[rkward-devel] plugins: optionset; use and usability

[d_jan]

Hi RKWard Devs,

(Scroll way down for summary)

Am 04.06.2015 um 20:10 schrieb Thomas Friedrichsmeier:

> On Wed, 3 Jun 2015 17:57:36 +0000 (UTC)
> Jan Wort <d_jan at ymail.com> wrote:
>> [SNIP] …
>> related to
>> the GUI connected to otionset and not only a problem of the optionset
>> control alone. 
>>
>> E.g. the recode GUI could be redesigned like this:
>> […SNIP]
> 
> ok, yes, that can probably be improved. But it's a mostly independent
> problem. Let's get the optionset straight, first.
sure

> (BTW, originally I
> played with making "NA" a value to select in the "old values" list, but
> that posed problems as it needs rather separate handling, internally.
> Also there is the - corner case - problem of distinguishing it from
> literal "NA" strings. So that's why arrived at making it a
> radio-option. Checkbox would work as well, of course).

ah, good to know. I came across the quoting/non-quoting stuff as well,
in my case in terms of usability (it is probably an instance the
question of how close the GUI should be to the underlying system)

> 
> [SNIP]
> 
>> A rather simple solution would be to provide the GUI for controlling
>> the values in a pop up. Thats how SPSS is/was doing it. It is clear
>> what does belong to what, but it is not very elegant.
>> (http://imgur.com/fabT823).
> 
> Yes, that always felt a bit clunky to use. I can't quite put my finger
> on it, but perhaps it has something to do with having something "all
> new" (the popup) appear for each item, having to re-orient myself over
> and over again.
> Just for brainstorming, though: Suppose we leave everything as is,
> but _add_ an "Edit" button to each row in the display that will simply
> activate that row. Possibly add some other visual cue (suppose a thin
> frame that flashes, briefly) to highlight where editing takes place...
> Would that solve most issues? (Note: a "delete" button could be added
> in this solution, too).

Hmm... It is unclear how much we can win by that approach. Core problems
with mapping/orientation for the user would sadly remain.

I don’t know how much additional work popup windows are, but they would
be my way to go, if they are easy to implement. They are not fancy and a
bit cluncky, but they are familiar (= "intuitive"), provide a sense of
what-I-do-right-now and are reliable "workinghorse" controls.

Either way, it makes sense to map the "delete button" to the items
themselves (even if that takes a bit more space) – that would make the
result appear where the input happens.

> 
>> A better solution which combines the display of several values, gives
>> easy access to editing them and provide a recognizable grouping could
>> be the use of an "accordion" control. It would look like this:
>> http://imgur.com/52pOvCr
>>
>> It combines several advantages: 
>> * It provides a clear structure
>> * enough space in the accordion’s title to show several values (for
>> recognizing/identifying)
>> * it is clear which set of elements is selected (visually grouped in
>> the accordion boxes) 
>> * the sets can be deleted directly (no select row, than delete). 
>> * The accordion is a standard control and not something unusual I
>> made up myself. 
>> * You can create any GUI inside the accordion(s), as it is "just" a
>> container. (one would define the GUI only once; it would be repeated
>> in all accordions of the "accordion-optionset")
> 
> Ok. I can see the merits of that solution. But it seems somewhat
> non-trivial to implement. I'll have to read up on ways to implement this
> some more.
> 
> One caveat in our case is that in reality there can only be _one_
> underlying widget. We can probably make it look like separate
> expandable widgets, but for instance, it will not (easily) be possible
> to have two editor widgets expanded in the same optionset. So that's
> one constraint.
> 
> Another thing that is not quite clear to me, yet, is how we will
> best handle the sizing. It may (or may not) be a good idea to make the
> implementation _always_ show exactly one expanded editor widget
> (disabled in case there are no rows), in order to avoid dynamic
> resizing troubles. But in any case, we can't predict, how many items
> there will be, but we still have to decide on some minimum / default
> size. Any better ideas than making this something like editor height
> plus four rows?

Clarification needed: I’m not into the technical details and constraints
here – is minimum/default size referring to the height of an opened
accordion element?

> 
> I'm slightly concerned that scrolling the whole thing
> (including the editor widget) will feel somewhat clunky, when
> required. I'm thinking it will probably make sense to implement
> scrolling in a way that will make sure the editor widget is always
> visible in full, i.e. scrolling will "flip" through the accordion
> somehow ... 

That way of thinking makes totally sense, however by automatically
opening stuff while scrolling, we get again the problem of "where am
I"/"What is this". This would be no problem at all with scrolling though
images or the like, but our stuff looks very similar (harder to orient on)

> and then I'm scratching my head wondering how I can achieve
> that. (OTOH, in typical usage, users will work their way from top to
> bottom on merely a handful of items, and rarely have to scroll). Any
> additional ideas / input on this?
Clarification needed: Are you referring to ideas of how to avoid scrolling?


> Anyway, probably still looks like the winner-solution, indeed.
> 
>> [SNIP]
>>
>> * Tables (even better usability, less versatile) 
> 
> Yes. But again, I'd like to focus on the optionset, first, before
> making any detailed plans on "option tables".

sure.

SUMMARY:
So based on my experiences:
Fixing the current optiontable approach (table+changing values in a form
below) is hard (aka I have not good idea though we tried)

Things to consider:
- Accordions are imho a pretty good solution, however, they seem to be
difficult to implement in a way that makes them work well as far as I
understood.
- If popups are much easier to implement, we should consider doing that,
since they are reliable and have imho good usability apart from being a
bit clunky.


Regards,
 Jan