Hacker News new | comments | ask | show | jobs | submit login
JQuery knobs (anthonyterrien.com)
472 points by agumonkey on May 9, 2012 | hide | past | web | favorite | 96 comments

Nit: it's jarring that when I first mousedown on the control, the value changes. This makes small, incremental changes difficult.

Now, if I click on an area of the circle that is far from the pointer, perhaps it should snap. But if I'm close (or on top of the pointer), snapping is undesirable.

(compare to a physical knob, which is the thing being emulated here: touching the knob does not change the input, you must touch and then move)

This is the crucial annoyance with knobs in a lot of synthesisers (real and virtual). Another problem with them is that it's not obvious how you change the value. Do you drag to the angle you want? Do you drag vertically? Horizontally

Which then gets me thinking about direct vs indirect manipulation. Which then distracts me from eating my breakfast.

I think it might be interesting to have a knob-like control that responds to the scrolling action of the mouse/touchpad. At least with that, you'd have (somewhat) clearly defined up and down actions. Touchscreens could support this with a two-finger-up/down gesture, and then we'd be very well on our way to Trek-like UIs ;-)

Some iOS apps already do (can't remember right now).

I'm not sure if it's what Udo meant, but the date/time widgets are in this vein. Actually, a knob that functioned like those widgets would be quite interesting.

All popular software-synthesizer knob controls adjust the value by dragging vertically. Including the really well-designed ones like Ableton Live.

Which is why this piece of UI is rather counter-intuitive, and it's obvious the author hasn't ever really used any other software with knob controls.

But even then, I kinda think knob controls aren't very user-friendly either way. I can sort of understand their usage in software synths as a skeuomorph, but that's about it.

For my android app DJPad I originally implemented knob control as linear. Move up or right and the value increases, move down or left and the value decreases.

I realized this was a mistake when I gave my app to friends to test and had to stop myself from saying "no! you're moving the knob wrong!" and went back to the drawing board :)

Protip: If you want to make small incremental changes, mousedown on the knob and drag way out, making the radius of your turning motion much larger.

I actually thought that part was kinda nice in allowing me to make either quick large changes or small incremental changes. But then again, I'm not your average interwebs user, so I probably would be aware of the same issue if actually implementing it.

Made a pull request that supports arrow keys and mousewheel, which makes it more usable for finer adjustments: https://github.com/aterrien/jQuery-Knob/pull/3/files

this could be solved by requiring a minimum cursor movement before the value changes. If you want only a small change, you need to move it beyond the trigger limit, then back again

the same idea would help with getting exactly 100 or 0 values - if moving back set the "zero" zone between 0 and about -10, or going the other way once you hit 100 you need to progress significantly past it, say to about 10, before it wraps value

Beautiful, but, when is this ever the best UX for a control (outside of sound mixers and sequencers)?

(I'm expecting/hoping to get schooled on this.)

It’s a much nicer input mechanism to just click and drag left/right or up/down, or to use a scroll wheel (or trackpad scrolling).

What distinguishes a physical knob from a physical slider is that the knob affords relative movements, rather than absolute ones: you turn the knob with the same motion from every starting setting and your hand stays in the same place, whereas a slider has a distinct physical position corresponding to each setting. This allows control of knobs at various scales, from careful adjustments (“fine tuning”) up through fast dramatic changes. [And this is why the iPod wheel was such an ingenious input device.] Sometimes you want one type of control, and sometimes you want the other.

This particular software implementation, however, has the interface characteristics of a physical slider, not a physical knob. The visual display of these knobs is probably alright for some uses though, if you swapped out the mouse logic.

I really wish that browsers would get around to implementing mouse lock, so that it would be possible to construct interface widgets where a click/drag could perform some action without necessarily moving the pointer around the screen. http://dvcs.w3.org/hg/pointerlock/raw-file/default/index.htm...

Edit: to answer your question, I think relative adjustments are often appropriate in tools for picking or adjusting values, for everything from scrolling down a long page (witness the popularity of scroll wheels over clicking on scrollbars) to modifying parameters in interactive diagrams, to changing color or line width in vector drawing tools, &c. Physical examples of knobs are common: toaster settings, old manual camera controls, radio tuners, car steering wheels, pedals on a bike, fishing reels, hand drills, clocks & timers, and so on. Relative controls are underused in software, and I think showing them visually as knobs can be helpful in some cases, though getting the implementation details right is important.

My jQuery knob plugin called knobRot has relative controls. It uses sprites rather than canvas, and there are a few other issues in the tracker, but you can see a demo here: http://www.domitable.com/static/side-projects/jquery-plugins... and this is the source on GitHub https://github.com/AlexanderParker/knobRot

I also would like to have a way of locking the mouse position, but sadly that would give black hat developers a nice exploit (for harvesting likes etc).

This is good news, though I don't see it becoming a standard any time soon without a way of blocking nefarious sites from taking hold of people's pointers. Perhaps a browser warning bar when a site tries to lock the cursor (or does this already happen)?

It's not good UX for audio production software either. The good ones (in my opinion) work by clicking and dragging up and down (or left and right) and merely render the knob as if it's spinning.

Now as it happens I'm of completely the opposite opinion - I much prefer the kind where you have to click and drag in an orbit around the control, because you can move further away (screen space permitting) to achieve finer control.

Knobs are the primary interface in many live music controllers. Check out Ableton live, or the evolution uc-33 to see how they are commonly used. Would be very neat for a web based controller.

EDIT: Oops, I guess I can't read

Knobs are the primary interface in many DAWs because their developers copy hardware interfaces without too much thought. They translate to computer interfaces very poorly.

The main advantage of a hardware knob (over slider) is that you have very good control over it's rate of change. The main disadvantage is that it's hard to turn multiple knobs at once.

None of this applies to software knobs. I can't think of why would anyone want to use this over Tangle's sliders aside from prettiness.

The only sensible simulation of a "knob" in HTML I can think of would be a text field with a value that goes up or down based on how much you scroll mouse scroll-wheel. Thinking about it, I don't see why it should be different from a slider. You can have a tangle slider that is also scrollable with a wheel (if that is possible to capty with JS). Which is kind of the way normal UI sliders work.

The only time I enjoyed using software dial-knobs was when I had a hardware controller to tweak them with.

In that situation having the visuals match is handy to avoid dissonance.

In general, I dislike software knobs. They're an example of skeuomorphism that could be done much better.

Well, they also have the benefit of being compact which can be beneficial in complex audio applications, but I agree that they generally suck and would almost always be better off as a slider.

In all the DAW software and plugins I've used, there is at least an option to enable traditional up/down or left/right click-dragging. The knob still appears to spin, but you get the precise control of linear motion. Any good audio software will show you the numerical value anyway, so it's a bit of a stretch to say that knob widgets like this one are standard.

That's "traditional" in audio software. In 2D graphics software, radial manipulation is common. And don't forget the wonky 3D software modes where you just wiggle the mouse until something sort of rotates. Those are my favorite.


Sorry, I could have sworn I read it without it and then noticed it when I checked back later. I edited my previous statement.

It could also be used as a percentage indicator for instance a round a persons picture in the middle.

That wouldn't be a knob though. That'd be a circular progress bar.

My old boss's boss once told our team that he had a dream... that on really high traffic days, our site was so well tuned, all we did was sit back and turn knobs and smoke cigars. This combined with the right backend tools brings that closer to reality. (Because i'm way too lazy to program a real graphical interface)

In general this is probably more useful for touch devices--the paradigm of a knob is much more realistic when you're using your fingers. Though it would make a nice progress indicator regardless of touch.

The paradigm of a knob isn't that great at all. I think it's only because of the size contraints (you often need many controls) that you see knobs being used over sliders.

A slider instantly tells you the current level (relative to minimum and maximum) and is very easy to adjust.

A knob also instantly tells you the current level (relative to minimum and maximum) and is very easy to adjust.

Not even then. Touch interfaces pay no attention to the rotation of a single point, so this would require two fingers, and if even then, you couldn't rotate it more than 180 degrees (try it without lifting up your hand). Scrollbars seem to win as far as touchscreens are concerned. Also, it's dependent on the visual indicator. For example, to set something at 50%, you need to move the visual indicator to the 50% mark. So, you'd need to first determine whether the indicator is clockwise to the mark, or counterclockwise, and rotate in reverse accordingly. Contrast that with a slider - if you want it at 50%, no problem, just put your finger at the 50% mark and you're done - muscle memory can help with this.

Did you even try the demo? I'm using it on an iPad right now and it works great (with one finger even!).

Yes, I'm referring to a 'knob' interface, not this emulation. This is more of a round slider bar.

They take up less room than a slider. And certain controls are commonly radial: dimmers, volume dials, focus. Sometimes it just feels right.

I'm wondering the same thing, but one consolation is that I can see these being used as indicators vs. as a control.

It's the wrong UX for sound related apps because in that industry people expect to adjust knob controls by dragging on them up or down so they're going to be confused and decide these knob controls are "wrong".

Audio software made a bit of mess with the whole knob vs. slider thing. Digidesign released several products that used their linear fader code, but they only changed the graphics -- not the mouse code! Yup, you'd move up or down and the thing would randomly turn clockwise or counterclockwise.

Somehow this became a standard.

20 years of customer confusion and complaints yields this advice: there are at least three common modes for interacting. 1) up/down | left/right, 2) radial (follow the mouse pointer) and 3) relative radial (follow the pointer, but use it as an an offset in degrees of the original position).

The latter is useful for something like a volume control (or any real-world control, really). Otherwise one wrong click and you're at max.

In each mode you want both a linear and logarithmic scaling option. Otherwise you have the "soundblaster volume" problem where all the range is between 0 and 30, and 31 to 100 is largely ornamental.

There's a bonus mode using the number in the middle as a target. If you click and drag on that, you get the up/down mode even if the outside zone is normally radial. This guarantees that nobody is happy and seems to be the alternate standard in much audio software.

Click to activate THEN mousewheel to increment/decrement (again, using the linear or log scaling) is a sane compromise.

Beautiful, but I don't want to see this in the wild. Knobs are bad for the same reason that pie charts are bad. Perceiving one-dimensional differences is easier than rotational/angular ones.

For quantities, yes, but for ratios, I'd prefer pie charts and knobs.

"75%/25% odds" would be nicer on a knob display, for instance.

Not really for ratios. If there's a min and a max, sliders make sense.

You can make a better argument for a knob if you have an unbounded range, or an effectively unbounded one (making small adjustments on a large scale). Think old iPods.

I'd really like to see some limits put in -- if you approach 100 from the 90s, have it stick at 100 instead of wrapping around immediately. Same if you try to go below 0. Right now it's really hard to get the know to fix at the limits of its range, something easy to do with traditional sliding controls.

Agreed, there are some things (like volume controls) where you really don't want wrap-around.

It's hard to make it 100 without it going back to 0. Maybe a gap between them and if you're already moused down going to up to 100, it stays at 100 as you continue to move the mouse right, but will go back down as you mouse left?

Completely agree, but I think the solution is simpler: just like a physical knob, don't let it cross over from 100 to 0 and back. If it's 100, you need to drag it back around the centre to get to 0.

if (curLevel == maxLevel && angleFromCenter > 0 && angleFromCenter < 45){ // Ignore } else { // Process normally }

My nit: I can't crank it to 100 without it flipping back to 0 on me. If this was a volume control, that would suck huge.

Like a few other in the thread I'm now stuck looking at an application where I can use this. They look friggin' awesome.

For some reason, the basic CSS reminds me of Wipeout, and that makes me both nostalgic in general and nostalgic for my young naivitë for future (I bought everything associated with that game when I was ~12). It's weird that UX can evoke that sort of response, but now I want to use it everywhere.

I wanted to work on some of the usability issues raised in this thread, but I'm not the biggest fan of the style of the original JavaScript, so I ported (most of) the code to CoffeeScript:


I left out some of the configurability by choice, and there's no Cakefile yet, but I added the ability to color the knob through CSS via the addition of a hidden style target element. Maybe not a great practice, but I like it better than embedding style information in the code and HTML. Additionally, it'll draw resolution-doubled on Retina displays.

Feel free to hack on it.

I implemented something like this for my 'Clock' iOS app about 6 months ago.

Check out: http://itunes.apple.com/us/app/clock-free/id497161475?mt=8 and double tap to set the alarm using this UI metaphor.

The takeaway for me was that UIWebView is still too unresponsive to handle touch events, so although the app uses HTML5, the touch event handling had to be implemented in ObC.

Really nice. I'd make one change if I had the time to fork it myself... allow vertical and/or horizontal mouse movement to control the slider in addition to circular movement. In some cases (such as time-based scrubbing), having the control spin one or more times by moving the mouse across the window is easier than trying to adjust it by circling.

Being familiar with knobs in digital audio workstation UIs, it's somewhat frustrating that I have to trace the thing around in a circle. Convention is that clicking in the knob and then dragging continuously up or down or using the scroll wheel should change its value.

Nice, but a bit annoying to mix styles and other settings in the data attribute like that, and they would have to be repeated for each knob.

A library to easily parse custom CSS properties would be pretty cool. The "CSS" could be either in regular stylesheets (browsers ignore properties they don't understand), in a data-style attribute or maybe in a <style> element with a custom type attribute value. Browsers ignore properties and selectors they don't understand anyway.

      .knob::-jquery-knob { ... }

    <style type="text/jquery-knob">
      .knob { ... }

    <input style="width: 150px; -jquery-knob-skin: tron">

Extremely awesome. My only (nitpicky) objection: I wasn't able to do a simple

  $('#myProgressKnob').attr('value', _new_value_);
and have the graph around the edges update. The number in the center changes, but the circular part doesn't get updated (at least, for me). I really wanted to use this in my latest project (shameless plug: http://wwikt-peterldowns.dotcloud.com) but couldn't make it happen so I'm switching back over to the twitter bootstrap progress bars in the meantime.

Disclaimer: I'm a totally new to JS and could be trying to do something un-possible. Thoughts? Has anyone else been able to make this happen?

Use this instead:


Thank you!

This still does the same thing for me, can you show your code?

I never got it working. I switched to the twitter bootstrap progress bars instead.

jQuery knobs + jQuery Rumble


Want to help update the script to keep the number in the middle?

This is simply stunning. Fantastic work, can't wait until I have a good reason to use this.

I really like the interaction on my iPad with a couple small issues: don't jump with I first touch and don't allow wrapping from max to min.

Alternatively, I don't think I would want to use a mouse with these.

The design is visually nice.

UX-wise... I never encounter controls like this, they don't look functional, and I wouldn't necessarily be likely to click one in the wild.

I think we will see this being used in lot of 'web infographics'. I personally was never fond of infographics in the image format but it helped spammers derive SEO juice which is how the whole infographic mania started.

Infographics meant for web consumption should be made using HTML, CSS and JS not images and this library will help a great deal.

It would be a very good addition to Bret Victor's reactive document widgets.

Very slick looking stuff man. If I could suggest something, it would be to give an option to show the data display numbers outside of the circle, or give an option to call a callback handler when the data changes. This way a finger motion adjusts the knob, and the data display is not obscured. Good stuff.

These feel very strange. They don't behave like any knobs I've ever encountered in software.

It's pretty, but I think it would be more usable if it didn't wrap between 100 and 0.

A fair point, and I imagine it would be trivial to add a min and max to the configuration options. Without looking at the source, my hope is that it's utilizing <input type="range">, which has min and max built right in.

[Edit] I had to look. Apparently it's just adjusting the value of a text field, which is probably better for backwards compatibility but does make me a little bit sad.

Cute. One thing that would improve it would be keyboard shortcuts. The editing of the number in the middle feels a bit awkward too. I guess it might make a nice replacement for a slider in certain circumstances.

Maybe the mousewheel can be put to use here?

http://archive.plugins.jquery.com/project/mousewheel (untested)

Kind of ... the focus has to be on the number before the mousewheel works though: http://jsfiddle.net/dmethvin/gDfcY/

hmm, i was thinking along these lines: http://jsfiddle.net/gDfcY/6/

this gives NaN, tho, because I suck at javascript, but I'm sure there's something workable in there.

http://jsfiddle.net/gDfcY/8/ Seems to work, but it's probably not the most elegant way it can be done

For comparision, YUI offers a similar widget: Dial.

"It's like a real-world, analog volume control dial, but with much finer UI control."


'Dial' is a better word than 'knob'.

In British English the word has a variety of profane implications, inviting childish sniggers from grown men: http://www.urbandictionary.com/define.php?term=knob

The following are quoted extracts from Roger's Profanisaurus:

"knob 1. n. Penis; prick; John Thomas. 2. v. To shag. As in “I knobbed the arse off her”. knob cheese n. 1. Smeg-ma. 2. Foreskin feta found underneath Kojak’s roll-neck (qv) and around the banjo (qv) or cheese ridge. Also knob Stilton, knob yoghurt, Helmetdale (qv). knob chopper n. Precariously balanced lavatory seat which falls down while you’re having a piss and therefore must be held up manually. knob head . knob end n. Fuck wit; thick head; oaf. knob jockey n. Someone who sits on a door handle whilst the door is in motion for sexual gratification. knob shiner n. Someone who is always prepared to polish a pink oboe (qv)."

Source: http://en.wikipedia.org/wiki/Rogers_Profanisaurus

Reminds me of this: http://www.schillmania.com/projects/soundmanager2/demo/360-p...

... which has been around for a few years.

It seems that the text field accepts arbitrary numbers and then sets the knob to a rather random-looking position. It would make a lot more sense if these values were clipped to the range of the knob.

One use-case would be setting clock time, though with some modifications. I had such control in mind before. I think for some of us it would easier to make two clicks rather than enter numbers.

So I first tried this on mobile and that's where this interface becomes horrific. As my thumb slides over the number toward the top of the circle, I can't see what I've selected.

So I first tried this on mobile and that's where this interface because horrific. As my thumb slides over the number toward the top of the circle, I can't see what I've selected.

"jQuery Knobs" sounds like a term for dickish jQuery enthusiasts.

I don't like to sound negative but this looks to me the wrong way to do it.

You are redefining here a UX/UI element: The slider. Well, I like breaking the rules and innovation, but you have to care about the end user. I have been working with computers for over 10 years now, and I didn't figure out what these small circles do until I checked the HN comments.

I might be a little sleepy, it's late here; however, I have strong doubts that any Internet/Computer semi-literate will figure out what this do and how to make it works. This is the case where a 3D shadowed boundaries, little bars and gradient colors can make a huge difference and guide the user to use the tool.

This is stunning. UX metaphors can work in number of situations.

Yep. I have been waiting for something like this for a UI doodle I have. Brilliant start.

Thanks! We were starting to create our own custom knobs for our site (verelo.com). This saved us a lot of time. We'll definitely be contributing back.


Works beautifully on my iPhone. I can see this being used for filtering "results per page" on ajax shopping websites Great work!

Works really nicely on an iPhone – much better than a lot of knob controls in many native apps.

I would love to be able to use this with other canvas-shapes... How can this be implemented?

I wonder how long it will take before someone publish cubase.js now:)

Even for JavaScript, that's an accessibility nightmare. Horrible!

I thought this was going to be an article about "brogrammers,"

Am I the only one who thought this post was about people?

Cool coding though :)

I came in expecting to hear people ranting about why jQuery is inferior to some other Javascript framework / coding style. Instead the people are positive and the sample code is sweet...

Very nice!

complaint: no visual way to determine if a knob is read-only?

fuckin awesome!!

watch out, honeywell might sue you

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact