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

Thu Jun 4 18:10:30 UTC 2015

Hi,

On Wed, 3 Jun 2015 17:57:36 +0000 (UTC)
Jan Wort <d_jan at ymail.com> wrote:
> Hello RKWard Developers, 
> 
> We already mailed about some problems usability challenges with the
> optionlist-dialog. I took a look at the current problems and created
> some suggestions for a solution that might be easier to use. 
> 
> Core problem for the current optionlist is mainly the mapping: It is
> not easy to know which values from the table map to which gui
> elements and what the results of this are. This is as well 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:
> (http://imgur.com/bh9s9N6) so that is is easier to recognize what
> does what: The titles offer some natural language like accout of what
> is happening; The NA-coding is either a possible value or a checkbox.

ok, yes, that can probably be improved. But it's a mostly independent
problem. Let's get the optionset straight, first. (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).

> Still, that optionset has some problems on its own, mainly that
> (visually) the same controls are used for different valuesets (which
> you select in a space different from the controls: the optionset)
> 
> **So the idea was to "wrap" the sets visually somehow**. 
> 
> First idea was a tab-like approach: each tab has own values, own
> controls, so that would be clearer. However, a tab is small, and many
> values can be set via an optionset. It was unclear how a 100pixel
> length tab can be made to carry the right, unique and identifying
> information for (re) finding the right tab. Nevertheless, thats what
> it would look like: http://imgur.com/QuVVNbL)

Hm. I see. Too bad, that would have been very easy to implement...

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

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

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

Anyway, probably still looks like the winner-solution, indeed.

> In Regards to option-tables: I made some additional research and
> found that such controls are standards for attribute editing in IDEs
> like eclipse ("Table Cell Editor"); and that too-complex options
> could be represented in a pop up, as shown for the color selector.
> Mockup here:  http://imgur.com/HoUYTHB
> 
> So in summary: 
> * GUI of dialogs apart from optionset might be improved using current
> controls.
> * Optionset usability improvements may be:
>   * NOT tabs :(
>   * Popups like in SPSS (o.k. usability, versatile)
>   * Accordions (good usability, versatile)
> 
> 
> and as a different control as suggested by Thomas
> 
> * 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".

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20150604/9f80600d/attachment.sig>