thanks for the feedback!. i also have some rather general questions on this:
- would it be a better solution to split things into smaller entities, i.e.
separate the ANOVA from the t-tests and have two plugins (rk.ANOVA could
still draw in the other as a dependency)?
- should plugin requirements better be handled as package suggestions (not
dependencies)? ez really needs a few other packages, but we could postpone
the actual installation "RKWard-like" to the moment when you're actually
running a dialog for the first time. that way, you could have a quick look
at new plugins without installing everything it could probably use.
- should we recommend some sort of naming scheme for pure plugin packages,
so they're easier to recognize in the R libs directory? i used "rk.*" on
this one, but it could also be "RKWard.*", "Rk*" "rkward*" or whatever.
Am Freitag, 21. Oktober 2011, 12:27:23 schrieb Thomas Friedrichsmeier:
> - The "Data" varslot could be made to default to the current data.frame
cool, done. "current_object" is only mentioned as an example in the docs,
> - For purely between designs, is it really necessary to specify
> a subject id? Could this be made to default to rownames (x) or something
in theory yes, i can add some logic to set "required" only if within is not
empty. but ezANOVA currently seems to have a bug here:
so, i can only really test this when 3.0.1 is out.
> - I'm not entirely sure, how this would work out, but have you tried
> swapping the "Model"-options and those options which are currently on the
> first tab?
yeah, i'm not really happy with that either. maybe i should also add a
between/within/mixed model chooser to not bloat the dialog. the multi-varslots
occupy a lot of space if they're not needed.
> Pairwise t-Test:
> - The R default for p.value correction is "holm". Perhaps the plugin should
> use the same default?
> - Ideally, the plugin would support both wide (separate variables) and long
> (outcome + group variable) format. Perhaps a generic conversion facility
> would be a good candidate for an embeddable plugin, since this would come
> in handy in many places. (See box plot for an example of a plugin that
> already supports both formats).
sounds good, will just take a little time.
> - All your rk.header()s start at level=2. For consistency, they should
> start at level=1
ok, that was an issue in rkwarddev (rk.JS.doc()), will be fixed in 0.04-2 (is
> If you don't like the looks of that, fix pages/rkward_output.css, and / or
yes, for my taste the header fonts are much to huge, compared to the normal
font size. could need some tuning, indeed.
> Having consistent levels of headings will become particularly
> important, once we add table of contents / navigation features to the
totally makes sense.
viele grüße :: m.eik
dipl. psych. meik michalke
abt. f"ur diagnostik und differentielle psychologie
institut f"ur experimentelle psychologie