3

I'm creating a custom skeumorphic dial and I have some doubts about what could be the better way of interacting with it using the mouse, which should be as intuitive and effective as possible.

Dial example

Right now my control has the following rules:

  • click and drag on the cursor (the small circle near the edge of the internal circle) allows angular control;
  • click on the scale (the outer annulus) selects the value directly, while dragging allows angular control;
  • click and drag anywhere else: linear control (vertical/horizontal)
  • mouse wheel;

There are two problems here.

First, I'm afraid that the linear control can be confusing, expecially when the dial is very small; maybe changing the mouse cursor (circular arrow on angular control, NWSE on linear) could be a solution? I'd prefer to leave the linear control option, which is sometimes faster than angular, and in my program it could be very useful since there are about 100 of them.

Second, linear control on dials should be available for both horizontal and vertical directions, and the reason is that some dials could be at the edge of the screen: if one control is near the top edge, for example, increasing its value would require at least two click+drag actions to reach the maximum value if the control orientation is only vertical. What could be the best practice for the movement > value conversion? Radial distance is an option, but wouldn't account for relative distance once the range is reached; another possibility could be waiting for a minimum amount of pixel-space reached and then decide the orientation (horizontal if delta X > delta Y, otherwise use vertical).

PS: please, don't suggest to use sliders: there are specific reasons for dials, most importantly the space occupied by the whole interface, which has to contain all controls, and tabs/multiple windows/mdi/panels are not an option.

3

Nielsen&Norman have written this about knobs:

However, virtual knobs are physically challenging to manipulate with common input devices such as mice and trackpads, which don’t have a natural affordance for rotation. Because linear-input devices like mice have difficulty executing rotation, some designs add a hidden linear-dragging functionality to the knob, allowing users to click and drag up or down, vertically, in order to increase or decrease the parameter value. However, this behavior is not expected, and usually has no signifier, so users may never discover it. (Plus, if implemented poorly, it can wrest control away from those attempting to move their mouse in a circle to mimic the rotation of the knob.)

In short, angular control makes for harder manipulation, linear control is not discoverable and can be disorienting.

From my own personal experience, I have found linear controls frustrating and unintuitive, so I think your first hypothesis might be justified. However, don't take my word for it — test it. Your original design and all the suggestions you put forth can be tested with users (qualitative testing, though you can supplement it with quantitative testing, too). Then you'll know what works best.

Also, I'd recommend you to toy with other ideas. You say space is limited: why not implement a slider that grows larger on mouse down? Or a slider that uses the entire screen area as its drag area? (I believe the iOS brightness and volume sliders in the control center work somewhat like this.) Or a slider that appears on button click?

  • Thanks for the reference, very interesting. I decided to leave both angular and linear controls, which are distinguished using different mouse cursors. Also, linear control uses a value that combines both horizontal and vertical movements: (-oldX+newX+oldY-newY)*ratio, where ratio is based on the range size. I thought about other ideas, but I'm developing an editor for a musical instrument that has more than 250 parameters: using dials is not only more consistent with the real instrument, but allows viewing of all controls in a glimpse. You can see some images here: bigglesworth.it – musicamante Jan 1 '18 at 21:52
  • @musicamante Cool. I guess I'm not the target audience here, but the UI seems like a mess to me. I really would recommend doing user testing with the actual audience, to see if the result is usable for them. If you'd like, I'm willing to help you prepare it. – Tin Man Jan 2 '18 at 14:39
  • Thank you @tin-man, I realize that the UI seems very confusing from a "normal user" perspective, but we have to consider that synthesizers are very complex instruments and their users are accustomed to complex interfaces. I actually received very positive responses about the UI and its layout, which is rather aligned with similar programs: if you look for "synth editor" images you'll see :-) Other approaches are unsatisfying, uneffective or don't really improve usability: collapsible/tabbed panels are distracting, simplified controls that expand to full controls make no sense in this context. – musicamante Jan 2 '18 at 18:17
  • @musicamante I understand—rereading my comment, it sounds too negative. It certainly might be the optimal UI for your users. Still, I recommend testing it out with your target audience. User feedback might be relevant, but it's coming from current users—you're not hearing from those who never tried it or tried it and gave up. – Tin Man Jan 2 '18 at 20:11
  • 1
    @musicamante "Real world" synths use(d) rotary pots because they can be packed closely and are (probably; if memory serves) cheaper than straight-line pots/sliders. However, as noted in the answer, a UI-emulation of a rotary control is difficult to control with a mouse. Personally, I'd consider using normal sliders (either vertical or horizontal): easier to control, and you could definitely get two, probably three in the same space as two rotary controls. – TripeHound Jan 5 '18 at 9:28
0

garageband for Mac does what you're trying to accomplish, I think. They stick to the Y axis; up turns the knob up, down turns it down. Here's a video of the interaction: https://youtu.be/LcJwLhRVmyw

  • 1
    OK. However just because one app has a certain behaviour that doesn't necessarily mean it's the best way to do something. It's useful as a bit of research, certainly, but I wouldn't want to suggest 'This app does it, so everyone should copy' without a bit more research. – JonW Jan 5 '18 at 9:36
  • Good point, Jon. What I like about the Garageband (a long-standing legacy app) example is A) The app is rooted in skeumorphism - they're going to use a dial nomatter what, just like musicamante desires and/or requires and B) Apple has thrown away any confusion with trying to utilize the x-axis. They offer one straight-forward way to interact with the dial; up and down on the y-axis. – Brent Enarson Jan 5 '18 at 23:32
  • There are two things I really dislike about y-axis control. 1. With values starting from the top edge to its maximum (90° to 180°) it feels counterintuitive to move the mouse up when the visualized value goes "down" on the right side of the dial. 2. When a dial is near the vertical edge of the screen, it might take more than one click+drag operation to reach the wanted value: if the dial is near the top of the screen, the current value is 0 and the user wants to reach the maximum (127) it might require him/her at least 3 click+drag movements; see this example: youtu.be/WfPXNh5Srs8 – musicamante Jan 7 '18 at 1:14
  • The same (2) problem happens for dials near the bottom edge of the screen or any horizontal edge in case of x-axis limitation, and (1) can be a no-problem, since one would imagine that moving the mouse upwards means increasing the value. Still, I've to consider that, with the layout I use (with more than 200 controls that have to be on the same window) lots of users will have the screen completely occupied by the window, leaving some dials near the edges; some users with small screen resolutions even reported the window going way beyond the screen size. PS: sorry for the double comment. – musicamante Jan 7 '18 at 1:26
  • I think you're considering all of the right edge cases. And unfortunately (or fortunately?) not everyone is going to use, "the perfect method," for interacting with these knobs. They'll discover 1 of your 4 and keep with it. Is your mouse wheel method engaged on-hover? Sounds cool. Re: issues with being too close to the screen's edge, perhaps tighten the distance of mouse drag to adjust from 0-100%. Adobe Audition uses maybe 72 px to turn knobs up / down. Audition in action: youtu.be/7vpl6W6JYu4 – Brent Enarson Jan 9 '18 at 22:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.