Spinbox direction hints and time relation

Question

I'm trying to write an input widget that allows to set a timer, having visually defined sections for seconds, minutes, hours and, possibly, days.

Right now it fundamentally is a personal project for my own usage, so my query is mostly out of curiosity, but I may decide to release it publicly at some point.

I wasn't satisfied with what the toolkit I'm using (Qt) could provide (QDateTimeEdit), so I decided to write my own.

While some touch-based devices use clock-face looking widgets, I don't feel them as immediate as they should: they may be fine for touch-only devices, but they are terrible on desktop.

Coming from old-fashioned desktop experience, I am bound to spinbox-like controls: a widget that shows the current value, and allows its editing through:

• primary mouse button, by clicking the "arrow buttons" shown on the side;
• direct keyboard input;
• mouse wheel or similar "slide" input;

My attempt is to use separated spinboxes for each field, so that the user can easily click/wheel a field in order to change the related value.

In this case, the first two aspects are, in theory, quite intuitive:

• the "up arrow" will increase the current field value and, possibly, the "parent" one: 00:00:59 would become 00:01:00 if the arrow is near the second section;
• typing the value automatically sets the value of the field or the overall timeout (I think I can solve that by managing keyboard focus, but this is not really the point here);

Then I wanted to add support for the mouse wheel or similar events, and here comes the problem. As we all know, the wheel/slide behaviour has become ambiguous in the last years (and for good reasons): depending on the platform, or even the user configuration, we could have opposite results, and swiping/scrolling for a numeric control is not always intuitive.

I thought about adding a "hint" about the direction, showing where the greater or smaller value will be; here you can see a possible attempt (don't mind the appearance and the right side rectangle, it's just a test):

The above follows the concept of "up", showing greater values above the current one. But I'm not sure about its intuitiveness, especially considering that we're talking about time and a time out, and that, depending on the configuration the "up arrow button" may be opposite to the wheel/slide behavior:

• should a greater time out be shown above or below?
• should the greater/smaller timeout follow the same direction of the wheel?
• should the direction respect the wheel or the arrow buttons?

I've seen completely opposite display modes on touch devices (eg. vertically displaying 59, 00, 01 or 01, 00, 59), but those are normally more intuitive: swiping up or down scrolls the displayed value. Mouse wheel events and arrow button clicks are different beasts.

I know that similar questions have been asked before, but in my research I've only found possible suggestions about what the arrow button or wheel/slide interaction may do, and showing a hint may result in unexpected behaviour: the visual hint may show higher values, following the arrow direction, or it may be the opposite following the wheel one.

I also know that similar issues have been raised before with related controls, most importantly the different behaviour between a spinbox and a combobox having similar values but using completely opposite logical orders: an "up action" on a spinbox increases the displayed value, while the same on a combobox (or its popup) may result in the opposite.

Furthermore, time is a very relative dimension: "up" or "down" may be perceived in different ways, and using time values for a timer (which fundamentally is the negative of a time perception) makes things even more confusing.

Answer 1

To strictly answer your questions:

should a greater time out be shown above or below?

If you want the up arrow to increase the number, above.

should the greater/smaller timeout follow the same direction of the wheel?

The OS likely already is taking care of that for you, all you need to listen for is "scroll up"/"scroll down". If the scroll up input was generated from a 2 finger swipe or a scrollwheel, and in which direction, ideally isn't something your app should need to care about.

should the direction respect the wheel or the arrow buttons?

If you listen to scroll up/down events, there is no conflict.

---

With that out of the way: I'd be very careful with these on desktop:

While they do give affordance to spin direction, they remove affordance that you can enter text via keyboard. They also are fairly noisy, showing 4x as many elements as a plain hh:mm:ss text field, and hard to use as in the worst case, you need to scroll through a list of 30 numbers. I believe that outside of combination locks, this pattern isn't widely used anymore in the physical world, so any skeuomorphic benefits it might have enjoyed when it was introduced may have evaporated by now (though the pattern itself is, thanks to Apple, still well-known).

Your concrete example also shatters the expected gestalt of a time input, as the spacing and the UI between the numbers is quite large.

I personally dislike those things on phones already (the material design time picker is superior as it allows you to set the time in 2 taps, as opposed to extensive swiping), and on desktop they feel even more out of place. On desktop applications, I prefer overwrite-based time inputs:

Here, instead of an insertion cursor between the digits, an overwrite cursor is placed on top of a digit. Scrolling/arrows affect that digit only, separating characters which don't make sense being edited anyway are skipped from the navigation (h, m, s in this example, but it could also be colons, commas or semicolons).

If you really do need to give affordance to scrolling up and down, you also can add arrows, similar to windows 11's clock app:

(though, again: The up/down affordances take up quite a lot of space)

the "up arrow" will increase the current field value and, possibly, the "parent" one: 00:00:59 would become 00:01:00 if the arrow is near the second section;

I would be careful with that. While there are situations where you want to count up continuously (eg in a timeline), there also are ones in which you don't want it (eg changing an alarm from 14:02 to 14:58)