4

In a GUI application I have a setting for a time interval. In this case, it's a refresh period, but the same issue comes up when you set how early you want a calendar reminder, how long to snooze an alarm, how long to keep old messages, &c.

There seem to be three accepted patterns for doing this:

  1. A list of preset intervals. There are often technical advantages to doing it this way (you can coalesce different events with the same interval, allowing the processing system to handle several events at once). It's also very simple to understand, but it doesn't allow the user to specify an arbitrary time interval.
  2. Use a text input for entering some numbers, alongside a mechanism for selecting the units, such as in this example from Google Calendar. This allows entering any interval, but it's hard to enter compound intervals (e.g. a month and two days). It's also inconvenient to make changes across unit boundaries, such as changing from 13 days to two weeks.
  3. Use a slider. This is simple to understand: unlike the text-based approaches, it's easy to see the rough magnitude at a glance. It can be very tricky to enter a time precisely, especially through a touch-screen interface. I've only ever seen this used with a linear (as opposed to logarithmic) range, which means it works badly if the input can range from a second to a week.

There are also combinations of the above approaches, such as a slider with an editable text field next to it, or a text field that lets you enter free-form text such as "1 week". Are there any other accepted patterns for setting a time interval graphically? I'm especially looking for something that allows precise data entry over a wide range of input values, and I don't think any of the approaches I've listed are good enough.

5 Answers 5

1

The problem with having such locale-dependent and non-constant things as months and years is their inherent ambiguity. "Does a month equal 28, 29, 30 or 31 days?" "Are we talking about the bankers' year of 360 days, or 365, or 365 1/4 or 366 days? (putting aside more weird numbers)" With this in mind, a combination of numerical controls seems to fit the bill:

mockup

download bmml source – Wireframes created with Balsamiq Mockups

Please note that these are stock up/down buttons and they are horrible from the mobile/touch perspective. In reality, one needs larger up/down buttons directly above and below the "steppers" (like these):

enter image description here

2
  • 1
    This is a really good start, but it opens as many questions as it answers. What should it do when you you increment "minutes" from 60 to 61? Wrap around, wrap around and increment "hours", or stay at 61? What if you type "120" into minutes? A compound control like this has the problem that it's much more click-intensive to change (say) from the value in your example to "1 day", because you need to reset each control.
    – Dan Hulme
    May 20, 2013 at 9:36
  • @DanHulme if you increment from 59 to 60 it should wrap around and increment hours. If you type 120 into minutes, it should wait till you change focus to another control (e.g. if you accidentally typed 120 instead of 10) and then increment hours by 2. To reset a component, there probably has to be a reset trigger near the label (although if you implement scrolling speed dependence on the time the button is pressed, scrolling back to 0 is easier). To change to 1 day, the quickest way is to a) depress down button in days, hours, minutes, seconds, b) click once on the up button for days. May 20, 2013 at 9:47
1

I really like the solution of Microsoft Outlook:

They have a combo-box, where frequent time-values can be easily picked:

Outlook screenshot

If you want something more accurate, you can edit the textbox directly, where the units needs to be specified. It auto-completes with the most probable unit:

enter image description here

enter image description here

It looks like it's able to support most cases; you can quickly set from a predefined list, but also specify something accurate when you need it.

1
  • I like the idea of frequent time-values, but that list is rather prohibitively long... it seems like this might be better implemented on a mobile-type scroll wheel.
    – rach oune
    Oct 17, 2014 at 0:30
0

So the real question is how great a need do your users' have for custom intervals? Do your users NEED to be able to input one month and 2 days? Probably not all that likely and you don't really want to design for exceptions.

Sliders are fun but can be a time consuming to QA and of course have accessibility issues to overcome.

In the case of one month and 2 days, the user could probably use a reminder at the end of the month that in 2 days, they need to do something. Anything else can be handled via the weeks choice.

The combo of inputting a qualifier - number, beside a preset selection of minutes, hours, days, weeks, months gives you the broadest set of user controls with limited possibility of input error.

I think we'd need to know a little more about your users before we can give a definitive answer for them. In general, the combo works.

0

As is the case with may UX issues, the "best" solution depends on what you expect will be in your users' minds as they use your UI.

Going along with your three cases:

  1. Pre-determined ranges - These might be great in your case, since it sounds like you're dealing with the "period" of a repeating operation. However, it would be terrible if you were designing a calendar, since the user is thinking "Meeting at 3pm on Tuesday" and not "38 hours, 22 minutes from now".
  2. Text field - The difference between great and not-so-great implementations of text field date inputs is (in my opinion), whether or not natural language is supported. For example, if I can type "every morning" or "every dat after lunch" into the field and get a reasonable result -- that's impressive.
  3. Sliders - These are super annoying if you have a specific date/time in mind, especially if the user must use more than one slider to define a time. Imagine if I want to schedule something for each wednesday at 9:15am and you made me use a slider to find "wednesday", another to fine "9am", and a third to find ":15". I would end up spending four times as long to define that piece of data, compared to just typing "Every wednesday at 9:15am"
1
  • There's a reason I specified a time interval in the question. I think setting a date and time is a separate problem with potentially a completely different solution.
    – Dan Hulme
    May 20, 2013 at 11:26
0

I thought so little of the existing methods that I decided to make a new one for a touchscreen interface, consisting of concentric dials. It's used as a "custom..." item in a list of preset intervals (because there are technical reasons for preferring certain intervals). It looks like this:

Screen shot on Nexus 7 (click through to full-size)

In the resized screen shot it's quite hard to see the unit labels, but they're "days", "hours", "minutes". The user drags any dial to rotate it, and at the end of a drag, the dial smoothly settles at a tick mark. (That is, you can't drag it to be in between two ticks.) Dragging across 0 increments or decrements the next dial smoothly. The user can also double-tap a dial to spin it to that point automatically. Catching the dial (by touching) while it's spinning interrupts the animation and allows a drag.

The innermost dial (for days) has a "cut-out". When numbers go behind the cut-out they're replaced. From the state shown in the screen shot, if you rotate anti-clockwise, 3 comes out from the cut-out; or if you rotate clockwise, 11 comes out from the cut-out. This means that the range of times isn't limited by the numbers on that dial: the maximum value could be arbitrarily high (but is limited to 30 days in my use case).

I was worried that it might be a little too hard to read off the current value, but this is mitigated in use by the enclosing screen (in the background here) displaying the current value in written form (in the user's language). I also made an experiment with having the read-off point for the dial on the right instead of the bottom, so the numbers would read left-to-right, but it looked very unnatural to have the numbers rotated that way. So far, the response from my trial group of users has been encouraging, and I'm waiting to learn how it performs "in the wild".

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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