[R-gui] Auto-GUI: Automated Building of GUIs for Objects

James.Callahan at CityofOrlando.net James.Callahan at CityofOrlando.net
Thu Nov 18 02:47:54 CET 2004


Developing a GUI for R is hard -- even at the conceptual level (let alone 
coding) -- because there is neither a unique path, nor a unique 
destination.

First, There is no one definitive GUI toolkit in the open-source 
community. Moreover, the type of person attracted to R development -- sees 
50 different ways of accomplishing the task. The closest solution I have 
seen is someone on this list developing an R interface to GUIs that 
provides a common R interface to multiple GUI toolkits.

Second, it is not clear what the GUI destination is. Given a clear idea of 
the destination, R developers find or develop the tools they need.

On 17-Nov-04 Philippe Grosjean wrote:

>  2) Second case: I write an original analysis and I want to make it 
widely
>  available for oceanographers. Most of them do not want, and will never 
learn
>  the S language. They obviously need a simple and easy GUI on top of my 
R
>  function, because they want to run the analysis without knowing all the
> details..."

One thought I have been toying with is that of an "Auto-GUI" tool that 
would look at an R object and attempt to build a GUI for it. The analogy 
would be the "Auto-Form" tool in MS Access (or the better implementations 
of the same idea in Lotus Approach or even in dBASE III). The DBMS looks 
at the table and mechanically builds a form.  The user has requested that 
Auto-GUI build an MS-Office style menu for an object. Auto-GUI looks at 
the object, sees that it has a print method and attaches the "print 
method" to "File-Print" option on the faux-Office menu.  Auto-GUI looks at 
the data structure and provides a tabular view (spreadsheet like) view of 
the data on one tab. Auto-GUI sees one or more plot methods and provides
separate tabs for various plots (some more complex plots may be lazy 
loaded, the plot isn't drawn till the user clicks on the tab). So far, 
this just more or less recreates GNumeric or MS Excel. There should be a 
model tab. But, what does a model look like in a GUI?

To me, this is one of the core GUI questions, what does a model look like 
in a GUI?   R has a standard syntax for describing a model on a command 
line, but what does a model look like in a GUI? The now classic MS Office 
GUI wraps a familiar menu around a visual representation of an object -- a 
text document, a worksheet, a graph, a project, a photo, a database table, 
a drawing, a map etc.. How should we visualize models and other R objects? 
 What is a WYSIWYG representation of a model?

A visual representation of a model could be:
- a simplified (implicit, but not explicit matrix notation) equation -- 
similar to the command line interface
- a matrix equation rendered in HTML with hotspot links to visual 
representations of the objects represented by the symbols in the equation
- a stylized version of a graph -- I'm looking at a GGobi cloud of points 
and I grab a "plane" symbol I want fitted through it. I twist the plane to 
indicate I want to allow curvature.
- a flowchart -- macroeconomic models are often depicted with flowcharts.
- a tree with  right hand (independent) variables converging towards one 
or more tiers of left hand (dependent) variables.

I like the idea of a matrix equation rendered in HTML for output.  I am 
frightened by the thought of students learning statistics as locations in 
a particular vendor's report. the student learns to look in a particular 
location on the output for a certain useful number.  Which is fine till 
they switch between stat packages such as switching between SPSS and SAS 
or SAS and R. If students are going to remember by location, then let them 
remember the location in the context of a matrix equation. The Auto-GUI 
with an output screen consisting of  a matrix equation rendered in HTML is 
one possibility, but it still might not be the best way to do it.

Suppose I have a graph of a histogram and then drag and drop a bell-shape 
curve onto it -- what should happen? 

Just some incomplete thoughts....

Jim Callahan
Management, Budget & Accounting
City of Orlando
(407) 246-3039 office
(407) 234-3744 cell phone
	[[alternative HTML version deleted]]



More information about the R-SIG-GUI mailing list