Dear All, There is no advantage of GUI over CLI, IMO. The real issue is the answer to the questions: "What should I do next?" or "What am I allowed to do here?" A "nice" interface, not necessarily GUI, will offer friendly answers: "I was expecting you to do _this_" or "In this situation you are allowed to do _these things_" You see, it's all a matter of _expectations_, which you statisticians are very good at computing. An application interface is a language, a dialog really, which has its own grammar and productions. A good interface should be able to recognize (in this dialog-language) the kinds of things you are trying to do and respond with hints or corrections when your inputs are incomplete or incorrect. A command-line interface is much more flexible in this regard because everything is a string and can be easily scripted as sequences. [Mouse movements and clicks are hard to model this way.] What is needed are more visual clues and responses from the CLI to guide all users, expert or not, to application paradise. HTH, Johanus Dagius __________________________________________________ -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-help-request at stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
At 05:03 AM 6/27/2002, Liaw, Andy wrote:
>My guess is that the args() function might help with the second problem,
no?
>
>Cheers,
>Andy
Yes and no. I didn't mention args because can't use it "in real
time". That is, the problem often arises after the student has typed the
function name and the opening parenthesis. Its a bit tough to type args()
in the middle of typing the actual function whose arguments you're trying
to remember. It is also difficult in the middle of a string of cascading
functions.
One (?simple) solution might be context-sensitive help (F1?) that calls up
the argument list of the function closest to the point of invocation (e.g.
in this trivial example):
>sqrt(var(x))
^ F1 after the "r" or "(" following
"var" would bring up
the args for var().
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !) To: r-help-request at
stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
> From: Marc R. Feldesman [mailto:feldesmanm at pdx.edu] > Sent: Thursday, June 27, 2002 10:23 AM > > At 05:03 AM 6/27/2002, Liaw, Andy wrote: > >My guess is that the args() function might help with the > second problem, no? > > > >Cheers, > >Andy > > Yes and no. I didn't mention args because can't use it "in real > time". That is, the problem often arises after the student > has typed the > function name and the opening parenthesis. Its a bit tough > to type args() > in the middle of typing the actual function whose arguments > you're trying > to remember. It is also difficult in the middle of a string > of cascading > functions. > > One (?simple) solution might be context-sensitive help (F1?) > that calls up > the argument list of the function closest to the point of > invocation (e.g. > in this trivial example): > > >sqrt(var(x)) > ^ F1 after the "r" or "(" following "var" > would bring up > the args for var(). >Well, not exactly... Methods could be a bit problematic. If you just do args(plot), it's not going to be terribly informative. It needs at least the first argument to figure out which actual method to call, and the actual method dispatch will need to be re-implemented at that level (context-sensitive help). That seems like quite a bit of work... Cheers, Andy ------------------------------------------------------------------------------ Notice: This e-mail message, together with any attachments, contains information of Merck & Co., Inc. (Whitehouse Station, New Jersey, USA) that may be confidential, proprietary copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by e-mail and then delete it. ============================================================================= -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-help-request at stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
At 14:47 26/06/02 -0700, Marc Feldesman wrote:>Beginners I've taught seem to have more difficulty figuring out which >function(s) to use to accomplish a particular task than actually figuring >out how to use R (or S-Plus) from the command line. They also have >difficulty remembering the arguments to specific functions once they figure >out which ones to use. The first problem might be resolved by a more fully >cross-referenced help system (the help system is great for experienced >users, but hard if you don't actually know the name of the function you're >looking for). The second problem might be aided by adding code-completion >to the UI - something ESS already does for many packages and libraries.Yes, that is why I insisted more on R's help system in the last version of "R for beginners". (BTW, a revised English version is now available on my home page, see link below, comments are welcome of course, I will send it soon to CRAN). I think how to use the help system is one of the few things that are good to know before starting. A nice way to learn R may be to run it and browse the help in html format: the "See Also"-section has hyperlinks from one help page to the others. I believe the help pages have all what people would like to see in a GUI. Emmanuel Paradis http://www.isem.univ-montp2.fr/ISEMFre/Equipes/PPP/PPerso/Paradis.php>I think if these two areas could be addressed, beginners might be less >daunted by R/S learning curve. > >My $0.01 (US). > > > >-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.->r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html >Send "info", "help", or "[un]subscribe" >(in the "body", not the subject !) To: r-help-request at stat.math.ethz.ch >_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._> >-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-help-request at stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
Hi, Another praiseworthy initiative, especially point 7!! :)) However, concerning point 6, I have some doubts. Java is undoubtedly very cross-platform, but it also quite slow and a drain on resources. If you are considering Omegahat's SJava: the Windows binary is obsolete although that may be easy to remediate, and the source pakage requires an SDK to be installed, something not everybody needs otherwise. I don't know the other alternatives well enough -- I didn't like what I saw of wxWindows, though :) -- but they do not appear to be used very widely. Why don't you consider gtk? This is actively being actively developped, there exists an associated resource editor (glade), it runs on multiple platforms, and last-but-not-least there is already a beginning of a GUI interface for R written using it. An alternative is TrollTech's QT, the powerful basis for the KDE environment. It too exists on multiple platforms, and may actually be more platform-independent than GTK. I think it may be used freely in open source projects. As to the interface design: did you see my post in this thread where I mentioned NCSS? It has a simple interface design that is quite elegant and self-explaining, and that should be easy to interface to a CLI environment like R inherently is. I do not at this point volunteer as a developper, but I certainly will want to beta-test once you're a bit further advanced with the project! Cheers, RenE Bertin PS: univ. of B.C., that's in wonderful Vancouver, isn't it? How are the dogwoods this year? ------- Hi Folks, I'm sorry I missed this message. Myself and a Professor at a California university are currently designing a simplified R GUI that is targeted at Linux, FreeBSD, MacOSX, and Windows and will provide an interface to doing "canned" procedures and project based operations. I'm currently building [...] The tentative name for it is obveRsive woRkbench, and it is currently way to early to even guess at a release date or even if the project is actually feasible. Since the project will be open source, I'm hoping to get a few collaborators on it (hint hint). It will be hosted on sourceforge or an equivalent when we are ready. [...] 6. Utilizing a cross platform GUI system, either FLTK or wxWindows in C++ or Java (depending on which is easier and more stable). 7. Heavily user tested with a focus on usability, targeting students and regular folks, not professors of statistics :-) Any commments on this are more than welcome, and we'll be announcing it officially soon. Zed A. Shaw University of British Columbia -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-help-request at stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
Hmmm. Choice is a good thing, but so much choice?! Then why not just expect every user to develop his or her own GUI?! I fully agree that whatever technology is going to be used to develop a GUI for R, it should ideally be something that contains a layer of abstraction within it, allowing it to run natively on all supported platforms, and not require an additional layer like (apparently) gtk needs X11 to run on the Mac (but afaik it is native on windows, so it will probably be carbonised or whatever for osx sooner or later). But to get a useful GUI that responds to the expectations and requirements of the largest number of people possible, a consensus will have to be found on the beast's phenotype (how it looks, what it does, etc.) and its genotype (the codebase to be used). This is how OpenOffice was developped in a little over a year, this is how mozilla is being developped (the former using its own layers of abstraction for interfacing with the host, the latter [mainly, methinks] using gtk). Of course, linux but also R itself, and probably FreeBSD on which Darwin is based are also developped by countless developpers -- but in concert. I am afraid that the other alternative will result to, indeed, numerous, more-or-less-half-hearted attempts that will surely work, each do something a little differently or a little something different, leaving the user with the existential question which version again was able to tackle the problem at hand, and does it run on my system. PS: your passionate account of choice reminded me of my own days as a fervent Mac user & advocate -- but it also gave me some (more) reasons why I will probably not go back (except when Michael Robertson decides to port Lindows to the PPC :))) PPS: have you ever tried to count the number of Aquaish themes for gnome/gtk? Combine that with Oroborus/X (a window manager for X/Darwin in rootless mode), and you get pretty close -- at least to untrained eyes 8^] Met vriendelijke groet, RenE J.V. Bertin College de France/LPPA 11, place Marcelin Berthelot 75005 Paris, France>From: Jan de Leeuw <deleeuw at stat.ucla.edu> >To: "RenE J.V.Bertin" <rjvbertin at hotmail.com> >CC: r-help at r-project.org >Subject: Re: [R] re: GUI's for teaching >Date: Sun, 7 Jul 2002 10:18:43 -0700>There will soon be more than 10, maybe more than 20, different GUI's >for R, and that is how it should be. You just don't want all of them on >CRAN. >But generally, the more the better. > >Think of Emacs on the Mac, for instance. There is Classic, Carbon, Cocoa, >Darwin, Xemacs, GNU Emacs. All running on top of the vanilla Unix code, >which can still be used from the command line. Lots of choice. > >Think of TeX on OS X. Excellent implementations in Carbon (OzTeX, CMacTeX), >Cocoa (TexShop, iTeXMac), all running on top of teTeX. All >functionally basically equivalent, but differing in ease-of-use, degree >in which one can customize, flexibility. Again, lots of choice. > >Of course most people on OS X will prefer Cocoa R, but some may want >to run ESS in Cocoa Emacs, and some may even want to use >gnome/KDE/Qt/wxWindows/FLTK/tcltk and so on. Great. There >is something to be said for cross-platform development, but >you cannot seriously expect someone with access to the Cocoa API's >to develop for an X11 based toolkit. And you cannot expect someone >who lives in TeXShop, Cocoa Emacs, and Chimera (Navigator) >to happily switch to a gnome/gtk interface to run their R._________________________________________________________________ -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-help-request at stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
>From: Jan de Leeuw <deleeuw at stat.ucla.edu> >To: "RenE J.V. Bertin" <rjvbertin at hotmail.com> >Subject: Re: [R] re: GUI's for teaching >Date: Sun, 7 Jul 2002 20:14:04 -0700>On Sunday, Jul 7, 2002, at 15:48 America/Los_Angeles, RenE J.V. Bertin >wrote: > >>Hmmm. Choice is a good thing, but so much choice?! Then why not just >>expect every user to develop his or her own GUI?! >> > >That is unrealistic to expect, but it would be ideal, of course.Then we do not agree on this. But it all depends on where you place your priorities...>>phenotype (how it looks, what it does, etc.) and its genotype (the >>codebase to be used). > >The same genotype can lead to different phenotypes (Qt for Windows looks >different from Qt for X11 looks differentYes, it looks different in that it "adapts to" the environment it runs in. However, buttons and the like will still be more or less in the same place, and more importantly, the philosophy behind the man/machine interaction protocols, the ergonomics, remain the same.>from the Aqua version for OS X -- same story for tcl/tk). Mapping toolkits >to native calls uses the strength of the >native toolkit -- such as services on OS X (or NextStep).Again, it is a matter where you place your priorities and your resources. Developping an interface that makes use of all sorts of facilities of an operating system's layer that some claim to be exiting is probably very exciting and satisfying indeed for them. But then what -- you have a nice tool, but you can't exchange with the majority of others? I think that's a pity and, in the context of R (intended to be multi-platform), an effort lost.>>This is how OpenOffice was developped in a little over a year, this is how >>mozilla is being developped (the former using its own layers of >>abstraction for interfacing with the host, the latter [mainly, methinks] >>using gtk). > >OpenOffice now exists for the Mac in two versions: one on top of X11, the >other using Carbon. Of course, they lookLast time I looked, OO only ran under X11.>different. Mozilla exists as Classic, as CFM-Carbon, and recently as a >Mach-O Carbon application. Again the versions >look different, because they inherit different components from the >different toolkits. Moreover Mozilla's Gecko engine is used in Chimera on >Mozdev, which is a pure Cocoa application. And again looks very different.Hmm. If they look so different while all using technology from the same vendor, who is to blaim -- if blaim there is to be found?>My guess is that the 20+ versions of the GUI will all have roughly the same >menus, and roughly the same >capabilities. And that these capabilities will not be very different from >those of ESS.Then that's 20 wheels reinvented :)>Choice includes the option to run X11 with any window manager, with gnome >or KDE, either on top of Darwin >or of Linux, either on PPC or X86.Amen. And how much choice in this matter do you have under Aqua? Last time I looked (February), you could choose between candy-colours and basically almost grayscale appearance, there were a few (unstable) hacks to customise a bit more (and outcry on the forums for more control), and it didn't seem possible to even specify a solid colour for the desktop rather than an image... OTOH, many users are probably (blisfully) unaware of the fact they don't have (unlimited) choice (and consider me a weirdo because I modified the look of my Windows boxes -- is that Linux you're running there? :)))>Illustrates my point. If people want to make X11 applications look as Aqua >as possible, then one might as well write >applications in Aqua. Makes them much more powerful as well.I think they would be very upset if you suggested that to them :) They will probably feel they should be able to give whatever look they like to their environment of choice. Just have a look at the themes sections on freshmeat.org ... Anyway, this is drifting too faR...>Hetzelfde.:)>>RenE J.V. Bertin >>College de France/LPPA >>11, place Marcelin Berthelot >>75005 Paris, France_________________________________________________________________ -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-help-request at stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._