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 ;-)
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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)."
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.
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.
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...
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)