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

[d_jan]

Am 05.06.2015 um 20:58 schrieb Thomas Friedrichsmeier:
> Hi,
> 
> On Fri, 05 Jun 2015 12:41:22 +0200
> d_jan <d_jan at ymail.com> wrote:
> [...]
>> 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)
> 
> in essence: Yes. But in particular for selecting existing values, it is
> somewhat difficult to go too far away from the underlying system. (Not
> saying it can't be improved at all).
> 
> [...]
>> 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.
> 
> Popup windows would be very easy to do. Perhaps I will try that, just
> to get a more hands-on idea of how it would feel.

certainly worth a try.

> But I have not given up on your accordion idea, yet. Sorry if I'm
> sounding overly sceptical, here. It's simply that any implementation of
> the accordion will mean a good deal of work. That seems quite worth it.
> But because of this I'm trying to anticipate a couple of problems
> _before_ putting effort into a particular implementation, only to find
> out, I should have taken a different path at the start.

makes sense. I just wanted to take into account the difficulty of a good
implementation, thats why e.g. I suggested the popup alternative.

> 
> [...]
>>> 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?
> 
> This, and the height of the closed elements combined. The latter is the
> hard part, because we can't predict, how many elements there are going
> to be. So we can't entirely avoid the situation of having blank space
> below the (complete) accordion (ok, that one is not a major concern),
> and the situation of the accordion growing beyond the space available
> in the dialog.
> 
> (The constraint I was talking about is a somewhat separate, and
> probably rather minor issue: We'd probably have to implement it such
> that exactly one element of the accordion is expanded at any time.)

interesting constraint. I am not sure if/how problematic this might be,
but it would give an arbitrary element some sort of highlight in the
case the list is prefilled.

> 
>>> 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?
> 
> Either that, or alternative ways of making scrolling work nicely. Or -
> if that is warranted - some reassuring words that scrolling will only be
> needed in corner cases, and users won't despair, even if the entire
> accordion gets scrolled.

If the space available for the accordion elements (an expanded form and
>3 collapsed ones) that should be o.k. Scrolling is usability wise not
too much of a problem if it is easy to recognize that one can scroll.

However, if there needs to be one element to be opened all the time, I
suppose we need to expect that scrolling will be needed.


> 
> And on second thought: Did we possibly discard the finger-tabs too
> early? Note that we would be free to re-arrange the options a bit,
> towards a taller but less wide layout, i.e. making more room for the
> tab labels. And perhaps in general the tab-label would not have to be
> all _that_ long to allow reliable (re-)identification? At least for the
> recoding plugin it seems "old -> new" would suffice, for the sort
> plugin (and possibly scatterplot), the variable name would do. True,
> this solution cannot provide a full summary in any but the most simple
> cases. But in fact, even a list view will quickly reach its
> (width-)limit in more complex cases. Possibly - brainstorming, again -
> we could even design a sort of "slide-out": By default the full width	
> is taken up by tabs, providing a long summary (much like an all-folded
> accordion). Clicking on a tab opens up the editor widget for that row
> on the right side, while squeezing the tab-fingers to a short label
> form (this would be the state as shown in your mock-up). Some button
> or splitter can be used to go back to full-length summary / hidden
> editor, if needed. Otherwise navigation is still possible using the
> shortened tabs. Vertical scroll-bar is less likely to be needed, as tabs
> and editor are shown side-by-side, rather than below each other. In
> case vertical scrolling is needed after all, it would affect the
> tab-area, only.
> 
> Does that sound half-decent?

It does. However, this would be a custom control which operation will
not be known to the user and which best practices/behavior will not be
known to us (also exiting though). Even in the case of an easy
implementation of this, it is likely to need several iterations of
testing, fixing etc. until we know it performs well. So: Yes, it could
work, however it’s sorta risky usability-wise to implement a novel kind
of control. (even if it is based on a familiar other control, tabs)

> 
> [...]
> 
>> 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)
> 
> Yes. Point taken.
>  
>> 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.
> 
> Slightly different: They are somewhat-hard-but-possible to implement in
> any case (given our library foundation). Dealing with scrolling is the
> issue where I can't quite figure how we'd want this to work,
> conceptually.
> 
>> - 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.
> 
> I'll give them a try, somehow, and keep you posted, but may take a
> while before I get 'round to do so.
Great, I’m looking forward.

Regards,
 Jan
Jan