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

[Thomas Friedrichsmeier]

Hi Jan,

I'm quoting you in full: Apparently your mail did not go to the list.
(All: Any objections against configuring rkward-devel to set Reply-To
explicitly? I.e. do you reply off-list, often?)

On Sat, 30 May 2015 17:57:12 +0000 (UTC)
Jan Wort <d_jan at ymail.com> wrote:
> Hi Thomas, 
> 
> Hi RKWard Devs, 
> 
> 
> >… "modes of operation" for the optionset. One is the "manual"
> >variant,> featuring +/- buttons. 
> > […]"driven" optionset. It is suitable for cases 
> > where a list of "things" is already defined somewhere outside the
> > optionset
> 
> Thanks!. I think I got now what it does. 
> 
> 
> > [maybe usability would improve if…] status display to only a single
> > column,
> 
> I thought of that too, though after some analysis of similar controls
> it occurred to me that the problem is probably somewhere else. 
> 
> The control is unfamiliar to the users and assumptions drawn from
> experiences do not hold. 
> 
> This is in particular relevant for knowing what interaction has which
> results and knowing where these results will be displayed ("Mapping")
> I checked various similar controls in different applications. E.g.
> the "formatting- styles" control in word/libre office is similar – a
> list listing some sort of settings-sets); as well other Statistics
> applications seem to use that popup-idea too. It is actually pretty
> clunky – but known to the user from many other applications. 
> 
> This does not mean that the idea of optionset is "wrong" or anything
> it’s just that lack of transferability of knowledge and difficulty to
> map (locate) interactions and results.

Before going into your suggestions, specifically, let me start by
saying that on first impression, I think we may want to have both.
Solution 1 would remain - technically - very similar to the current
optionset. Solution 2 looks more like an all new control to me.

For solution 2, this looks clearly superior for the more simple cases.
But I believe it will not "scale" to the more complex ones. Here, the
strength of the current optionset is that it can contain pretty much
anything that works in an RKWard plugin standalone. This means:

a) Relatively little extra xml-semantics to learn for the developer.
b) Ability to include arbitrary controls. As an example, the color
selector is a plugin in itself, and can be included in an optionset.
Right now it is little more than a <dropdown>, but eventually it will
include extensions like a color preview, alternative modes of selecting
colors by RGB, color maps, etc. In allowing to include any such
elements, directly, it also allows for more modularity in development.
c) Can make use of all existing means of managing complex options, and
interdependent controls.

To sketch an example, the scatterplot plugin is rather important, but
currently in a rather sad state. It would make a lot of sense to
re-design it around an optionset, allowing to specify an arbitrary
number of x-y-pairs, and for each at least
- line color
- line style
- line width
- point color
- point shape
- point size.

Arguably, all of the above could easily be represented in a table-like
control with dropdown boxes. But next there would be some very useful
extensions: For instance, we might want to allow certain additions for
each x-y-pair, such as data concentration indication, linear or
non-linear regression fits, etc. For each such addition we'd again need
options for at least line color, style, width, but in some cases also
specific parameters. All this will remain fairly manageable, if it can
be visually grouped (into frames or possibly tabs), and irrelevant
options can be disabled or hidden (such as line and background color of
concentration ellipsis, if that is not shown). But the same amount of
flexibility is simply not available in a purely table-like control,
AFAICS.

(Another example that could profit from an optionset-approach would be
Data->Subset data.frame. If you look more closely, you will find out
that this actually has considerably more complexity than meets the eye
on first glance.)

> IDEA/SOLUTION 1: 
> 
> What if the List entrys would be  more like tabs (visually too),
> making the connection of each Set with the setting form clear? (or
> otherwise make clear that clicking an optionset gives you an
> according, optionset-specific panel/form) 
> 
> 
> I could provide some mockups for this, if you are interested in
> pursuing these directions. 

Yes, that would be nice!

> IDEA/SOLUTION 2: 
> 
> However, for the uses I’m aware of (like Sorting, Recoding) an
> matrix-like representation with added controls sees to be ideal:
> There would be far fewer problems to match editing, representation
> and results of actions; as well this way would be quite good for
> "change" scenarios, using a this-before and a this-after
> column.                 
> 
> Examples: 
> http://imgur.com/rlXmiF6
> http://imgur.com/WKvp1Dw

For the second example, I think this solution is in fact superior on
all counts. For the first example, I think it depends: Very nice for
the case that you want to recode many distinct values to distinct other
values. Not so nice in case you want to merge five different values into
one "other" category.

> I had a look if the underlying (I assume) qt has such a control build
> in; I did not find it in the standard lib; however, it seemingly
> could be made with combining the standard elements as shown by the qt
> people     themselves:
> http://doc.qt.io/qt-5/qtwidgets-widgets-icons-example.html
> 
> 
> It may as well play well with the existing matrix control (? – I only
> have minor knowledge of qt)

Well, implementation-wise: possible, but will require a good deal of
custom coding. I'm also starting to think, it would not make sense to
impelement this in RKWard's <matrix>-element after all, but as a
separate element (e.g. <optiontable>). But that's an implementation
detail. I'm also not so sure on how this would be defined in the plugin
xml.

> These are my thoughts to this; please write, if I oversaw something
> essential. I am fully aware that either suggestion is not a
> one-line-change-fix; however, since the element is seemingly
> frequently used in several plugins I though I throw in the ideas and
> analysis of problems.

Ok, in summary: I think there are use cases for both solution 1 and
solution 2. Solution 1 sounds much less scary, technically (based on
what we have, now). And perhaps we can make considerable improvements
with relatively little effort. I'm definitely interested in your
mockup(s), there.

Solution 2 is really elegant for other use cases, but looks like an
all-new control to me, meaning a bunch of work. Which does not
mean it is not worth the effort, but I think I'd like to look into
solution 1 more closely, first.

> Kind Regards,
>  Jan

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/20150531/4456a2c8/attachment.sig>