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

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

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.

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

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

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?

[...]

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

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/20150605/b0df945c/attachment.sig>