[rkward-devel] item response theory plugin (and some more ideas)

[meik michalke]

hi,

Am Donnerstag 14 August 2008 22:04:46 schrieb meik michalke:
> my future plans are to develop additional dialogs for goodness-of-fit tests
> and ltm specific plot options (e.g. test information curves).

...and therefor i could probably use a new logic feature. i'd like to have a 
single plot dialog for several (if not all) models, but some plotting 
features are model specific, so they should be grayed out if unsupported. i 
could let the user define the model, but it would be more elegant to 
automatically check for the class of the data given for plotting.

the results of the irt model fit dialogs are stored in a R object in the 
workspace for further computing, each object is of its specific model class. 
as i understand what can be achieved with the logic section it's not yet 
possible to check the class of a chosen object, is it?

the workflow i think about would look like this:

open irt plot dialog
 -> select object with estimated parameters (varslot)
 -> if object in varslot is of class xy, make option a available
 -> if object in varslot is of class yz, make option b available
    ...

in xml:

<logic>
<convert id="modelxy" mode="equals" sources="variable.class" standard="xy" />
<convert id="modelyz" mode="equals" sources="variable.class" standard="yz" />
<connect client="optiona.enabled" governor="modelxy" />
<connect client="optionb.enabled" governor="modelyz" />
</logic>

 # # #

some other ideas:

- the more plugins evolve, the more likely you will end up with a menu 
structure full of entries you'll probably never need (i wonder how many 
people will find my own plugin useful). i'd consider it a loss of usability 
if the opening of a dialog became the search for the needle in a haystack. 
therefor i'd propose a new and simple configuration dialog (in the basic 
rkward configuration, plugin section) with checkboxes for each available menu 
entry. basically it should be a replication of the menues generated by all 
installed plugins, where the checkbox decides which is actually shown or 
hidden in the real menu. this might improve the usefulness of rkward in 
teaching situations as well, as you can give your students software with a 
reasonable set of features, and in later courses, simply add more dialogs if 
needed.

- in the long run, an online repository of available plugins could be more 
useful than installing them all by default. something like the script 
administration dialog of amarok would be neat ;-)

- in the "object to save to" field of the "import text/csv data" dialog of 
rkward 0.5.0b, it's a bit annoying that the cursor automatically jumps to the 
end of line all the time, and that the field is filled with "var" if you 
delete all letters to give the object a name on your own

- what do you think of a MAINTAINER file for the plugins, or something 
similar? or maybe as a last section of the plugin's help page (after 
technical)?

- dialogs persist after they've done their work. this is sometimes useful, 
sometimes it's not. i could use a configuration option to switch this default 
behaviour on or off, and perhaps an additional "keep dialog" checkbox near 
the submit button that should honor the default setting, but enhance 
flexibility

- and just out of curiosity: is there someone working on the windows port yet?


viele gruesse :: m.eik

-- 
  dipl. psych. meik michalke
  abt. f"ur diagnostik und differentielle psychologie
  institut f"ur experimentelle psychologie
  heinrich-heine-universit"at d"usseldorf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20080828/7cb40637/attachment.sig>