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

[Thomas Friedrichsmeier]

Hi,

On Sat, 21 Nov 2015 18:22:06 +0100
d_jan <d_jan at ymail.com> wrote:
> Yes, a warning-symbol is better; semantically, it would be a
> status/task-attention in an iconset (if I understand iconsets right!)

ok. That part is easy.
 
> 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"

In principle, yes. But in some scenarios that will prove difficult. E.g.
(fairly common) two varslots on one page, one accepting a data.frame,
the other a categorical vector.

I do see your point that _if_ we want to enforce a hard check, the
varslot should not accept these objects at all, but also I'm not 100%
sure on how exactly the user would get feedback on the reason why the
object is refused: "this object does not work, here, because...".

Anyway, to me the "larger theme" is: Will we always be correct about the
restrictions we put into place? In particular for numeric vs. logical,
there will often be cases of doubt, where e.g. using a logical is
clearly atypical but may (or may not) be legal. This is very often the
case for plots, sometimes for tests. And in fact often the underlying R
functions themselves will be documented to take "numeric" arguments,
when actually they will happily work on logical as well. In fact, this
is true for quite a number of the plugins that currently specify
"numeric" varslots(*). E.g. t.test, ...

That's why I'm leaning towards "soft" checks: No, doing a t.test on
dichotomous data may not be considered best practice, and we may want
to indicate that. But it's entirely impossible with R, and it's not
totally unreasonable, either. Shouldn't we assume the user essentially
knows what they are doing (stats wise)?

Of course, whether or not that is a good idea depends on your next
question:

> 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

Very unlikely to see a silent failure for wrong type of input. The R
functions in use do check their input.

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

Generated warnings or error messages are shown/recorded in the output
window, quite visibly. So, overlooking/forgetting them seems rather
unlikely. Unfortunately, in many cases, R's messages will be rather
cryptic, making it hard to figure out, exactly what went wrong.

In such cases, I would hope, the "warning symbol" would come in handy,
again.

[snip]

Regards
Thomas

(*): To be fair: Logical could easily be special-cased, as "rather
likely to be acceptable for both categorical and continuous data".
OTOH, if we're talking about varslots looking for logical, input, both
a factor, and a numeric variable _could_ qualify (if they contain only
two distinct non-NA values). And both logicals and numeric variables
could clearly pass for categorical input in many cases, too.
-------------- 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/20151121/9bf480c6/attachment.sig>