[rkward-devel] Position of Data picker target

[jan]

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 <d_jan at ymail.com> 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
> rkward-devel at kde.org
> https://mail.kde.org/mailman/listinfo/rkward-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20151004/cf7549d5/attachment.html>