I know might be heresy but I'm curious why people like the interaction of scrubbing numbers. IMO it's hardly discoverable, it lacks reference values to know how far to drag and feels like poor UX. What others think about it? The first time I saw it was on Bret Victor's learnable programming, also great to know more history about it, and if somebody knows previous uses of it. http://worrydream.com/LearnableProgramming/Movies/Vocab12.mp4

My initial angle on this — they're a bit like a 1D, text-code version of this style of 2D GUI input (see also the Kaoss pad). I don't much care for the inline scrubbing numbers a la Bret's Tangle, since they feel like the tiniest step away from text code toward a richer graphical/visual coding environment. I'd prefer that we just take the whole entire step and start building rich scrubbers in a truly graphical/visual context. All that said — basic scrubbers are nice if the medium you're working in is purely text. That's what's nice about Tangle. It's not for programming, it's for prose.

Number-scrubbers are pretty common in visual effects software. You might have a text expression that drives something visual, and dialing in something to taste is terrible UX if you have to type out numbers. Usually the dragging "scale" is adjusted for the magnitude of the number that you're scrubbing. Some apps also let you manually choose the sensitivity with a context menu.

The domain where I want to use it is writing programs that generate graphics. What makes this interaction awesome is that you get continuous feedback in the graphics output area while you are scrubbing the value. So much more productive than: type in a number, render, type in another number, render.

Seconding their applicability in graphics stuff. Also note how Bret uses it to tune the jump factor in the demo game in "Inventing on Principle". Scrubbers are great for situations like that when you're trying to find "magic numbers"- parameters you don't care what exact value they are as much as how they affect your simulation in relation to others.

Further on discoverability — there are a lot of tools (3d programs, for instance) where all number inputs are scrubbable, and it's clear from the styling whenever a field is just an output/measurement and not an input. Other tools will put a vertical up/down control next to the field, and (like Yoshiki said) the cursor changes to give you a hint that it can be scrubbed. On the other hand: number-type inputs in some web browsers are automatically scrubbable using the scroll wheel! So it's regretfully easy to accidentally scrub them when trying to scroll through the page. Argh!

Yeah there are a lot of cases I can think of where reference range values are part of the tacit knowledge you have when approaching the system, for example “scales” in a design system. So I think this limitation of scrubbable numbers can’t be discussed absent of specific contexts like that. I can also imagine situations where they aren’t appropriate(also cases where ppl get overly enthusiastic in using them in the wrong context. On reflection, I’ve done this before!!)

As some of you know, I've worked a bit on this stuff and plan to do more. I'm hoping to give this feature some love over the next couple of weeks; mainly because recent discussions here have inspired me to do better. This is what I did the last time I looked at it; auto discover the variable and add a slider in a space somewhere around it. You can imagine a color swatch or some other style of widget to make it obvious; and allowing the user to add a comment to help identify the UI for ambiguous cases.

float val; // widget-slider

I agree that plain numbers aren't as discoverable, but the way they are drawn is different in the demo posted by @Dominik Jančík - with their black backgrounds. I think you only have to 'discover' them once. And a pop-up indicator with limits, etc. would be easy enough to do. That said, I think I still prefer adding UI widgets inside the document, giving it more of the feel of a jupyter doc. Indicating non-linearity or limits is much easier if you aren't restricted to text. Another idea I had was to have the widgets 'cover' the text and fade back to editable text based on context, but I think this is probably too confusing.

I always found the discoverability hard and for the stuff I do the problem is that if a thing can be scrubbed, then it can't be dragged 😕

@Mariano Guerra if you have ways to toggle the scrubbing then standard text interactions (selection, dragging) are still possible. Here's two possibilities: Toggling (Ctrl+Shift): https://codepen.io/domjancik/pen/XWdjrQv Hold to enable (Ctrl): https://codepen.io/domjancik/pen/VwamOyJ

yes, there are ways, but they become less discoverable even 🙂

@Mariano Guerra Prompt? https://codepen.io/domjancik/pen/VwamOyJ

yes, that's the way I'm solving the discoverability problems in my app, tooltip (almost) all the things, but instead of showing them as tooltips I show them always in the same place with some extra metadata

Scrubbers are great for situations like that when you're trying to find "magic numbers"

To me the real solution would be to fix the problem of magic numbers, I know it's a hard thing to do. But scrubbers just feel like a bandaid to the real problem.

The solution that I want is more like a real knob/slider which you can turn (or slide). A knob can be endless if that fits the situation. So that you can be precise if needed or change the value to a much higher value by turning the knob faster. These kind of knobs are available on midi controllers and I've seen them in software (ableton and vst's come to mind) as well. It would be cool if the html-browser range input would support this behavior more or less out of the box

@Maikel I implemented an endless slider to my Curv project, but I'm not in love with the UI. I'd appreciate some more specific references to good UIs for this, so that I can see what a better UI might look like.

@Daniel Garcia curious what you mean by solving the problem of magic numbers. For physics params in games at least, to me everything is arbitrary and relative to other values, so I’m not sure what the problem to be solved is.(Maybe “magic numbers” isn’t the right word? Sorry if that was confusing)

@Doug Moen The knobs on the nord lead https://www.wikiwand.com/en/Nord_Lead line of hardware synths have endless knobs with a ring of leds to indicate the value. I'll look for other examples in software and will post them here

I do the same thing with control knobs, along with a tooltip that appears to show you the units and current value. The orange arc gives you a sense of where you are around the knob, but the knob may scale exponentially depending on what it is for; and there is no indication for that, other than 'playing' with it. I don't think that's a big deal, but I guess it isn't discoverable.

@Chris Maughan in ableton you can still type in the value when needed, is this also possible in your solution?

No, but it probably should be 😉

I want these kind of controls in the browser as well, and they exist offcourse but I think the biggest problem in getting the native feel is that you cannot hide/show/control the mouse pointer and position like you can do in a desktop application. On a mobile touch device this might be less of a problem

Do they need to be discoverable? There is often a tension between being efficient and discoverable. Imagine you wanted values in a spreadsheet to be draggable and discoverable. If you show some UI you've probably just decreased the information density by 50% or more. People that are actually trying to enter data will probably tab, type, tab, type, tab, type so the UI is just wasted. Holding alt and dragging to slide a value when you want to explore is a reasonable trade off. Sure, a new user won't know they can alt-drag a value but the training of that new user is over in 30 seconds and is possibly not worth the loss in efficiency for the few days later when they start trying to be productive. I'm not saying you shouldn't have visible sliders period. It's rather, probably more of what's your expected use case. If you only ever expect less than say 20 inputs then sliders might be great but if you expect 300 inputs maybe not so much? Or maybe at least there's a tension between targeting noobs and once in a while users and targeting experts/pros. There's a reason we take the training wheels off the bike at some point.

@yoshiki By "magic numbers" I mean this critic by Bret Victor. But I like more just being explicit in the language/API and have labels on arguments, like:

ellipse(xPosition: 161, yPosition: 219, width: 114)