[R-gui] (renamed) What do we do?

[Thomas Friedrichsmeier]

I must admit, I'm not quite as adept at statistics as you are (or as likely 
most of the people on this list are), so I can't respond to everything, but 
some things I can answer:

> To be explicit, the components of the t-test that I'd like to see, to
> make this a non-trivial example (scalable to the level of the
> analyst), would be:
>
> 1. specification of the groups (2 variables, vs. 1 response and a
>    grouping variable).

In the draft: <varselector>, <varslot>. I admit, there's no yet a tag to 
represent a widget to select one or more specific values from a nominal-scale 
var (if the grouping var is not 0-1-coded), but that's not a problem in 
principle.

> 2. specification of the variance estimate (and corresponding adjustments)

<input>, <radio>, <checkbutton>, <select> or <optionselector>

> 3. approaches for resampling - data, model based.

I was rather thinking of using a separate dialog, but it's no more than a few 
options-tags plus a bit of code in the <code>-section to realize this in a 
single dialog.

> 4. approaches for sensitivity analysis (related rank-based tests,
>    related 2-sample based likelihood based tests, using both same and
>    different probability models, additions of noise or resampling, ala
>    Gary King's Clarify).

Various options-tags (see 2), no? Potentially some rather complicated stuff in 
the <code>-section, but no more complicated than any individual solution 
would have to be.

> 5. a "dial-o-meter" (I don't see it as 1-d, but not sure what the
>    right interface would be) to control the flexibility inherent in this
>    (buttons, help settings, link-outs) based on user's skill level,
>    needs, wants, etc.

Depends on what exactly you mean by this. I can think of three approaches 
(solving different problems), only one of which would require an extension of 
the specification-draft:
1) As long as it doesn't touch the core functionality, it's entirely the 
applications responsibility (to e.g. offer transformations to be applied to 
selected objects, or not), and the application would provide that 
"dial-o-meter" (in the dialog itself or in a "global" place), no need to put 
something like that in the spec.
2) Simple but probably quite feasible approach: Put extended options into a 
separate <tab> (whatever your app thinks a <tab> should look like, no need 
for it to really be a classical tabwidget). Probably rather reasonable 
anyway, when we're talking about dialogs with potentially _lots_ of options.
3) Extend specification to include "level"-attributes for all "widgets". 
Application would decide (depended on user setting) which level of widgets to 
show and simply assume default values for widgets below that level. Other 
than than, see 1). There's no problem with adding this to the specs. We'd 
have to agree on rough landmarks in the range of levels to use (potentially 
multi-dimensional, but dimensions would need to be defined beforehand).
Some toolkits may have trouble showing/hiding widgets on the fly (Qt handles 
this like a charm, but I'm not sure, how some others will be doing), but in 
these cases, it's not a problem of the specification, but would also apply 
when trying to find an individual solution.
If you want something similar for the help-settings, I propose to use either 
#targets (current proposal is to use HTML for the help), or several 
help-sections with different "level"-attributes. The application would know 
which target to jump to preferrably (once again based on user-settings). This 
would of course require the plugin-author to provide multiple versions of 
help, otherwise the setting will not have any effect. But this is no more 
complicated than any "individual" approach.

> I don't think that constraining the data format, i.e. #1, would be
> useful; it is precisely the issue being addressed with the GUI. #3/#4
> start to become novel, at least they were when others proposed them.

Ok, but these really only require a more elaborate <code>-section, no? I mean 
there's nothing fundamentally new in the GUI, or is there?

> #5 is what I'm hoping to see in your description of the layout,
> Thomas, i.e. a statistical rather than computational description.  I'm
> not seeing it at this point, but maybe I'm being obtuse.

Not quite sure, whether you're satisfied with my answers, but I'm open for 
proposals. After all, it's only a draft. I'm very convinced that we should 
use something along these lines, and at some points I have strong opinions 
about what should _not_ go into the draft, but I'm definitely open for 
discussion of improvements/extensions/changes.

> I don't see what you are doing as particularly novel -- in fact,
> numerous parts are possible as very simple extensions of ESS or
> (X)Emacs tools (such as the S-Spreadsheet tool from the mid-90s, or
> the widget and image tools that have been available for a while).
> But to each, their own toolset...

It's not very novel, indeed, and it's not innovative at all. The differences 
to the approaches you mention are that 1) it's relatively easy on the 
plugin-writer, esp. as far as the GUI-side is concerned (one of the major 
reasons I wanted to have something like it in the first place), 2) it's as 
you say not depended on a specific toolkit (and independency from specific 
toolkits is a definite prerequestite, if we want something useful to all of 
our projects!) 3) it is meant to allow for easy fallbacks, so that an 
application, that e.g. does not understand the newly introduced 
"level"-attribute is still fully functional 4) it is designed to leave some 
freedom of look-and-feel-and-functionality to the application.
2) is probably the most important point, but IMHO, the others deserve 
consideration, too.

> But #5, if you can figure that specification out...!

How did I do?

Seriously, I see you have some very interesting ideas, that I did not think of 
and would not have thought of. Also chances are, that new ideas will come up 
late in the process of trying to agree on a specification, some of which 
might not be easy to incorporate (although I'm quite optimistic).
Still, don't you agree, that if we could find a solution that could cover if 
not 95% then at least some 60% of "standard" problems, a lot would still be 
won?

Thomas