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
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________ RKWard-devel mailing list RKWardemail@example.com https://lists.sourceforge.net/lists/listinfo/rkward-devel