<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<p>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.
<p><b>*FNAS Teaching Perspective*</b>
<br>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.
<br>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.
<br>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!).
<p><b>*R Community Teaching Perspective*</b>
<br>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.
<br>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?
<br>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.
<br>The following ideas were voiced, many of which already have applications:
<br>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).
<br>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.
<br>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).
<br>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.
<br>5) The Khoros idea of Tim Keitt's sounds good.
<br>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.
<p>I look forward to responses.
<p>graham lawrence wrote:
<blockquote TYPE=CITE>Definitely 2 camps on this issue; so why not compromise
with a drop-down
<br>menu for the most frequently used processes, the user responds with
<br>necessary parameters for his choice, and R then writes the source statements
<br>on the terminal and executes them. The user follows the familiar
<br>procedure, is thereby automatically introduced to the command statements
<br>involved, and R's self-documentation feature is retained.
<p><br>John Fox wrote:
<blockquote TYPE=CITE>Dear R list members,
<p>I've read with interest the discussion about developing a GUI for R,
<br>particular reference to the use of R in elementary statistics classes.
<p>Brian Ripley's point -- that students can use a GUI-based package with
<br>little instruction and support -- is the key point for me. This isn't
<br>a question of laziness: Spending time teaching students command-driven
<br>software that they may not use again after the class, or may use too
<br>infrequently to become fluent, takes time away from teaching other
<br>The counter-argument that GUIs are too easy to abuse seems perverse
<br>If students are taught to analyze data properly then they won't abuse
<br>software. They can produce nonsense with command-driven software as
<br>Surely there's no real virtue to making things hard for people.
<p>Another point is that the presence of a GUI provides an option, but
<br>doesn't force anyone to use it. I never use the GUI in S-PLUS, for
<br>example, and would likely not use a GUI in R for my own work, nor for
<br>classes beyond the elementary level.
<p>Finally, I wonder whether it would be helpful to refocus the discussion
<br>providing tools for creating GUIs rather than a GUI itself. I have
<br>a (perhaps updated) version of the kinds of tools provided by Lisp-Stat
<br>for constructing menus and dialog boxes. Lisp-Stat makes these available
<br>for Linux/Unix systems, Macintoshes, and Windows systems. With such
<br>in place, teachers interested in creating GUIs for their classes could
<br>so, contributing the results to CRAN. I hesitate to make this suggestion,
<br>since I don't have the expertise to program -- as opposed to use --
<p>My take on that is that for people who'll need to work with data
<br>analysis an a daily basis, there's no way around learning the command
<br>line. You simply don't get the "information at your fingertips"
<br>feeling any other way.
<p>However, there's a fairly large group of people who need to do
<br>statistics only at quite long intervals -- they spend years collecting
<br>data, and when they get to analyzing them they don't want to (re)learn
<br>a whole language. In some cases there is also an amount of
<br>anti-intellectualism involved ("Just show us what to do!"), which the
<br>statistician should arguably fight against but that can be hard. For
<br>those people, we really need a simplified interface, or they'll come
<br>back to haunt us with questions about how to solve the hard issues
<br>(that they inevitably run into) in SPSS....
<p>rohan sadler wrote:
<blockquote TYPE=CITE>>Dear All,
<br>>This is a question to sound out possibilities.
<br>>I am with the Faculty of Natural and Agricultural Sciences at the
<br>>University of Western Australia, representing a few of the more
<br>>statistically minded in the faculty. Essentially, there have been
<br>>problems in the past with software support, changing over statistical
<br>>software, and paying lots of money for it. In R you have an advanced
<br>>statistical software package, it is free and it is adaptable. Also
<br>>maths department at UWA is using it on an informal basis and so support
<br>>over the long term is available. The only reason why the faculty is
<br>>using R as a whole is because there is no GUI equivalent to
<br>>Minitab/SPLUS/Genstat in R that can be used for undergraduate teaching
<br>>purposes (unless I'm seriously mistaken). In RWindows there is the
<br>>but it is not designed to carry statistical functions with buttons
<br>>options and this is what is needed for low statistical level undergrads.
<br>>There is RWeb, but at this stage of development you wont find many
<br>>takers in the faculty.
<br>>What I want to know is this: can anyone give me a quote on what it
<br>>cost to develop a RWindows clone of the Minitab GUI. This GUI would
<br>>support initially the simple six (EDA, probabilities and quantiles
<br>>distributions, t-tests,one-way anova, chi-square, and simple linear
<br>>regression), and have the potential to develop into the next level
<br>>statistical analysis (glms, multivariate methods, time series and
<br>>spatial - analytical problems common across our faculty). If the cost
<br>>development is comparable to present licence maintenance fees at FNAS
<br>>then I think our small group can argue for its adoption. Not only
<br>>the benefits to undergraduate teaching in other universities would
<br>>immense. If development costs are high then other faculties at other
<br>>universities, where the software licencing arrangements are also
<br>>troublesome, are also invited to participate in this potential project.
<br>>I imagine this question has been discussed before, but I hope to have
<br>>but an interesting turn to it.