[rkward-devel] ANOVA plugin

[meik michalke]

hi,

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:
> ANOVA:
> - 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, 
isn't it?

> - For purely between designs, is it really necessary to specify
> a subject id? Could this be made to default to rownames (x) or something
> similar?

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:
 o https://github.com/mike-lawrence/ez/issues/1
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?

sure, done.

> - 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.

> General:
> - 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 
in svn).

> If you don't like the looks of that, fix pages/rkward_output.css, and / or
> rk.header()

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
> output.

totally makes sense.


viele grüße :: 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: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20111021/66213185/attachment.sig>