When presenting (in a simulator) a user interface, that normally uses turning knobs, how should the mouse wheel map to the turning of the drawn knob?

I am looking at a simulator which draws a bunch of knobs. The knobs turn clockwise to increase the associated value and counter-clockwise to decrease it. However in some models, one value may be represented by a vertical wheel that looks similar to the mouse scroll wheel and this is always turned down to increase the value. The value may be represented by knob in other models with standard turning clockwise to increase.

The knobs can be turned by moving a mouse pointer over them and either clicking or turning the scroll wheel. Left click always increases the value and middle click always decreases it and this is consistent across the models. However in some models scrolling up turns the knobs clockwise and in others it turns them counter-clockwise and this is confusing.

So I'd like to file bugs and/or suggest patches, but I don't know in which way it should be made consistent.

  • I mentioned, that there is a value which when represented by vertical wheel rather than knob is definitely increased by scrolling down, but now that I think about it, for the knobs turning up to increase seems more natural to me. – Jan Hudec Aug 26 '15 at 20:35

I'm guessing this is a simulator for internal systems only? Because if it is to be distributed to many users there are going to be all types of devices some with no mouse, some with a mouse but no scroll wheel, and some with no middle/right click. So it would be best to drop the wheel interface all together.

If it is on standardized devices, and to answer the question from pure opinion/intuition, scrolling up should turn knobs clockwise and vertical wheels upwards. Scrolling down should turn knobs counter-clockwise and vertical wheels downwards.

The vertical wheel reasoning is fairly obvious, it matches the motion on your mouse wheel. When you scroll down it scrolls down and decreases.

As for the knobs, you want to keep it consistent with the wheel, so up = increasing value. Clockwise is more commonly associated with increasing value, for example a clock. As the hands move clockwise time value increase, from 1:00 to 12:00. So in this case up should be clockwise.

  • It is completely public. It runs on normal PCs and I have not seen one without mouse for ages and I have not seen mouse without scroll wheel for quite long either. There are too many controls, so mapping them to keyboard is not an option; nobody would remember the keys anyway. There are always two options, one with clicking (left is always increase, decrease is either middle or shift+left) and one with wheel, but unfortunately it is not consistent. – Jan Hudec Aug 26 '15 at 22:20
  • 1
    By the way, please read the bit about vertical wheel again. It is an unusual case where scrolling down increments. It is a rather special case where it makes kind of sense (which does not translate to the knob). – Jan Hudec Aug 26 '15 at 22:21
  • I have a few mice that don't have scroll wheels though admittedly they're cheaper. And a lot of all-in-one pcs are touch screen that won't have middle click or scroll wheels, but I suppose most users will provide a mouse for those. I also assumed you were trying to change the action of the vertical wheel when you redo this because to me it seems much more intuitive to increment when you scroll up not down. – DasBeasto Aug 26 '15 at 23:18
  • You should probably also mention touch. This is an increasingly common feature, so the system should respond to touch gestures appropriately. – phyrfox Aug 27 '15 at 1:16
  • @phyrfox, good idea. Drag is pretty obvious (drag right to turn clockwise, drag left to turn counter-clockwise) and will work with touch and will work with button-deficient rodents. – Jan Hudec Aug 27 '15 at 9:17

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.