[rkward-devel] feedback

Fri Nov 21 09:39:48 UTC 2014

Hi,

> here's some feedback from the presentation, reduced to the parts where
> they'd welcome some improvements:

on a general note, we really have a bit of a problem tracking all these ideas 
in a decent way. Do use the feature tracker, for now. But we should also work 
on prioritizing ideas, some way.

> - in the workspace browser, "show all environments" should not be checked by
> default, so you only see "your" objects in the worksapce. actually,
> unchecking that box is one of my first actions after a new installation as
> well ;-)

Ok. Done.

> - in the code veiw, the whole printout section was seen as problematic (at
> least in this context), as it wasn't really clear to anyone that this is
> just what makes the RKWard output. i remember i asked for some options to
> configure this part myself a while ago. no idea how to deal with it.
> perhaps a more explaining comment would help, like "the calculation is done
> at this point; the following code generates the output", or so.

Hm, I can absolutely see the point. However we should also avoid adding _too 
much_ additional wording. That just makes things look yet more crowded, IMO. I 
can see two angles to attack this:
1. As you suggest a better comment. But let's keep it somewhat concise, i.e. 
perhaps just "## Printout: The following code generates the output". And 
similar labels for the other sections.
2. This would really be something to highlight in a short intro to working 
with RKWard. Our "RKWard for Newcomers" page in the wiki is not so terribly 
helpful, I'm afraid, and rkward_for_new_users.rkh could definitely use some 
improvements, too (including screenshots)...

> - the regression dialog should be enhanced. we were recommended to look at
> RCmdr's regression module for something they'd love to see in RKWard.

Yes, true, it's totally basic, so far.

> - in general, they wished for a more obvious workflow regarding what can
> further be done with results from some analysis (say, you have just
> estimated Rasch parameters, but no clue that there's a particular plot
> option for that in another branch of the menu). this wish is a bit harder
> to fulfil, of course, but i had two ideas to enhance the situation: the
> first approach would use the "run again"-link feature to recommend common
> follow-up analysis steps in the HTML output, like pairwise t-tests after
> ANOVA or special plots. however, this would limit the availability of
> recommendations to what the original plugin author could think of, and we
> don't even know what happened to an object after the dialog was closed. the
> second approach would be to implement a new entry in the workspace
> browser's context menu for objects, say "next steps". depending on the
> object class, it would list copies of the main menu structure (like data,
> analysis, plots) which are particularly useful for this object class. the
> mapping for this would have to be defined somewhere, perhaps in the dialog
> XML code, or more centralised in the pluginmap. this way, the
> recommendation would also be available for objects made with other plugins
> and even scripts. where possible, the regarding object could be pre- filled
> into the appropriate dialog field. it could be limited to "what you'd
> usually want to do now", if that can be figured out...

Hm, ok beefing up the workspace browser is one sensible idea (may even be in 
our tracker, somewhere, at least the general idea came up, before), and 
probably not too hard to do. Essentially we'd have to make it so plugins can 
"suggest themselves" for certain classes of objects (and also specify, where 
that object would be filled in).

But I'm not quite sure how far that approach will help in practice. It will be 
much more meaningful to give suggestions for "special" objects, such as fitted 
models. Not so much for plain numeric vectors, although these could represent 
the same concepts (e.g. a vector of residuals). Arguably, of course the latter 
may not need quite as much explaining, in the first place.

A different problem is that it may not be easy enough to discover: You first 
have to actually create the object that may be of interest for further 
investigation (and that simply can't be the default behavior in _every_ 
relevant case). And then you'd still have to find out that a context menu (or 
something) in the workspace browser will give you hints on how to proceed.

So again, documentation could be a second angle at this. For some sets of 
plugins (and I'm thinking of the IRT plugins as a prime example). I think a 
sort of "vignette" would really be useful, i.e. a separate help page giving an 
overview of what is available, and the workflow to use it. We don't have 
dedicated support for this, ATM, but it could be done today, by creating 
"dummy" plugins that don't actually contain anything (but do have a help 
page), and are not placed in the menu. Then you could link to their help page 
in the usual way.

But also to spin your idea of "follow-up" links in the output window some 
further: These recommendations would not necessarily have to come from the 
(first) plugin's author. We could define a sort of "follow-up" database 
consisting of:
- id of plugin (and pluginmap) a
- id of plugin (and pluginmap) b
- relationship ("b is a follow-up to a", "b is an addition to a", "b is an 
alternative to a")
- comment (potentially containing instructions on what options to check)
(optionally this could also contain pre-selected parameters, but this might be 
exposing too much of each plugins internal workings, and thus could break, 
easily)
Entries to that database could be defined anywhere, not just along with plugin 
a. 
This would allow to provide "follow-up" information, dynamically. This could 
be linked to next to run again (automatically, of course), but could also 
replace some (most/all?) of the current <related> section. Doesn't sound too 
challenging, technically, IMO. The key question would be, whether we can 
compile enough, and good enough information to make this a useful tool...

> overall i think they really liked RKWard already, and highlighted stuff like
> the possibility for pluginmaps to be disabled, especially in a teaching
> context.

Great (and no, I still haven't forgotten to give you more options for "plugin-
enabledness-manipulation").

> well, and there seems to be a problem with our bundle and OS X yosemite :-/

Symptoms?

> but one problem can be marked as "done":
> - the factor analysis plugin should gain support for the MAP criterion, so i
> wanted to get started with a dialog for psych::VSS() some time soon. i just
> saw now that i already did this :-D i must check if that version has not
> been released yet...

Yes, it's funny the stuff that you find, when you come back visiting your own 
code after some time ;-)

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20141121/2d52b22f/attachment.sig>