[HN Gopher] How Apple designs a virtual knob (2012)
___________________________________________________________________
How Apple designs a virtual knob (2012)
Author : gregsadetsky
Score : 91 points
Date : 2025-10-07 18:19 UTC (4 days ago)
(HTM) web link (jherrm.github.io)
(TXT) w3m dump (jherrm.github.io)
| brudgers wrote:
| Up and down virtual knobs are entirely unintuitive to me.
|
| I understand the rationalization, but a knob is not a slider and
| what's the point of non-skeuomorphic skeuomorphism?
| dsego wrote:
| It's a visually more compact interface element, but still
| allows the same simple interaction as a slider?
| brudgers wrote:
| We don't steer automobiles with reins because new
| technologies work better with interfaces that match their
| technological properties. We've learned a lot about human
| computer interaction since the 1970's.
| quitit wrote:
| This approach solves a common problem in apps that need to
| surface a lot of controls.
|
| Problem 1: Sliders take up a lot of space.
|
| Problem 2: Fine control of a mouse or touch-driven interface is
| provided by sliding, not by rotational gestures.
|
| The idea here is to use a virtual knob to save space, while
| providing the fine control possible with a sliding interface.
| The sliding direction is generally chosen to be intuitive to
| the function of the knob. (Locking to horizontal or vertical
| also assists with fine control.)
| brudgers wrote:
| Using a knob when using a knob doesn't solve the problem is
| poor design...then again, skeuomorphism is usually bad
| design.
|
| Here a counter that increases and decreases with mouse
| movement would take less space and be more intuitive.
|
| And a much much better design because it would provide a
| numerical readout of the value directly at the point of
| interaction.
|
| But in fairness, most design is bad because designers tend
| toward satisfying themselves rather than users...ok, I will
| stop ranting now.
| pegasus wrote:
| A counter provides more information but takes longer to
| read and appreciate than a simple angular magnitude.
| pegasus wrote:
| Exactly. It's not about skeuomorphism, it's about saving
| space. Yes, it's unintuitive, and they could have made it
| work with a circular swipe as well, and probably should have,
| but it makes sense design-wise.
| Synaesthesia wrote:
| It's quite common in DAWs, it allows you to adjust knobs quite
| easily with a mouse.
| duped wrote:
| It's a fixed size slider which uses the rotation of the
| indicator to tell you its position, instead of the position of
| a thumb in horizontal or vertical position.
|
| If you replaced it with text or a bar that filled the area it
| would be the same.
|
| It's better than a linear sliders because it takes up less
| space. It's better than a bar slider because you have more
| range to display (the length of the arc of the indicator is
| longer than the horizontal and vertical dimensions). This in
| turn makes it better for putting into tighter spaces.
| brnaftr361 wrote:
| I didn't read the writeup. The result was pretty gnarly. The
| active area on a phone left me scrolling up and down and I had to
| go very slow once I got purchase on the knob or it would rotate
| back after a quarter turn.
|
| Please no.
| hackernudes wrote:
| Agree. Makes sense for a mouse cursor but not touch.
| amelius wrote:
| Huh, the knob turns back when you attempt to turn it circularly
| (the most intuitive gesture).
|
| How difficult can it be to make a knob that works when turned
| both linearly and circularly?
| weinzierl wrote:
| Came here to say that. They over-engineered it in a way that
| killed the only truly intuitive way to interact with a knob.
| hannesfur wrote:
| Having played a lot of MSFS 2020/2024 recently, I feel like I can
| appreciate this way more now. Since they have to make these knobs
| realistically and in 3D, when using them with a keyboard and
| mouse (or even worse a controller) it's incredibly difficult to
| see and turn them. It gets even worse since you can push and pull
| many of these knobs (the difference being potentially
| catastrophic as well).
| bee_rider wrote:
| Interesting. I could imagine a knob not being _so_ bad with a
| controller. But maybe I'm miss-imagining or maybe they
| implemented it poorly.
| quaintdev wrote:
| The whole idea of knob is stupid both on touch screens as well as
| desktop. There are other good alternatives which are far more
| intuitive than knobs.
|
| Knobs are good when you can physically rotate them like for
| example in a car. But there we are removing knobs and adding
| touchscreens.
| MattPalmer1086 wrote:
| Completely agree. They are very prevalent in DAWs and audio
| plugins, as they try to look like physical hardware. I
| absolutely hate interacting with them, either with touch or
| mouse.
|
| I guess the one advantage they have is they don't take up as
| much room as a slider, maybe?
| bigyabai wrote:
| I tolerate knobs in DAWs/plugins... _if_ they let you
| manually enter a value. So much fiddling can be skipped by
| dialing in a value directly.
|
| Without manual entry, you trap users in fiddly UI hell.
| dleeftink wrote:
| When knobs are fiddly, most VST3s offer high-resolution
| midi mapping for precise automation. I agree through, that
| a precise readout is a must as the 'knob units' may not
| always map to what is displayed by the VST host.
| hermitwriter wrote:
| Designing 3D real-world interactions for 2D screens is fun.
| Literally fun. Rarely useful.
| sethwebster wrote:
| Yeah, the paradigms are just too different.
|
| I prefer sliders for knobs... just much more natural with a
| mouse or touchscreen.
| hermitwriter wrote:
| It's hard to replicate the "coolness" factor though of a
| true studio control board. It begs to be touched and knobs
| beg to be turned...
| LoganDark wrote:
| Hmm, for alternatives, are you thinking of things like
| spinboxes? (I know them mainly from Blender)
| Fraterkes wrote:
| The point of knobs is that you can fit a ton of sliders in a
| limited space, and that you can wildly adjust them with very
| little movement. Both are requirments for a lot of music
| software. What would the alternative be?
| tobr wrote:
| You can do this with a normal slider as well. Map a large
| pointer movement to a small control movement.
| Fraterkes wrote:
| I meant the opposite: with only a small mouse movement you
| can fling a knob wildly, which is great if you want to do a
| quick transition on eg a high pass filter or a low pass
| filter
| dleeftink wrote:
| I think multi-zone drumpads on the recent Akai MPC Live 3
| provide a good middle ground, quite similar to mapping
| various zones on a trackpad. The Macbook touchstrip was a
| cool (but maybe too cool) addition as well, similarly
| introduced by various DAW controllers (Push, Machine, MPC
| Live, others).
| Fraterkes wrote:
| I meant that in the context of a digital ui, knobs are
| great because theyre a way to fit a finely-adjustable
| slider in a small area. In the physical world there's
| obviously lots of alternatives
| StopDisinfo910 wrote:
| > What would the alternative be?
|
| Large slider which doesn't change place, buttons to select
| what you are adjusting. Display the current value on the
| button if you need it to stay visible.
|
| The magic of software ux is that you can actually replace
| things on a screen in a way you can't on a physical device.
| charrondev wrote:
| Then you can't see the value at a glance though.
| Cockbrand wrote:
| Others have already pointed out that a knob saves a lot of
| space. And I'm surprised myself how usable a knob is when
| controlled with a vertical trackpad scroll gesture. Probably
| still a frustrating control on a touch screen, though.
| duped wrote:
| If you've ever used pro audio software you come to love rotary
| over linear sliders. They're simply more flexible and dense
| when you have many parameters to tweak.
| kowbell wrote:
| Linear sliders are also finite, while rotary encoders can
| spin forever.
| siriaan wrote:
| In the physical world, sure, but there's no reason why a
| virtual linear slide could not be made endless
| baxuz wrote:
| Yeah but that doesn't have much value as you lose the value
| indicator.
|
| If you don't need a value indicator, you don't need a
| circular knob as an affordance. You can have a whatever as
| it just reacts to your input.
|
| If you do have a value indicator which is "infinite", such
| as a numerical value display, it's better to make it
| interactive and place the interaction on top of it, instead
| of splitting the UI between a value indicator and the
| input.
|
| A lot of software does this.
| baxuz wrote:
| It's really not. You're looking at it the wrong way, and
| haven't come across any of the use cases it solves.
|
| If you have limited space and you need to both interact with
| and see fractional ranges, knobs are the way to go. It's way
| more glanceable, and the entire range is displayed in the knob
| itself.
|
| Think of it this way: Both a circular knob and a slider have 2
| elements: the interactive area and the range display. However,
| the slide has the same knob size that is set on a large track
| displaying the selected range by moving the knob, whereas the
| circular knob has the track displayed radially inside it.
|
| For the track example -- the knob is the only interactive
| element for all practical purposes when it comes to precise
| tweaking of values. Single clicks on a track usually don't
| support further dragging after the initial click on any OS or
| UI implementation.
|
| This comes with many positive sides:
|
| - The interactive area (handle) is always in the same place.
|
| - The interactive area is in practice always bigger than a knob
| on a linear slider.
|
| - Adjusting the knob doesn't reposition your cursor, no matter
| what you do with the mouse.
|
| - The circular track allows for much easier visual
| identification of fractions compared to a linear track due to
| its radial nature.
|
| - The indicator can be a single pixel, whereas on the linear
| track, the knob is a fairly imprecise blob due to its nature of
| needing to serve a dual purpose. This means it's a lot more
| precise.
|
| - There is a lot more granularity in the same surface area.
|
| - Interaction precision isn't limited to the size of the track
| where it needs to scale linearly
|
| - You don't need to dynamic element rendering or resizing which
| may cover other things you're looking at.
|
| - The area is much smaller. On a 16x16px circular knob, I can
| get up to hundreds of steps which are clearly visually
| distinct.
|
| All of that being said, the article is quite bad as it
| contradicts itself, and uses knobs in ways they are not good
| at, which is circular interaction and being able to do multiple
| circles. It beats the point of having a knob, might as well
| have an interaction handler on the number indicator itself.
| jeroenhd wrote:
| In just about every simulator featuring knobs, I've noticed
| that most knob interfaces will accept scroll wheel inputs. Use
| the literal knob in your mouse to control the knob on the
| screen.
|
| Of course Apple's mice don't have a physical knob, so that
| approach doesn't work, but knobs and mice can work outside of
| the Apple sphere.
|
| On touch screens, you can probably make them work by tapping
| the knob and popping up a slider to control the value. Lets you
| use knobs to maintain an overview while exposing usable
| controls for modifications.
| nixpulvis wrote:
| I actually think knob inputs i.e. just the knob without
| vertical or horizontal modes, are quite useful. The ability to
| naturally gain precision the further out you drag is very handy
| and intuitive.
|
| Not good for computers with mouse inputs, but for touchscreens
| I like the idea.
| DonHopkins wrote:
| >The ability to naturally gain precision the further out you
| drag is very handy and intuitive.
|
| Pie menus, where the selection is based on the gesture
| direction, allow you to move further out (longer gesture) to
| get more "leverage" or precise control over the angle (either
| continuous angle, or the selected slice).
|
| The angle selects a slice, but you can think of a knob as a
| pie menu with one slice (the whole pie) that also has a
| direction and a optional distance parameter.
|
| But you can even use the distance to exaggerate the angular
| precision even more!
|
| Here's a demo of a "Precision Pie Menu" I wrote in 1988 for
| NeWS in PostScript, which exaggerated that angular precision
| effect even more, once you pass a certain distance, allowing
| you to have extremely precise control over the angle.
|
| https://www.youtube.com/watch?v=c0scs59va4c
|
| >Demo of the precision pie menu. Research performed by Don
| Hopkins under the direction of Mark Weiser and Ben
| Shneiderman. Developed and demonstrated by Don Hopkins.
|
| >Transcript:
|
| This is a demonstration of the Precision Pie Menu under the
| NeWS window system.
|
| It's an experiment in exaggerating the extra precision that
| you get with distance.
|
| As you move out further from the menu center of a pie menu,
| normally the further you go from the center the more control
| you have over the angle.
|
| But if you want to input an exact number like an angle, you
| might want to get it down to the a certain number, but you
| run out of screen space before you get enough leverage to
| change the number to what you want.
|
| Now what happens here is that when you poke out, it makes a
| flexible lever, that the further out you go, the more
| flexible it becomes, and you have much finer control over the
| number.
|
| So as I move around back in and out, I'll poke it into a
| different place and just come out further to get a lot of
| leverage, and dial exactly the number I want.
|
| So here's what happens when you go around to the other side:
| "pop pop"!
|
| And as you get nearer it gets less and less flexible.
|
| Generally you'd kind of eyeball it, and then get it exact
| like 93, well there's 93 or 273, there's 273.
| alberth wrote:
| QuickTime use to have a wheel as a volume control.
|
| It's was a pain to use and they later dropped it for a slider.
|
| http://hallofshame.gp.co.at/qtime.htm
| Cockbrand wrote:
| You beat me to posting this. When this version of the QuickTime
| player came out, I couldn't understand how Apple of all
| companies could ship this obviously awkward control.
|
| Edit: Scrolling further down on the article, I get reminded of
| the weird pop-out drawer at the bottom of the player. I had
| totally forgotten about it, and it was also a very awkward and
| un-ergonomic piece of UI.
| 62 wrote:
| I don't know who they think they are fooling but these are all
| garbage. Jerky and frustrating to use, same as always.
| dvh wrote:
| The one called garage band synth knob with 17 images is available
| as MF-A01 in real life. But beware there are 2 versions with same
| model number get the one with the set screw and brass bushing.
| ranger207 wrote:
| > After using the knobs in Garageband for a while, I noticed that
| they didn't always react the way I thought they would. Most of
| the time the little indicator dot on the knob would follow my
| finger as I spun the knob around in a circle. Other times the
| knob wouldn't follow my finger at all and seemed to go in random
| directions. I eventually figured out that I had stumbled on three
| different ways to turn a virtual knob.
|
| > ...
|
| > Apple's attention to detail is what has propelled it to be the
| most valuable company on earth. Whether it's the click of a
| physical button or the math behind inertial scrolling, Apple
| employees work really hard to make products that are deceptively
| simple and just feel right. The virtual knobs found in Garageband
| are no exception and I hope others enjoyed learning about them as
| much as I have.
|
| I think these two statements are contradictory. Personally, I've
| noticed a pattern when people post about Apple UX that seems to
| go "yes this thing may be unintuitive _but_ actually it 's a sign
| of really good design!" that I can't quite seem to wrap my head
| around
| al_borland wrote:
| I think it's more that someone may assume how something works,
| and it isn't exactly that, so they say it's unintuitive. But
| there could be multiple assumptions on how it should work on
| first use. Covering all of those possibilities, and integrating
| them into a cohesive experience that works the first time, and
| makes even more sense as you continue to use it and learn the
| other ways to interact, shows a strong attention to detail and
| design.
|
| This is opposed to something that may be very intuitive for 30%
| of people, but the other 70% are lost, and the implementation
| doesn't scale.
| PunchyHamster wrote:
| I think in UX there is general lack of desire to properly
| explain how stuff works instead of relying on just "guessing
| user expectations right"
|
| like if said knob just displayed a vertical bar with marks
| signalling up and down also works it would be very clear to
| person that tried to just spin it
| bitpush wrote:
| Agreed. There's a lot of self blaming going on here. "Apple
| cares about users so much. They work sooo hard" .. but also
| when things don't work well, they don't seem to update their
| world view.
|
| Its quite fascinating behavior really. Reality distortion
| field.
| Zak wrote:
| I'm amused by the contrast between Apple's attention to detail on
| the implementation and their failure to recognize that a virtual
| knob with a touchscreen or mouse is a fundamentally bad idea.
|
| The author also makes this error, praising Apple's design prowess
| and denigrating its competition while failing to recognize they
| "didn't always react the way I thought they would" because
| they're ill-suited to the medium.
| oncallthrow wrote:
| Literally every DAW has knobs everywhere: it would be
| impossible to use sliders everywhere in a DAW's UI, there
| simply isn't enough room.
| HeWhoLurksLate wrote:
| was going to say, heaven forbid we use a little skeumorphism
| o11c wrote:
| "Make [a slider] bigger while the mouse button is held down,
| and warp the mouse so that when you let go you pick up where
| you left off" has been a solved problem for decades.
|
| And with traditional toolkits (i.e. not HTML) it will even be
| fast.
| llbbdd wrote:
| This would be a few lines of CSS and it would be very fast
| baxuz wrote:
| It's not all about the interaction, but also the visual
| representation which can be much finer and granular in
| small spaces with a knob.
|
| I can make a 16x16px knob where you can see almost the
| entire 320deg of the range.
|
| It's also easier to see fractions, such as 1/2, 1/3 or 1/4.
|
| Sliders, especially in 16px possess none of those.
| duped wrote:
| I was able to debug and fix someone's MainStage patch last
| night over SMS when they sent me pictures of their screen,
| where all the knobs were visible.
|
| Being able to see the full state of the thing is important.
| Hiding it behind interactions is just as bad as hiding it
| behind menus.
|
| Sidenote, you _have_ to do this on native because pointer
| lock /warp is not universally supported in web browsers.
| oncallthrow wrote:
| As someone who regularly uses DAWs, this sounds like
| terrible UX
| jasonjmcghee wrote:
| Pretty interesting- on the first knob (with vertical and
| horizontal disabled) works great with how I thought the
| horizontal and vertical gestures were supposed to work - the
| difference being I did them on the edges instead of the center.
|
| I found this knob to be the best experience.
|
| Curious if others feel strongly for the centered experience.
| nixpulvis wrote:
| Ironically, this post perfectly demonstrates up why these
| gestures should not be used together. I could not reliably make
| it trigger one vs. the other and which mode it selects is not
| something the code can detect without continued input which will
| lead to discontinuities in value.
___________________________________________________________________
(page generated 2025-10-11 23:00 UTC)