[rkward-devel] Bug: Submit not active in several plugins (?)

d_jan d_jan at ymail.com
Sat Nov 21 17:22:06 UTC 2015


Hi,

TL;DR:
0) Unambigous (not-delete-like looking) symbol for warning: good.
1) Don’t allow adding certainly wrong values in the first place
2) In a  likely-to-work scenario, warn users in a comprehensible way.
2.2) If the likelyness is rather low or a wrong input causes certain
mayhem, stick with hard checks.
3) consistency is good.

Or more elborate and comprehensible:

Am 21.11.2015 um 15:17 schrieb Thomas Friedrichsmeier:
> Hi,
[SNIP]
>  
>>>> Also, in front of the picked variables are little delete icons
>> (trashcans on KDE). If I click them, nothing happens.
> 
> The icon was meant as an indication that something is problematic about
> the object, it is not meant to be a button. I suppose some sort of
> "Attention/Warning" symbol might explain this better? The actual
> problem is shown in a tool tip on mouse over.
Yes, a warning-symbol is better; semantically, it would be a
status/task-attention in an iconset (if I understand iconsets right!)

>> What should happen: Executing the test should be possible. If there
>> is a condition preventing this for good reasons, there should be some
>> warning/note that is not easily overseen.
> 
> Good point. In this particular case: Fixed. But actually, I do feel a
> bit uncomfortable, here, as there might be cases where were restricting
> what can be done, unnecessarily. For instance, in many cases, where our
> <varslot>s specify "numeric", logicals would be acceptable, too, at
> least as corner-cases. They'd still not be the "typical" type of data
> to feed into the plugin, but there may well be use-cases for doing so,
> once in a while.

1) Could we disable entries in the var picker? Or sortof have always
accepted ones and "critical/unknown" ones (they could be displayed gray
or only if demanded)?
Just thinking, that it is usually good to make bad things harder to do
instead of letting users fill the var slot and then saying "by the way,
I can’t take these"

2) What happens if you select a "wrong" type? Does it fail silently and,
lets say, some values are missing? Usability wise, it is the worst if
there is an error and the users does not notice that the analysis lacks
an important part or so and the second worst if he/she notices *but*
does not know why this happend and how to resolve the situation.
Lets say you feed a function logicals, it converts them to 1 and 0  and
does the analysis. If we are not totally sure that it worked there
should be a warning like:
"values [variable name] used in [plugin name] were boolean (TRUE/FALSE).
[plugin] only works on numerical values. Thus the boolean values in
[varaible] have been converted to numbers (1/0) for use in [plugin
name]. Please check if the analysis results are correct under this
condition" – ideally in the result stream, so it is not forgotten.


> Yet another possible filter is "number of dimensions" (i.e.,
> importantly, vectors vs. 2d matrices). I think false positives in this
> filter are relatively unlikely, although again, not entirely
> inconceivable.
> 

> I was thinking more along the lines of "ok, let's show the
> user that this is likely to be wrong, but do allow to proceed". 

Yes, this is o.k. if we come up with a comprehensible warning which
allows non-programmers to understand what is going on.

> (It
> would not be too hard to make this configurable per <varslot>, but I
> guess it would still be best to have a consistent policy on this).

Pro consistency from the usability perspective.

:)

Regards,
 Jan


More information about the rkward-devel mailing list