Hi, Sorry, in brief: I think the problem of mentally/visually connecting the target to the list of possible elements exists, but my suggested solutions don’t make much sense (except the coherent positioning), I see.
> I'm afraid I can't quite picture what you mean, or how it would help. > Perhaps I'm looking at different dialogs... > What I meant with incoherent positioning were probably the dialogs for plots like - Barplot (in which the grouping factors are on top, but the frame these factors concern are at the bottom(?)) - Pareto (same layout as barplot) - Boxplot (some options on top) (Now discarded) Solution: A line does not make much sense, cause some of the picker targets are not/can’t be on top, as you say, > except: > - If a selection is only needed subject to certain other settings, the So for now it may make sense to change the plot dialogues, but otherwise I need to make up my mind about a solution that actually solves the problem so leave it like it is :) Kind Regards, Jan Am 03.10.2015 um 22:09 schrieb Thomas Friedrichsmeier: > Hi! > > Next round: > > On Tue, 29 Sep 2015 18:45:05 +0200 > jan <[email protected]> wrote: >> … 2nd Usability issue >> >> Problem: The data picker target (the field you "put" the selected >> value from the list of data objects in) belongs function-wise to the >> list of data items and the green "put it there" button(s). Because of >> constraint space it is often placed on top or below other options. In >> this (frequent) case, it (visually) groups with the other (not >> directly data-picker-related) options, rather then the data picker >> list and it’s button. >> >> Proposed fixes: >> a) A line (like HTML’s <hr>) to devise the data picker target from >> other options > I'm afraid I can't quite picture what you mean, or how it would help. > Perhaps I'm looking at different dialogs... > >> b) A coherent position for the data picker target. It sometimes >> appears below- sometimes on top of other options. It would be great >> to have some coherence, since it would ease learning and make other >> (more complicated) fixes less needed. > I think the - unwritten - ruleset is currently: > - Data picker target (<varslot>, technically) goes on top, except: > - If a selection is only needed subject to certain other settings, the > <varslot> is directly below those. Example: File->Export->Export > Table / CSV, the "Rows and Columns" tab. > > Whether or not the above is a good ruleset, there are - very few - > plugins that violate it, as far as I am aware. Examples I have found > are: > > - Analysis->ANOVA->ANOVA (from rk.ANOVA), mixing "Design" in between the > <varslots>. That still makes some sense to me, although it may be > possible to move "Design" to an entirely separate row on top of > everything (including the data selection list, aka <varselector>). > - Analysis->Means->t-tests->Pairwise t-tests, placing "Data format" > first. Again, it might make sense to move this "even higher" as in > the "t-Test" plugin in the same menu. > > I assume you had in mind more problem cases than just these two. Could > you give some examples? > > Regards > Thomas > > > _______________________________________________ > rkward-devel mailing list > [email protected] > https://mail.kde.org/mailman/listinfo/rkward-devel
_______________________________________________ rkward-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/rkward-devel
