[IPOL discuss] A comment on sliders on demos

[Nicolas Limare]

Hi,

> Then, if we want to give priority to the textbox we have to programmatically
> change the slider parameters. If we need that the value in the textbox is
> taken into account even if outside the range of the slider, then we have to
> change the min and max of the slider when we detect that its value is out of
> range. [...]
> This should not be very difficult to do, but my concern is again that if we
> allow this, then we can end up with experiments that don't really make
> sense.

I don't think we should give the priority to the textbox. A
*correctly-defined* slider is supposed to provide avery option that
make sense in this context, with limits on the range and type of
input. For example, some demos could have a wrong behaviour when a
parameter exceeds some limits[1], a parameter could make sense only
with integer values and not with floating-point.

In a good demo, these parameters are checked server-side in the Python
code by checking and filtering the values received as method
arguments, *and* client-side in the HTML template by not providing web
users options to send a wrong parameter[2]. So any option not provided
by a slider should not pass the Python validation. Allowing the text
input to overrride the slider would not bypasss the Python validation,
and so it is not a good thing because it would make web users expect
something that doesn't happen.

This is in the perfect situation, when the demo provide exactly all
the options that make sense. If might often not be so, but then I think
it's better to suggest a change to the demo parameter form than to
override them. The parameter form improvement will last and be there
for everyone.

@Miguel: Can we set the step for these sliders, for example to allow
integer-only values with step=1, or pseudo-float with step=0.000001?

All the best,

[1] we recently had this situations with a demo taking a lot more
    time to compute when a parameter was too large 
[2] the HTML-level restriction does not guarantee that no wrong value
    will be received at the Python level (could be manually written in
    the URL query, or someone can edit the HTML locally), hence the
    need for a Python-level validation

PS: IPOL web demos are just a convenient demonstration of what an
    algorithm can with settings compatible with the demo server (RAM,
    CPU time), the web interface (data size, image size), and common
    use cases (parameter presets and range good for majority of
    data). They will not provide the best options for every possible
    situation and they are not not there to replace a local execution
    with all the freedom you have to play with input, parameters and
    even the code when you are working on your own machine. 

-- 
Nicolas LIMARE - CMLA - ENS Cachan        http://limare.perso.math.cnrs.fr/
IPOL journal                                            http://www.ipol.im/
-> image processing, reproducible research, open science
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://tools.ipol.im/mailman/archive/discuss/attachments/20140331/993561fb/attachment.pgp>