[R] re: GUI's for teaching

[Rohan Sadler]

Dear All,

Thankyou for your responses. Graham Lawrence, John Fox and Peter Dalgaard have thus
far said most cogently what I really had in mind. I'll demonstrate this by
clarifying the points that have arisen in the discussion so far.

*FNAS Teaching Perspective*
Although there is a range of student abilities students generally are not
mathematically inclined, or do coursework that has a high exposure to maths. They
are definitely not dedicated students of statistics. All they need to learn as a
group are the simple six analyses (simple EDA, basic prob.and distbns., t-tests,
one-way anova, linear regression, chi-sq test). Later, hopefully, the majority will
go on and do higher level statistics such as multivariate analyses and glms, but
again at a very applied level. Essentially they need to be aware of the limitations
of the analyses, and know where to go if they need further analyses, along with
basic statistical logic. This is to make them adaptable to the future. If they wish
they can take their knowledge further.
Two important consequences are that: 1) they will as soon forget R language as soon
as it is taught, and the learning curve is thus not worth the effort when they can
be developing other skills in statistical thinking that are going to be of more
value to them in the long term; and, 2) their work environments will be applied
science, which typically are GUI based. They need to be able to translate what they
learn at the university to the most likely work environments with ease, otherwise
the university learning is in a sense practically useless.
A GUI is more justifiable in this context, and is the rationale which is stopping
R's adoption as I see it in FNAS (beyond common conservatism towards statistics in
an establishment type natural sciences faculty - but that is besides the point!).

*R Community Teaching Perspective*
All arguements put forward by the R community are valid and I agree with completely
with the basic thrust. This thrust is one of "Gooiness" not being useful at high
levels, and encouraging a certain empty-headedness amongst students. Hence the
conclusion to be drawn from these real observations are that the sooner that
students can get onto R code then the better for their thinking and critical
processes, and the better for their analyses given the practical usefulness of
coding up and saving scripts.
Here Graham's and John's comments are pertinent. Teaching science in an applied
science should consider the whole of the student's statitsical career. The entry
point is first year where coding should not play a fundamental role to student's
understanding. At this stage the statistics package, as a demonstrator of
statistical principles, should do that with minimal fuss and pain. This is where
the GUI will be useful. Moreover, if the GUI writes source statements on a
terminal, and executes them, as what occurs in Minitab, then it is very easy for
students to make the link between buttons on a gui and parameters in command line
function. A script is thus easily constructed. When it comes to the next level
course, then this can be command line - as they already have an introduction to the
basic R commands, and more importantly to the logic of object orientated code.
Given that there are often data manipulations in multivariate code that are not
easily done in your Minitab (its junky compared to R), and getting students to
think in vector notation, then code is the best solution. To my mind this will
provide an exceptionally good platform to those students who wish to take
statistics further when they choose to become postgraduates. Our present situation
is that advanced students are taking on hard problems because that is the nature of
applied science problems, because they are thinking in a GUI framework. They do not
have the programming  or statistical resources and skills (where to find
appropriate software, documentation, and make sense of it) to make these problems
tractable. However, it seems clear to me that if a GUI was developed along the
above lines then the two needs, the low level  and the high level needs of the
range of different students under the faculty's tutelage, can be married. Does
anybody object to such a marriage?

*Documentation*
My opinion follows Graham, keep as much of the R-documentation as possible since
the connection between GUI buttons and function parameters is self-evident, and a
good lead into further exploration of R functionality and stats. Reference cards
can help (have a GUI reference card for the basic functions). R's manuals and
tutorials need no further compliments.

*Development*
The following ideas were voiced, many of which already have applications:
1) Icons on desktops that lead to GUI's that perform the analysis. Should be
sufficient, and easy to represent as a "toolbox" (essentially a menu bar).
2) Web Servers. I still have a problem with look and feel, though these can be
reasonably easy to solve. Again, if there was an equivalent of it in the current
workplace, rather than specifically  for teaching purposes, then I'd support it.
3) Turning to Linux. Sorry, where I come from this is not do-able in the near
future, for much the same reasons as why a GUI would be more suitable. Also we are
a large faculty whose administration is already uptight about how much it has
invested in computer resources and changes overnight are not in the business plan
(sigh! I use linux and this fact brings tears to my eyes).
4) Tcl/Tk interface. Some comments were on the suitability of it's cross platform
compatibility. As to look and feel I use sometimes the Tcl/Tk interface for the GIS
GRASS, and this is more than good enough, because again it is a concept that is
easily exported to the stats packages that these students are generally likely to
meet in the workplace.
5) The Khoros idea of Tim Keitt's sounds good.

*Final Point*
The other issue is that the drain on resources to have an ideal GUI in place will
be large. This use of time taken away from other projects is perhaps the biggest
issue - if it was easy to do then it would already have been done. So I offer a cup
of "Ophelia's Wine". How much would it cost to develop a menu for R windows that
has the simple six contained within it? Basic requisites would be that such a menu
be extensible to Linux and Mac at a later date, though not necessarily now. If
somebody can give me a price, even if it means hiring someone extra as part of an
existing programme, then I can start finding funding. The rational is that if the
costs of development are cheaper than the cost of maintaining existing licences
then it is do-able and promotable. Suprisingly, no one took up this issue in any
form, apart from  Kenneth Cabrera, and which was raised in my initial email.

I look forward to responses.

Rohan


graham lawrence wrote:

> Definitely 2 camps on this issue; so why not compromise with a drop-down
> menu for the most frequently used processes, the user responds with the
> necessary parameters for his choice, and R then writes the source statements
> on the terminal and executes them.  The user follows the familiar gui
> procedure, is thereby automatically introduced to the command statements
> involved, and R's self-documentation feature is retained.
>

John Fox wrote:

> Dear R list members,
>
> I've read with interest the discussion about developing a GUI for R, with
> particular reference to the use of R in elementary statistics classes.
>
> Brian Ripley's point -- that students can use a GUI-based package with
> little instruction and support -- is the key point for me. This isn't just
> a question of laziness: Spending time teaching students command-driven
> software that they may not use again after the class, or may use too
> infrequently to become fluent, takes time away from teaching other things.
> The counter-argument that GUIs are too easy to abuse seems perverse to me:
> If students are taught to analyze data properly then they won't abuse the
> software. They can produce nonsense with command-driven software as well.
> Surely there's no real virtue to making things hard for people.
>
> Another point is that the presence of a GUI provides an option, but
> doesn't force anyone to use it. I never use the GUI in S-PLUS, for
> example, and would likely not use a GUI in R for my own work, nor for
> classes beyond the elementary level.
>
> Finally, I wonder whether it would be helpful to refocus the discussion on
> providing tools for creating GUIs rather than a GUI itself. I have in mind
> a (perhaps updated) version of the kinds of tools provided by Lisp-Stat
> for constructing menus and dialog boxes. Lisp-Stat makes these available
> for Linux/Unix systems, Macintoshes, and Windows systems. With such tools
> in place, teachers interested in creating GUIs for their classes could do
> so, contributing the results to CRAN. I hesitate to make this suggestion,
> since I don't have the expertise to program -- as opposed to use --
> GUI-creation tools.
>
> John

Peter Dalgaard

My take on that is that for people who'll need to work with data
analysis an a daily basis, there's no way around learning the command
line. You simply don't get the "information at your fingertips"
feeling any other way.

However, there's a fairly large group of people who need to do
statistics only at quite long intervals -- they spend years collecting
data, and when they get to analyzing them they don't want to (re)learn
a whole language. In some cases there is also an amount of
anti-intellectualism involved ("Just show us what to do!"), which the
statistician should arguably fight against but that can be hard. For
those people, we really need a simplified interface, or they'll come
back to haunt us with questions about how to solve the hard issues
(that they inevitably run into) in SPSS....

rohan sadler wrote:

> >Dear All,
> >
> >This is a question to sound out possibilities.
> >
> >I am with the Faculty of Natural and Agricultural Sciences at the
> >University of Western Australia, representing a few of the more
> >statistically minded in the faculty. Essentially, there have been
> >problems in the past with software support, changing over statistical
> >software, and paying lots of money for it. In R you have an advanced
> >statistical software package, it is free and it is adaptable. Also the
> >maths department at UWA is using it on an informal basis and so support
> >over the long term is available. The only reason why the faculty is not
> >using R as a whole is because there is no GUI equivalent to
> >Minitab/SPLUS/Genstat in R that can be used for undergraduate teaching
> >purposes (unless I'm seriously mistaken). In RWindows there is the GUI,
> >but it is not designed to carry statistical functions with buttons for
> >options and this is what is needed for low statistical level undergrads.
> >There is RWeb, but at this stage of development you wont find many
> >takers in the faculty.
> >
> >What I want to know is this: can anyone give me a quote on what it will
> >cost to develop a RWindows clone of the Minitab GUI. This GUI would
> >support initially the simple six (EDA, probabilities and quantiles of
> >distributions, t-tests,one-way anova, chi-square, and simple linear
> >regression), and have the potential to develop into the next level of
> >statistical analysis (glms, multivariate methods, time series and
> >spatial - analytical problems common across our faculty). If the cost of
> >development is comparable to present licence maintenance fees at FNAS
> >then I think our small group can argue for its adoption. Not only that,
> >the benefits to undergraduate teaching in other universities would be
> >immense. If development costs are high then other faculties at other
> >universities, where the software licencing arrangements are also
> >troublesome, are also invited to participate in this potential project.
> >
> >I imagine this question has been discussed before, but I hope to have
> >but an interesting turn to it.
> >
> >Regards
> >
> >Rohan Sadler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://stat.ethz.ch/pipermail/r-help/attachments/20020627/ab30a810/attachment.html