I was just walking about the U Tenn campus thinking about my next month departure from the school back to India when I ran into Bob Muenchen , head of the Stats consulting centre and more famously the author of ” R for SAS and SPSS users” . Bob mentioned that the edition for R for Stata should be ready for next month. It was also his idea for the article on Red R.
In fact what perplexes users of statistical software like me is why complex softwares like R or SAS choose interfaces that are clearly not as well designed in simplicity as they are in statistical rigor. I think SPSS to some extent and JMP to a much greater extent represent well designed user interfaces. While Rattle , R Commander , R Analytical Flow and Red R are examples for R interfaces SAS also invested in the Enterprise class interfaces.
On all these I belive there is a much greater need for say a Pro UI designer and clean it up. I was reading Prof Maeda’s laws of simplicity ( see http://lawsofsimplicity.com ) and just comparing and contrasting that with some of the softwares I end up using.
The Principles of Reduce ( Shrink, Hide , Embody ) and Organize ( Sort , Label , Integrate and Priortize ) need to be looked into by the Chief Software Interface designers for analytics and BI. While attempts to create more and more robust and faster algorithms and prettier dashboards are important is it not important to simplify the process and procedures to do so . The software which is easier to learn and pick up will tend to have an edge over less visually designed softwares. Keeping it simple helped Apple in the retail electronics and software , it needs to be seen who or which enterprise BI or BA software will make attempts to do the same. An ideal stats or BI interface should be simple and powerful enough to be used by decision makers directly on occasion rather rely on the middleware of analysts and consultants solely.
5 thoughts on “Towards better Statistical Interfaces”
I tend to agree that R and similar statistics software would benefit from better UI. Many of today’s expert users (and developers) make the mistake of thinking that the R interface should be programmatic, because otherwise how would you do ?
UI designers have, for years, been addressing this problem. Unfortunately, there are lots of developers, there’s lots of software, and there are very few good UI designers. As a result, there are very few examples of software that work well for both experts and beginners.
One of my favorite authors in the field of UI design (or interaction design, as is preferred) is Bruce Tognazzini. Bruce has a depth of knowledge in the field that few can match, and an uncommon clarity in his writing. I believe that developers of front-ends for R would better their software by leaps and bounds if they read through just some of Bruce’s material at http://asktog.com/menus/designMenu.html.
Great site. I like the way you explain everything without using complicated terms.
Speaking of GUIs for R… take a look at Deducer if you get a chance. I’ve tried to put some serious thought into ease of use and GUI design principles (http://www.deducer.org/pmwiki/pmwiki.php?n=Main.GUIDesignConsiderations).
home page: http://www.deducer.org/pmwiki/pmwiki.php?n=Main.DeducerManual
“An ideal stats or BI interface should be simple and powerful enough to be used by decision makers directly on occasion rather rely on the middleware of analysts and consultants solely.”
Um, yes and no. There are some questions and analyses that really are quite complicated. Putting everything into a simple button click interface just doesn’t cut it. The issue is that decision makers need their results summarized for them in a way that the implications of the decision are understood. For the data analyst 90% of the battle is formatting the data. Does it count if I have to write 200 lines of code in python to make a data set acceptable for jmp? Simplicity is good, up until the point where the question is no longer relavant because it has been abstracted away.
Note: I mentioned the word “on occasion”. Basically softwares should aim to be useable atleast 10 % of the time by the CEO- Decision Maker directly, the remaining 90% of the time , data shaping can be done by analysts. Also the ability to store repeatable data formatting – this can help analysts themselves in helping with more insights OR even helping in focus on IMPROVING Input Data Quality Projects- which they can not do currently due to paucity of time. I agree that simplicity and complexity need to be balanced as you can see from the Review on John Maeda’s book (Law 9)