[rkward-devel] Optionset UI rework (was: Usability progress, testing on Mac)

[d_jan]

Hi Thomas,

> Splitting this into a new thread to make it easier to follow. I have
> now merged the optionset UI rework into "master"

great!


>> - Klicking on the + only would be…

oops. some characters got lost. anyway, it has low priority I think; it
were some thoughts on the interaction to open the options.


>>  - There should be some "visual coherence"…

attached a mockup of a possible style, which helps the user to navigate
the optionset better (in particular, it hopefully shows how a row and
the gui for setting the options belong together; there are as well some
suggestions to make it more similar like guis people know)

I could describe the changes here, but it is much easier to read them in
the pdf with the graphic aside.

Jan





Am 30.10.2015 um 17:42 schrieb Thomas Friedrichsmeier:
> Hi!
> 
> Splitting this into a new thread to make it easier to follow. I have
> now merged the optionset UI rework into "master", which means it will
> start being part of the daily builds, tomorrow. To follow more closely,
> in your git clone, simply do
> 
>   git checkout master
>   git pull --rebase
> 
> (Only the second line is needed to fetch updates, later).
> 
> State now, and open questions:
> 
> On Thu, 29 Oct 2015 14:13:02 +0000 (UTC)
> Jan Wort <d_jan at ymail.com> wrote:
>> - + and x in the Table:    - great to have a delete button on every
>> element    - delete button should be in the last "column" instead of
>> the frist
> 
> Done.
> 
>>     - the + is not needed on every element the + on the bottom of the
>> list is sufficient
> 
> Done.
> 
>> - Love the fold/unfold mechanism: details and
>> overview in one Interface!
>> - Klicking on the + only would be o (instead of the whole row, which
>> is unusual and thus hard(er) to remember). Or, as alternative fix:
>> make the whole last row highlight on hover, to signalize that it can
>> be clicked
> 
> Not entirely sure what you have in mind (and not quite sure, which
> version you were looking at; this had some last minute formatting
> changes around the time you had a look).
> 
>> - The + and x buttons at the bottom can go. They are not
>> needed and confuse imho.
> 
> Yes, these were just a leftover. Done.
> 
>>  - There should be some "visual coherence" of
>> a row and it‘s edit view (that the row one opened and the fields in
>> the detail view belong together), and a (minor) seperation from the
>> opened row/its details from other entries. Is there a way to style
>> the table/Tree, possibly with horizontal lines or a background or
>> both? (just tell me what is possible, and I try to come up with a
>> solution in this constraints)
> 
> See my other mail.
> 
>> Other Sets (B, connected, driven):- I
>> prefer A (the 1st) over B vor various usability and efficiency
>> reasons.
>> - I did not test the Connected and the driven set, but they both seem
>> o.k., it would be a nice addition if clicking the variable (in the
>> picker) would open the corresponding details in the optionset (so the
>> users sees that they are connected)
> 
> Can probably be done, not done yet. Will probably also need some
> per-plugin code (i.e. plugin authors will have to enable this feature,
> explicitly).
> 
>> - In a similar direction: We
>> should get rid of the # in the option set or include it in the
>> variables-part of the picker too, so the user can connect these two
>> lists mentally more easier (since they look more similar than)
> 
> The index column is now hidden by default (and in fact, at the time of
> the writing, there is no way to enable it). The interesting question is
> whether there is any use-case where the index column is actually
> helpful. Otherwise I'll just rip it out.
> 
> Originally, I had added it, thinking it would be helpful to indicate
> that rows would take effect in a specific order. E.g. sort first by
> row "1", then by row "2", etc. Now that may still be rather
> self-explanatory without an index column. Would anybody miss it?
> 
> Regards
> Thomas
> 
> 
> 
> _______________________________________________
> rkward-devel mailing list
> rkward-devel at kde.org
> https://mail.kde.org/mailman/listinfo/rkward-devel
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rkwardOptionsetUIesign.pdf
Type: application/pdf
Size: 77289 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20151030/a1735e07/attachment-0001.pdf>