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

["Stefan Rödiger"]

-------- Original-Nachricht --------
> Datum: 4 Jul 2010 14:14:13 +0200
> Von: "Thomas Friedrichsmeier" <thomas.friedrichsmeier at ruhr-uni-bochum.de>
> An: rkward-devel at lists.sourceforge.net
> Betreff: Re: [rkward-devel] [JSS-Announce] Special issue on GUI\'s for R

> Hi,
> 
> On Friday 02 July 2010, Stefan Rödiger wrote:
> > first of all I did not come as far as I wanted.
> 
> well, you got a lot further than I would have expected. Great work!

thx

> 
> > Moreover my provider has
> > technical issues. Thus I can not use svn.
> 
> Ok, we'll see if we can come up with a solution. Does anybody have an
> option 
> to set up an FTP-server in an uncomplicated way?

as stated in the private mail. We can stick with the old plan (SVN). In 1-2 weeks all will be back to normal.

> 
> > However, I think we will get a very interesting story. I please you to
> have
> > a look into the document till Friday next week (or give me feedback how
> > long you need). Please use the change tracking tool of OOo
> > ("Edit/Changes/Record").
> 
> I'll focus on providing content for the technical section(s). I'm not sure
> whether I can promise to make it by Friday, but I will try.
> 

I just need to take care of our "schedule", therefore the short time frames (but no need to stick stricktly to them). December isn't that much time at all. ;)

> > Figures are mostly place holders but should give a good impression of
> what
> > will be there at the end. 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. This will
> > distinguish us from other papers in this field but will also help to
> > understand why RKWard is where it is and what it is.
> 
> My overall impression is that the paper will end up pretty long, and I
> expect 
> we will need to trim it down in the end. 
> 

As far as I know there is no length restriction. http://www.jstatsoft.org/instructions#policy "Issues". We certainly should use this opportunity (reasonable) since this might help in other places.


> At the moment, I do not quite see which conclusion(s) we could base on the
> empirical data, and whether those conclusions are central to the paper. 
> Currently my impression is that including empirical data is a nice idea,
> but 
> when thinking about where we could trim, cutting this out would not hurt
> too 
> much.

One conclusion I would try to support with the data is that RKWard is holding a certain level or is growing (code and community wise). This relates somehow to available help (mailing lists, forums, ...). Best is we can show that RKWard is growing. We could also include a graph of the releases which is a big question for institutes which want to adopt RKWard. The same applies to needed fixes if a new version of R appears. I can remember troublesome times in the past.
GUI metrics is also an issue. Somebody stated that an useability issue is a bug and we want bug free software. But as stated in my previous mail it will just be supportive.

> 
> Regardless, here are some further hints:
> - Ohloh has some interesting metrics, indeed, but for some reason they
> stopped 
> updating their info on RKWard in 2008.

They were bought by SF as far as I know and Ohloh will be stopped anytime soon.
The source is fine but in principle we can use our own data. But I'm not sure how much work this is.

> - It's not easy to come up with good download numbers. You probably know 
> http://sourceforge.net/project/stats/detail.php?group_id=50231&ugn=rkward&mode=week&type=prdownload
> , but it lumps together the different file types, and does not include
> numbers 
> from distributions/other sources, making it hard to interpret.

Yes I know this source. There is even a updated statistics interface from SF.
But I'm also aware that the numbers have limited meaning and are hard to interpret. Still we can try to see if there is a relation between a public announcement (new release) or alike. I never really tried to use the data.

> Data from
> the 
> debian popcon may be most interesting: 
> http://qa.debian.org/popcon.php?package=rkward .
> 

Thanks, I was searching for exactly this.

> > Thinks like exact
> > menu structure are not so important in my opinion (may find a home in
> the
> > appendix).
> 
> Agreed.
> 
> > I have also some other things in mind (in especial usability
> > metrics, form factor) but I need to gain some knowledge (reviewing
> > literature, talk with an expert). Content wise I wrote down some
> thoughts,
> > took information from the mailing list or the RKWard wiki (hope this is
> > okay).
> 
> For larger chunks you may want to check who wrote them, so we can give
> credit 
> to those who are not already on the list of authors.

no question, sure we will.

> Some of the technical
> info you copied is a bit outdated... I'll comment / rewrite in the .odt.

great. I think this is also good for our general documentation. Moreover having updates on technical issues means progress. The question is whether it means something to R and RKWard in respect to the paper. I envision always something like "we did it that way, evaluated it and found this particular better solution".

> 
> > I have also found a bunch of literature (something like 20
> > citations ("lit_02072010.html") right now) from peer-reviewed articles
> and
> > other documents (books, abstracts, …). We certainly can cite more. How
> to
> > install RKWard exactly is not so important in my opinion. This should be
> > rather short, since there is a wiki, packages of different distros and
> the
> > read me.
> 
> Agreed.
> 

glad to hear this

> > The chapter "Structure of RKWard - Technical Design Overview" and
> > "Programmer’s Niche – Extending RKWard" are certainly very, if not
> most,
> > important. Best would be to satisfy many parties (the one who wants to
> > know how it works, and the other who wants to know how to code a GUI
> > plug-in).
> 
> I suggest relabelling the "Programmer's Niche" as "RKWard Plugin Example",
> and 
> to move it to the Appendix, with a reference from (a sub-chapter of) the 
> Technical Design Overview-chapter. I think both sections are closely
> related.

agreed.

> 
> > One thing I still have trouble with is the overall statement of the
> paper.
> > Currently it is just a description of RKWard. But it mustn't end here.
> The
> > editors asked for papers which discuss GUIs in statistics and R (that
> > where we make currently no comprehensive point), implement toolboxes
> > (that's where we fit well), GUIs for the desktop or cloud (that's where
> we
> > fit good) and other features R should have (that where we currently make
> > no point). But we will get there.
> 
> I think it is not mandatory to cover *all* of these points.

sorry, I didn't intent to say we need to cover all points. I just wanted to point out that we should focus (with a comment were we have a lot to tell currently).

> I will try to
> give 
> special attention to the reasons for some design decisions in the
> technical 
> section.

This is great.

> 
> Regards
> Thomas


Regards
Stefan
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01