[Rd] [R-gui] R GUI considerations (was: R, Wine, and multi-threadedness)

[James Wettenhall]

Hi again,

Peter Kleiweg wrote:
> To me, it does not make sense. When I have to work with
> something like Word, I am intimidated by lots of buttons with
> cryptic icons, with menus and submenus I can't make heads or
> tails of, the program doing weird things with my text I don't
> understand. A simple, friendly prompt is much more inviting.
> Give me a well-organised documentation, and let me do my thing.

I feel the same way.  But a typical member of the target audience for my
GUIs is certainly not someone like you or me (although occasionally I put
features into a GUI which can protect me against making some of the
mistakes I typically make at the command-line).  A typical member of my
target audience is someone who is highly intelligent, but has never heard
of a command-line interface, and would find it quite intimidating.  I'm
certainly not claiming that you are one of those people, but if you like,
I can introduce you to plenty of people like that.

> A GUI fits in a big-is-better marketing strategy. The more
> intimidating a GUI looks, the better.

I disagree.  I don't try to compete with the intimidating commercial GUIs.
My academic-style GUIs don't look and feel as professional as commercial
GUIs, but I give the user a choice.  Do you want to pay $5,000 per user
per year for commercial software to analyze your data, or do you want to
try using Bioconductor's command-line interface yourself (an idea they
will very quickly shy away from), or do you want someone else to analyze
your data for you or do you want access to the latest high-quality
statistical methods in Bioconductor via our GUI without paying any money
for a commercial license and without having to be intimidated by the
command-line interface?

When we first started distributing our GUIs, we were unsure whether we
would get more requests for new buttons / new features or more requests
for a less-intimidating set of menus/buttons, or possibly a "novice mode"
where lots of default values are used automatically without asking the
user, so that the data analysis workflow feels simpler.  Almost all
requests have been for more features, rather than complaints from people
who are intimidated or overwhelmed by too many choices.  But nevertheless,
I still think it is a good idea to have a "novice mode" in a GUI, with
less menu items, less buttons, less dialogs, with the understanding that a
number of default values are decided upon automatically without
consultation with the user.

> As a user, I always feel a
> prisoner of such monstrosities. Hundreds of options, but I
> cannot find the ones I actually need, with no possibility to use
> other software tools as auxiliaries.

Understood.  But as I said, you are not a typical member of the target
audience my GUIs are written for.  Neither am I.

> I find, the biggest problems with operating on large and complex
> sets of data (like you do in R), are things like digitisation of
> the data, preparation, transformation, selection. You usually
> have to do quite some work on the data before you have something
> R can handle.

Certainly most of the email questions we get from strangers about using
our GUIs are about how to get started e.g. rather than using a standard
raw data format which our GUI knows how to read, they have tried to
preprocess the files themselves in Excel or equivalent (unnecessarily), so
then we have to tell them "Please read our input-file-format
documentation!  Please don't mess with the standard raw data formats!" 
Then once they get started with the analysis, they are generally very
happy.  And we can try to improve our requried-input-file-format
documentation after getting their feedback.

> This preparation is best done with the tools you
> feel comfortable with, a simple editor, shell scripts, Perl,
> make, etc.

Again, it sounds like we are talk about a different class of users /
target audience.  My users certainly wouldn't know how to write a shell
script or use Perl or make.  But they do want to be able to analyze their
own data, and try different normalization methods and see the effects
graphically, rather than just sending off their data to a statistician.

> Once you have your data prepared, invoking another
> command through the command line is a small step. You can go
> forward and backward, doing data preparation and processing the
> prepared data with something like R, iteratively. Look at GRASS
> as an excellent example.

That's why we like writing GUIs for R, rather than just encouraging people
to use proprietary commercial GUIs.  If they use a commercial GUI, and
they want something a little different from what the commercial GUI can
do, there is often very little we can do for them.  But with an R GUI, you
can provide a way for the user to dump out an .RData file or equivalent,
so that if they need something which the GUI currently cannot do, then the
statistician can do some command-line operations on their .RData file and
send them back some graphs to put into their PowerPoint slides or an
updated .RData file they can continue using in the GUI or whatever.  I've
certainly done this for some users and they have been very pleased with
the results.  For other users, I have actually added new buttons / menu
items to the GUI very quickly in response to their requests for features
not currently available.

> You want all the preprocessing done in a GUI? I don't see how
> that is possible in a way that makes sense. How do you tell the
> GUI what your raw data looks like? How do you tell it to prepare
> the data for processing by R? Does the user have to learn the
> GUI's own scripting language and filters?

No, the user is not expected to learn any scripting language.  I think it
would be very difficult to write a general GUI for all types of data
analysis in R.  But we are focusing on very specific classes of data, e.g.
gene expression microarray data, where most people are using some very
well-known, well-documented raw data formats.  Gradually the developer can
add support for more raw data formats to the GUI, but sometimes the
developer receives a request for supporting a data format which is so
obscure that it is not worth the GUI developer's time to implement it so
we can just say "Sorry, you'll have to collaborate with a statistician who
can do your analysis at the command-line, unless you want to learn the
command-line interface yourself."

> If you want users to be productive, you have to give them
> something they can easily incorporate within the tools they use
> on a daily basis.

I have no objection to software developers writing Visual Basic macros for
Excel or webservers with familiar-looking HTML forms if that's what they
want.  But in our case, we want them to use something closely related to
the tools that WE use on a daily basis (not just what THEY use), because
if they develop a need for a customization - something out of the
ordinary, it is going to be much easier for us to fulfill their special
request using a command-line analysis if they are using R (either directly
at the command-line interface or via a GUI), than if they are using an
expensive proprietary commercial system.  And just to clarify, I'm not
talking about things like Microsoft Office which they would have anyway,
I'm talking about scientists deciding whether to spend thousands of
dollars on commercial software for very specific types of data analysis
starting with well-documented raw data formats or whether to use our free
software instead.

> No big applications with everything locked in,
> but a set of programs or commands that do specific tasks, with
> an easy to understand input and output. You need something that
> works in an open environment, so the user can use existing
> skills. With a GUI that does "everything", the user has to learn
> from scratch all the things that make "everything" happen.

I certainly don't think talking about at GUI for R that does "everything"
is realistic, and I have never considered doing that.  I'm happy to admit
that my GUIs have limitations in terms of what the users can do by
point-and-click, but for the advanced user (or for a collaborating
statistician who can take .RData files saved from their GUI analysis),
there are ways of switching from GUI analysis to command-line analysis
when really necessary, so in a way, an R-GUI _can_ do "everything", but it
just can't do everything in a user-friendly way, and doesn't want to try
to do that, because that would mean a completely intimidating collection
of menus and buttons (which is how some people feel about Microsoft
Office).

We may have to agree to disagree about some things, but I hope this has
made my point of view a little clearer.

Best wishes,
James