Approaches for setting a time period

Question

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.

Answer 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:

^{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):

Answer 2

I really like the solution of Microsoft Outlook:

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

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:

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.

Answer 3

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.

Answer 4

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"

Answer 5

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:

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".