museumsvictoria/nodel

<range> with nudge controls

justparking opened this issue · 7 comments

Currently the <range> control only allow sliding to control its value.

On many touch screens where space is a premium, sliding can be impractical and inconvenient e.g. level jumps too extreme, surface is grippy.

Being able to "nudge" up or down would overcome these issues.

Nudge controls could be added as things stand now using extra existing components but that involves lots of extra XML and backend bindings, etc.

I propose a nudge attribute which, when specified applies the nudging (up or down). This will make it easy to retrofit existing installations.

e.g. <range join="DSP Volume" min="-40" max="12" nudge="0.5"/>

And the nudge controls would present as circular "-" or "+" either side of the control.

NOTE: there is a big risk that with the "+" so next to the maximum value, the user could accidentally turn things up to their maximum. This will be addressed in another issue to come...

(@scroix @mcartmel @dargs CC)

A new branch added.
https://github.com/morimoriysmoon/nodel/tree/feat-improve-input-range

GOOD:
<range join="range" min="0" max="100" step="0.1" nudge="0.1"/>
<range join="range" min="0" max="100" step="0.1" nudge="0.5"/>

BAD: nudge should be greater than step or equal and multiple of step.
<range join="range" min="0" max="100" step="1" nudge="0.5"/>
<range join="range" min="0" max="100" step="5" nudge="7"/>

Note: 
- default value of step is 1 unless defined.
- default value of nudge is same as step unless defined.

Record_2023_02_24_08_39_02_883

Long press supported.
Record_2023_02_24_19_05_53_370

Looking good!

A few things:

  1. with nudging and long press, feedback should be driven be actual feedback. e.g. I just ran a test now without it being coupled to any "device" (real or virtual) and the slider moved. It shouldn't have.
  2. long press should not have acceleration applied. Should be constant rate of change no matter how long pushed.
  3. very important: behaviour, look and feel must remain exactly as before. New behaviour must only be activated if the new "nudge" attribute is in use. In other words, if a system is updated, the user interface and behaviour should not be different i.e. opt-in only.
  4. the current value seemed to be overwritten by the "-" button (see below):
    image
  5. the "-" and "+" don't seem to be properly centred in their circles.

I've had a rethink about (1): we'd need to test which makes for a better user experience - with device feedback coupled or not. It would depend on the real-world latency of the device feedback of course. At the very least, at least the value label is ALWAYS updated. Perhaps with nudge, feedback is coupled; but with long press, it's decoupled. Either way it needs testing based on different device latencies (which is easy to simulate).

  1. Acceleration removed
  2. Nudge functionality will be activated only when "nudge" attribute found
  3. Fixed
  4. Fixed

This look great except for some incompatibility with another a certain browser version.

And with any new UI control update, detailed, described example(s) are required in the sample XML file - sample index.xml file

  • Coupling issue: fixed
  • Small icon issue: fixed after pkg updated
  • Example added