[rkward-devel] [JSS-Announce] Special issue on GUI's for R

Mon Jul 5 11:51:35 UTC 2010

-------- Original-Nachricht --------
> Datum: Sun, 4 Jul 2010 21:14:12 +0200
> Von: meik michalke <meik.michalke at uni-duesseldorf.de>
> An: rkward-devel at lists.sourceforge.net
> Betreff: Re: [rkward-devel] [JSS-Announce] Special issue on GUI\'s for R

> hi stefan,
> 

hi

> am Freitag 02 Juli 2010 (16:50) schrieb Stefan Rödiger:
> > first of all I did not come as far as I wanted.
> 
> that's a humble understatement, right? ;-) to say the least, your document
> is 
> much more elaborated than i expected!
> 
> > I had some troubles in first place to come up with empirical data
> (strange
> > for somebody in medical/natural science) which describe the GUI
> development.
> > Finally I came up with the idea to include metrics (download number,
> Google
> > hits, LOC development, internationalization and such) used in other
> research
> > fields.
> 
> i think this is interesting to know and worth documenting, but i must say
> i 
> agree with thomas that RKWards popularity is not a topic the paper would 
> *absolutely* need, if we ran into space problems.
> 

We wont run into space problems that is for sure. :) Again, I think sowing an increase of interest in RKWard by numbers and a growth of the software (LOC, ...) is a good and interesting thing. It supports that it is not just an one trick pony but much more and that there is a real and growing demand for this type of software. After all it is not a package as Rcmdr but it is more than statitistiklabor and it is likely to be come the only fully fledged cross platform GUI for R with both GUI and command line users in scope. But sure, this numbers are just supportive and not the main issue.

> personally, from the perspective of a reader, i'd prefer a rather compact 
> paper concentrating on the really important information over a longer one
> that 
> might lose its scope a little. shorter articles are more likely to be read
> by 
> even vaguely interested people, and you can always find out more if it got
> your attention.

You have got a point here no question. But don't miss the fact that there are only rare occasions were we can publish a peer-reviewed paper about RKWard.

> if i was the reader, i'd expect mostly to be shown what
> the 
> software can actually do for me, to see if it's interesting enough to
> download 
> and install it.
> 

I totally consent. This is actually the basic concept (that's also why I think we add use case scenarios).

> while i was reading i thought, one dimension to look at could be "things 
> RKWard did in the past", "can do already" and "is planned for a future 
> release". for instance, we could reduce RKWards former dependency on PHP
> to a 
> footnote, restrict all mentioning of future ideas (and problems) to the 
> discussion section and focus mainly the things RKWard does as of now.
> 

The only trouble I have with the "future" is that nobody can predict what it will be like. For example there was a time when only little development happened in RKWard or we claimed to work on a seamless integration integration with an office suit. This was when Thomas and Pierre worked almost alone. Later on more developers (manly for plug-ins) joined and we saw a huge leap forward in many plug-in parts but not on C++ level (accept from Thomas of course). Situation has changed but this was not predictable. Thus there is still a lot "we want to do this and that". Such claims need support by data or another foundation. Everything else is vaporware. Please don't get me wrong here but you know real live can be a killer for projects with such a structure. Therefore we really need to be careful. I would suggest to say state "future statements" like "As of writing this paper the feature ABC is checked into SVN and will be release after careful testing with the next release not covered here". But I might be wrong here. Anyways in all the other aspects I consent.

> given that the issue has its scope on GUIs for R, i'd assume that the
> editors 
> will introduce the topic themselves, so we could trim down the history a 
> little as well.

You are right. I thought the same. The history of R and some R GUIs was done elsewhere (some citations point there) thus I also think we don't need more there. The history of RKWard is only known to Thomas in detail. I think a brief description is sufficient here.

> 
> i too believe that menu structures and installation are not so important
> here.

Glad to hear this. BTW would there be a way to "extract the structure" automatically? 

> 
> that said, i'd rearrange the paper a little, so we wouldn't actually lose
> any 
> of the main topics you already included (which give a comprehensive
> overview):
> - start with a short introduction how and why RKWard came into being
> - show its core components (data editor, R cosole...)
> - core functionalities & features (data import, package management,
> graphics
>   window...)
> - technical background & plug-in architecture
> - comparison with other GUIs (could be a tabular)
> - discussion (incl. future plans)
> - appendix
> 

yes. let's stick with it for the moment.

> > Meik: You did a work shop with RKWard. Maybe this would be a good story
> for
> > a "use case scenario". Right now there are some places in the document
> > (results output for example) which illustrate use cases. More in other
> > places would be better.
> 
> sure i can come up with something, but i wouldn't go into much detail. but
> you're right, RKWard can be really helpful in teaching scenarios -- once
> it's 
> installed, configured and understood ;-)
> 

Great. Do you have any idea when your draft is finished?

> > One thing I still have trouble with is the overall statement of the
> paper.
> > Currently it is just a description of RKWard.
> 
> well, i wouldn't say "just". we are all used to it so we're not confused
> by a 
> workspace browser, R console and tabs with data management, results, help 
> pages and script editors (and we're not yet speaking of the wonders behind
> the 
> menu bar). but if you're new to RKWard -- which will go for most readers
> of 
> the paper --, this can be quite puzzling. at least that's what a got from
> my 
> use case scenario ;-) i believe, if we just manage to show RKWard as it
> is, it 
> will definitely speak for itself :-)

Okay my point of view is biased of course since I'm well used to RKWard. I'm glad that we have external views.

> 
> you asked yourself why not everyone uses RKWard. probably it's the need to
> understand it first. therefore i'm sure it's worthwile to keep this 
> understanding as the overall statement.
> 

Yes you are right. As long as we don't make it a user manual completely. But I'm sure we wont. We all see the outermost importance of the technical part. Spreading the word about the great GUI plug-in structure is in my opinion one other main issue.

> what do you think?
> 

I think we all consent.

> 
> viele grüße :: m.eik
> 
> -- 
> dipl. psych. meik michalke
> institut f"ur experimentelle psychologie
> abt. f"ur diagnostik und differentielle psychologie
> heinrich-heine-universit"at 40225 d"usseldorf

-- 
GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl.  
Bis zu 150 EUR Startguthaben inklusive! http://portal.gmx.net/de/go/dsl