[R-gui] [Rd] R GUI considerations

From: Philippe Grosjean

Duncan,

I agree totally with you on all points, now that we clarified our 
respective ideas. I am afraid I probably agree also with your last 
point, from a theoretical point-of-view ("I still think we need more 
glue and am working on that while we continue to experiment with the 
design of GUIs for the next 5 years rather than the immediate 
needs.").

I say, from a theoretical point-of-view, because in practice I am not 
sure all these people waiting for GUIs, like in the projects I cited 
before, will appreciate we just continue to play in the sandbox for 
another 5 years!!! They want their GUI delivered... in the 
next years, 
or in the next six months, or even closer if possible!

So, a mix between the theoretical approach and the practical 
needs tells 
me that it is perhaps time to shorten a little bit the 
sandbox phase and 
to move forward right now.

Best,

Philippe

..............................................<?}))><........
  ) ) ) ) )
( ( ( ( (    Prof. Philippe Grosjean
  ) ) ) ) )
( ( ( ( (    Numerical Ecology of Aquatic Systems
  ) ) ) ) )   Mons-Hainaut University, Pentagone (3D08)
( ( ( ( (    Academie Universitaire Wallonie-Bruxelles
  ) ) ) ) )   8, av du Champ de Mars, 7000 Mons, Belgium
( ( ( ( (
  ) ) ) ) )   phone: + 32.65.37.34.97, fax: + 32.65.37.30.54
( ( ( ( (    email: Philippe.Grosjean at umh.ac.be
  ) ) ) ) )
( ( ( ( (    web:   http://www.umh.ac.be/~econum
  ) ) ) ) )          http://www.sciviews.org
( ( ( ( (
..............................................................

Duncan Temple Lang wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi Philippe.

 I am sorry that you are upset by what I wrote.
I did not intend to cause offense.  And I was
not considering you as "just a professor only interested
by the results of your students".  However,
the discussion has unfortunately degenerated to that
common denominator for several people, either implicitly
or explicitly and I believe it is important to make
certain that the real issues are identified and discussed
by being precise about what it is that is being discussed.

I most certainly do thing a "polymorphic" GUI
that mixes different components is feasible.
Indeed,  I have been working on the integration
in general terms for many years and have developed
a general infrastructure for integrating such tools
in various settings.  What we are discussing is
the software architecture for constructing this
distinctly focused GUIs.

I think experiments in GUI design are terrific and
we need them.  I applaud SciViews for this.
And JGR, etc. too. But they don't necessarily
allow others to experiment as they are not
customizable. Just as users don't necessarily
want to learn R to do statistics, R programmers
don't necessarily want to learn Java or C++
and the specifics of an application like
SciViews or JGR to try out small changes.
That is why I have long argued that we use
the existing common interest that we all have
which is R and that we allow people
to reuse components of SciViews, etc.

If these are integrated into R so that people can
really modify them and construct different GUIS
from their elements, that would be terrific.
In the meantime, the ability to easily and conveniently
do experiments in R does warrant discussing a software
architecture that facilitates that and so involves
bindings to toolkits, both modern ones and convenient ones.

 Anyway, apologies again for the misunderstanding. I was
not considering you in that narrow fashion that came
across in my mail.

 Enough said for the moment. All these experiments are good,
collaboration is good. The obvious place to do it in my book
is in the R language or else have some good glue between the
systems.  As much work as I have done on GUIs in the S language
in  the last 13 years, I still think we need more glue and
am working on that while we continue to experiment with the
design of GUIs for the next 5 years rather than the immediate needs.


 Thanks,
  D



Philippe Grosjean wrote:

Duncan,

Could you, please, stop considering me as just a professor in
biostatistics only interested by the results of my students 

and nothing

else. Do you need a couple of evidences that I am working with other
people, other applications, and that they require totally different
GUIs? Here they are:

1) I am the instigator and main programmer of ZooImage
(http://www.sciviews.org/zooimage/), an Open Source system combining
ImageJ and R (mainly) to provide a complete numerical image analysis
system for automating zooplankton samples processing. In the R side,
image measurements gathered by ImageJ are analyzed with the 

powerfull

machine learning algorithms implemented in R (like random forest,
bundling, ...). After analysis of several samples, they 

usually form a

space or time series to be analyzed by respective tools, still in R.
Targetted users are biological oceanographers... most of them are
reluctant to "programming" in R (i.e., to write and edit 

little scripts

to run the analyses), and the others are more accustomished 

to Matlab.

2) I participate to the development of FLR 

(http://flr-project.org/), a

framework for modelling fisheries entirely written with S4 

objects. The

project is now used in several fisheries evaluation programs, and we
face some problems with modellers and advisors telling they 

don't want

to have to "learn R" for running their models. Quite different
application and targetted users.

3) One of the future contracts I mentioned earlier in this 

post is with

IFREMER, to make a flexible reporting system mixing the report()
functions of SciViews and Rpad to end up with dynamically 

recalculable

HTML reports (hopefully web-based solution), for instance for weekly
reports on the survey of water quality along the French 

coast. Again, a

very different application and GUI.

4) Another contract consists in making an artificial human noise,
analysing results from more than 200 artificial odor receptors. The
people there agree for using R as the "calculation engine", 

but want a

really simple point and click interface for their analyses, 

and all the

machinery completely hidden.

That said, if you consider a polymorphic R GUI that mixes 

together the

different paradigms (menu&dialog boxes, spreadsheet, notebook-like
interactive documents, ...) is not something possible to 

do, it is your

problem. My own experience, *including the various 

different situations

cited here above* make me feel that it is something 

possible. I don't

want to kill all R GUIs projects in favor of a single one, 

but I affirm

that we should work in a more collaborative way.

Best regards,

Philippe

..............................................<?}))><........
) ) ) ) )
( ( ( ( (    Prof. Philippe Grosjean
) ) ) ) )
( ( ( ( (    Numerical Ecology of Aquatic Systems
) ) ) ) )   Mons-Hainaut University, Pentagone (3D08)
( ( ( ( (    Academie Universitaire Wallonie-Bruxelles
) ) ) ) )   8, av du Champ de Mars, 7000 Mons, Belgium
( ( ( ( (
) ) ) ) )   phone: + 32.65.37.34.97, fax: + 32.65.37.30.54
( ( ( ( (    email: Philippe.Grosjean at umh.ac.be
) ) ) ) )
( ( ( ( (    web:   http://www.umh.ac.be/~econum
) ) ) ) )          http://www.sciviews.org
( ( ( ( (
..............................................................

Duncan Temple Lang wrote:



Philippe Grosjean wrote:

Hello Marc and the others (and the User!2006 organizing 

commitee),

I answer to Marc's email, because I think it is the most 

constructive

one. I am a little bit dissapointed that the discussion 

about R GUIs,

whatever the initial subject, inevitably shifts to an endless
discussion about which graphical toolkit to use, and whether one
should interface it directly, or by means of an 

intermediary language

perhaps more suitable for handling widgets events.

Should I recall that this thread is *not* about which graphical
toolkit to use, but is trying to trigger a discussion on 

how could we

work together to avoid duplication in coding for R GUIs, 

and perhaps,

join in a common project. Something totally different!

I think all of us will agree that we have limited resources
and should collaborate where possible.
However, to do this, we must have a common set of interests
that form a reason to collaborate.
Your earlier mail mentioned the link
(http://www.sciviews.org/_rgui/rgui/GUIs.html)
to the different types of GUIs you were considering, be it
a Web-based, or notebook style, or whatever.

I really think that you have to think about things from 

other peoples'

perspectives and realize that many of us are not 

considering "the GUI"

as you are. You seem to have an audience in mind which
 a) need access to a broad range of R functions
 b) are averse to the command line.
It appears you have students in mind, probably non-statisticians
in an introductory class.  That is great. And your approach is
perfectly reasonable to address that need.

However, others of us have very different goals.
Some of us want specialized GUIs, e.g. GeneGGobi, interfaces
to specific functionality (e.g. random forests), ....
Others of us have been buidling tools for interactive 

documents, much

like a Web browser embedded in R with complex composite widgets
embedded within the document to have dynamic, interactive documents.
These are very different audiences, and accordingly very different
GUIs.  They require not customization of a general GUI, but
an ability to construct entirely new GUIs.

Where we can really collaborate is in the development of
GUI components that can be used from within R to construct
these different GUIs.

I really encourage you to try to consider what other people
are thinking and hopefully this will help us get past the
discussions of specific toolkits, etc.  I think they have
originated from beliefs that we are all talking about variations
of the same student-oriented GUI. In fact, we are talking about
much richer forms of pedagogy and interface.

D.

I know people that already play the game of 

collaboration: those I am

working with to bring bridges between their projects and 

SciViews-R.

There is another person working on general improvements of R for
GUIs: Duncan Murdoch, but this is about RGui.exe, thus 

for Windows only.

I support the proposition of Marc Schwartz to dedicate a 

session in

User!2006 to this subject... but I would like to precise this: it
should be stated clearly that the GUI session would 

*not* be about

discussing which graphical widgets to use, and *not* on the
presentation of yet another new R GUI project. That 

session should be

clearly focused on:
- actual examples of use of R GUIs, and the benefit 

their bring in

practice,
- propositions for developping a common and reusable API 

for R GUIs

(preferrably written in R to be independent of 

particular graphical

widgets -I started such a thing in svDialogs, and I 

think that Simon

Urbanek's Iwidgets is similar in philosophy-),
- bringing bridges between existing R GUI projects,
- identifying cross-platform opportunities.
That session should be followed by an extensive 

discussion (why not

around a drink, or a good meal?), between interested people. The
discussion should be best focused on:

1) How and who will install tools for collaborative work on those
common R GUI pieces of code (a CVS or SVN for 

instance)... we already

have a web site and the R-SIG-GUI, even if these tools 

are currently

under-used.

2) How and who will sketch documents summarizing our goals. Of
course, these documents should be editable by everybody. So,
something like a WiKi sounds good here.

3) In a near future, we will begin to add code in the 

"common R GUI

tools", of course. This should be pieces of code 

extracted from the

various R GUI projects. So, we have to draw an initial 

list of these

pieces of code and who will provide them.

I CC: this mail directly to the User!2006 organizing committee,
because it is a direct call asking for such a session. 

Regarding the

organizer,  I wouldn't propose names... someone from the R
developer's team, or a key person in R GUIs topics...
Best,

Philippe Grosjean

..............................................<?}))><........
) ) ) ) )
( ( ( ( (    Prof. Philippe Grosjean
) ) ) ) )
( ( ( ( (    Numerical Ecology of Aquatic Systems
) ) ) ) )   Mons-Hainaut University, Pentagone (3D08)
( ( ( ( (    Academie Universitaire Wallonie-Bruxelles
) ) ) ) )   8, av du Champ de Mars, 7000 Mons, Belgium
( ( ( ( (
) ) ) ) )   phone: + 32.65.37.34.97, fax: + 32.65.37.30.54
( ( ( ( (    email: Philippe.Grosjean at umh.ac.be
) ) ) ) )
( ( ( ( (    web:   http://www.umh.ac.be/~econum
) ) ) ) )          http://www.sciviews.org
( ( ( ( (
..............................................................

Marc Schwartz wrote:

Greetings all,

While recognizing that "this is easier said, than 

done", is there any

logic in suggesting that for those who might be interested, a
specific R
GUI session of sorts be added to the UseR! 2006 meeting 

schedule?

Since some quorum of interested GUI users may be 

planning to attend the

meeting or may be motivated to do so, it may be an 

opportunity to:

1. Leverage face to face interaction and visualize 

possible options

2. Define areas of commonality

3. Bring some level of focus to targeted segments of 

the user base that

would utilize a GUI and for whom there may be differing 

functional

requirements.

4. Identify cross-platform opportunities and technologies

5. See further notes below...


Some of the preliminary work could no doubt be done in 

advance to

better
prepare and structure discussion.

This could be done as a "breakout" session or if there 

is sufficient

interest (and facility/funding issues can be resolved) 

perhaps a group

session held the day before or perhaps the day after the main
conference
program.

If there is a core group that is interested in pursuing this, an
announcement could be made to the respective R e-mail 

lists (r-help,

r-devel, r-sig-gui, etc.) whereby, with the sufficient 

lead time as we

have, the requisite activities could be put in place to 

orchestrate the

session, define specific desired outcomes and identify 

individuals

willing to spend their time to coordinate and make this venture
successful (however success would be defined).

There is no business or financial motivation here for a 

GUI. If there

was and a for profit company decided that there would 

be a significant

return on investment, they would spend the money, hire 

the resources,

define a team leader and put forth a single development 

spec for a GUI

project based upon their own market research. It would 

be done in a

relatively authoritarian fashion and if you didn't 

agree, you would be

asked to find a job elsewhere.

Here, you would need to solicit voluntary resources, 

reconcile the

expected differences of opinion on the spectrum of 

matters that would

have to be addressed and define some common framework 

for operating,

perhaps based upon targeted user segments.

This subject, as mentioned, has come up on the lists previously,
with no
common resolution, resulting of course in the 

individual activities

that
have emerged.

Is there a group of motivated useRs out there, who have 

the time,

energy, and skills and are willing to work within the 

framework of a

design and development "team" environment, where a quid 

pro quo for

moving forward could evolve from the User! 2006 meeting?
Is there an individual, who would need to emerge from 

that group, who

has the respect and requisite skills to drive a 

consensus of opinion

and
keep a team focused and moving in the proper direction?

If so, that might be a step in the direction of 

evolving a GUI that

might make sense for some yet to be defined range of 

useRs, who would

not otherwise utilize the CLI or might need to evolve 

in that direction

over time.

If not, then the status quo continues...

There are some 300 Linux distributions out there and 

multiple X based

GUIs, which have evolved for reasons as varied as those 

behind the

available R GUIs and more. Yet there are a select few base Linux
distributions and largely two GUIs that have garnered 

any significant

market share. Perhaps, over time, lacking any 

coordinated activity, a

similar situation will evolve here, if the predicate 

that a broad

demand
for a R GUI is valid.

If the predicate is false, then this process is perhaps 

rightly done by

individuals meeting narrowly focused, local requirements.

I should note, that I am not prospective GUI user, but 

a happy ESS

user.
I simply thought that I would try to provoke some 

discussion on this

point, since I jumped into this thread earlier in the week.

Best regards,

Marc Schwartz

--
Duncan Temple Lang                duncan at wald.ucdavis.edu
Department of Statistics          work:  (530) 752-4782
371 Kerr Hall                     fax:   (530) 752-7099
One Shields Ave.
University of California at Davis
Davis, CA 95616, USA

- --
Duncan Temple Lang                duncan at wald.ucdavis.edu
Department of Statistics          work:  (530) 752-4782
371 Kerr Hall                     fax:   (530) 752-7099
One Shields Ave.
University of California at Davis
Davis, CA 95616, USA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDU+ta9p/Jzwa2QP4RAnppAJ9dv+LRlZttkmI8epiPrkU3aUsNjgCeIhGD
5bD+9bu3xIy6Oioy3a63JNo=
=s0yj
-----END PGP SIGNATURE-----