This question is inspired by the following tweet from Joyce Robbins:
RStudio has a lot of great design features which really enable/empower users as opposed to patronizing them. Joyce's tweet had a great example of this with RStudio providing GUI-like helpers to explore data but also showing the code-based approach.
My interest was particularly piqued by the word "explicit" to describe this design philosophy. Joyce said that this was discussed in the webinar, whcih I look forward to watching. However, it also made me wonder:
Are there any definitive written resources either from RStudio or recommended by its developers/users that discuss this philosophy in more detail? More generally, does anyone have any thoughts or favorite resources for inclusive, empowering tool design?
I'm interested in this too. It's interesting how variable responses to threads are on this forum. I feel like there have been other questions like this in the same vein before and it was eaten up by the members. Now, it's just silence.
I have no "definitive" resources, however I think the potentially stems from the tidyverse work. readr (I think before it was integrated fully into the IDE), had a shiny app that gave you a gui to point and click, but displayed very prominently the code that could be run. This parallels the approach taken in recent IDE changes like the object explorer and the connection manager.
TL;DR My hunch is it's a tidyverse approach, applied wholesale.
I think it helps if you ask questions in a way that encourages broader participation. This question is worded in such a way that it somewhat implicitly limits responses to somewhat at RStudio or someone who has seen/heard something from them in the past ("resources either from RStudio or recommended by its developers").
There's also a dumb luck factor as well; if the people that are most able to answer a question aren't around or don't have time to answer it, the thread doesn't reach the critical mass needed for sustained discussion.
I don't think the RStudio design principles are written down anywhere in particular, but I'll do my best to describe how we design IDE features. Our primary goals in developing the RStudio IDE are to:
Help encourage best practices when using R for data analysis,
Make R more easily accessible to new users,
Make it easier to write and debug R code.
We try to nudge users towards best practices where possible. For example, we strongly believe that analyses and reports should be reproducible. Clicking buttons in the IDE is not a reproducible action; however, the code generated by those actions can be used in reproducible reports. For that reason, we avoid designing features that can mutate state in the IDE, unless we can provide you the same R code that executes that action.
In doing this, I think we also help empower the user by teaching them how to use R to accomplish the same task that they've just executed within the IDE, and those same skills compound to help the user become a better data analyst.
Another way of putting it -- we try to teach you how to use R without the RStudio IDE, but attempt to make the R experience within pleasant enough that you stay anyhow. We believe this approach is genuinely helpful as you begin to automate data analyses, report generation, and so on -- you can build and debug your analyses in the IDE, but everything you build and implement is still yours, and can later be used outside of the IDE when required.
Ultimately, we want the RStudio IDE to help users become better, more productive data analysts, and so most of the features are designed to encourage that wherever possible.
Thanks so much for replying -- definitely none of this comes as a surprise after being an RStudio user, but it's really great to see the thought process articulated so nicely!
In my job, I'm both a frequent developer and consumer of internally developed analytical tools. I think "empowerment" really is the very best word to differentiate the best from the worst of the tools that I've touched.
Besides your own products, I also love the meta-empowerment of empowering others to build empowering products as well. Case in point for me is the ability to embed RMarkdown templates and R Project templates within packages which users can then open through the RStudio IDE.
By the way, as I think about this more, another question came to mind.
I have now seen/used some absolutely stunning Shiny apps so I know this isn't true across the board. However, I have also worked with some really terrible ones that only compound black-boxish-ness. It's always frustrating knowing that under the hood of these apps is simply R code that would be easily read/interpreted, but just clicking buttons it isn't always clear what is happening (or, to your point, not an accessible log of the options taken.)
Of course, the obligation to build good tools is up to the developer, but are there any defined best practices and/or specific tools built into Shiny to let other developers easily extend this philosophy? I'm thinking how cool it would be if -- just like the IDE's data loading wizard which writes the actual code -- it was easy for end-users to access and save the code-version of whatever they had accomplished in the GUI.
Hi Emily, there aren't currently defined best practices and/or specific tools, but some Shiny app developers have gone through great lengths to provide this kind of stuff in their own apps. Paul McMurdie and Susan Holmes put the most effort into this that I am aware of with shiny-phyloseq though that was a few years ago and I haven't looked at the code (just got a demo from them at an ROpenSci unconf and helped them work through some technical issues). I can't think of others off the top of my head but if you post on the Shiny category I suspect others will chime in.
I can't imagine we could make this kind of feature fully automatic with Shiny (unless you're OK with pretty craptastic code output) but I do think it's likely we could provide tools to make this much easier. For one thing, something like do.call(func, args) but instead of actually executing the code, it returns a ready-to-run version of the function body as formatted text. That might be a useful building block, once you've factored your app into sensible functions; at worst you'd have to spell out the relationships between these functions twice in your server.R, once for interactive use and one for printing. But at least you mostly wouldn't be copying-and-pasting a lot of code, which is what I suspect less sophisticated (than shiny-phyloseq) attempts at this are doing today.
Thanks so much to Emily for posing this question and to Kevin and Joe for the thoughtful replies. I also am a huge fan of this philosophy and make sure to spread the word as much as possible that this is how products should be designed.