I’ve been fiddling with various notebooks (both my own and other people’s) on a smartphone and a tablet, and finding that the phone consistently does not do what I expect when I try to manipulate a slider.
Either it interprets my action as the beginning of a “swipe for previous page” gesture, or it starts trying to select the content as text, or sometimes select the whole slider element, or it just does nothing. After it has started interpreting drag events, it sometimes releases the drag spontaneously.
Is this just a Mobile Safari problem? A general problem with mobile browsers? A problem with touchscreens? Just me personally whose touchscreen finger skills aren’t up to snuff? … Do other people also have this problem?
Is there any way to suppress some of those undesirable effects while still using the native widget? Would it be worth implementing completely custom sliders drawing with SVG and using d3.drag or the like?
(In general it would seem like native widgets would be better at handling edge case, being accessible for alternative clients like screen readers, etc. etc., but if the native widgets don’t cut it…)
I have the same problem on iPhone 7 with Safari when in portrait mode (upright position) and the slider is in its leftmost position. If the slider is not close to the screen edge, it works, but only if I drag the little dot. Not when touching to the left or right of it. Then it selects the whole slider. When in landscape mode, dragging also from the leftmost position usually works fine.
Yep, this is one place where our desire to make notebooks nice a mobile friendly clashes with our desire to use native, verbatim HTML elements. The HTML range sliders in notebooks are the same as HTML range sliders elsewhere, and afaict, don’t have any unique problems by virtue of being within Observable - it’s just that Mobile Safari has an especially finicky UX around them.
For now, if you’re building a slider-heavy visualization and care deeply about mobile usability, it might be best to rebuild a custom slider UI using d3-drag and if you’re feeling especially benevolent, make it importable like Jeremy did with the Inputs notebook.
Glad it’s not just me. Personally I mostly use a computer. I was just curious how various notebooks would look on a tablet / phone, and then found it very frustrating to manipulate the sliders.
But I’m interested in playing around with various input research experiments in the future (both on multitouch displays, and with mouse/keyboard), among various other projects. Crappy data input methods has to be my least favorite thing about browsers.
(For example: there seems to be no way to get display-pixel–precision mouse movements on high DPI displays because the API was designed for 70-100 DPI desktop machines from 1995, so everything is integers (getting access to precise movement counts from high CPI mice is an impossible dream); keyboard handling is a cross-browser and cross-platform compatibility nightmare; many of the native widgets across all platforms are limited and have weird behavior in edge cases; people’s hand-rolled interface elements tend to be buggy as heck and have terrible cross-platform compatibility often clobbering default shortcuts; inputs often have terrible latency and background javascript will stall the UI thread; drag and drop behavior is frequently wonky; the default browser text boxes are less capable than the typical GUI app from 30 years ago, …)
