views:

238

answers:

6

What's a good web-based UI for capturing a time duration from the user. Lets say that we want to capture a time duration in minutes. But would like to present it such that the user can enter in hours and\or minutes.

Just use 2 textboxes for hrs\min? Or a single textbox and let them type in "1hr 31min" or "91 min" ?

Or is there something better?

+1  A: 

Just let them type the numbers only in a pre defined time format.

Place 2 textboxes for hour and minute without the hr or min.

Also you have to define whether it is a 24 hour system or 12 hour.

rahul
Well, its a time duration. So there's no 24-hour\12-hour concept right? They could theoretically enter "32 hours 30 minutes"
HS
Ok. What happens when he enter minute greater than 60?
rahul
A: 

Have a look at the jQuery plugins (www.jquery.com), you should find some useful time picker components.

Mark Redman
I took a look at two of them and they were both less usable that plain textboxes. I think this is overengineering of trivial problem.
Josef Sábl
in that case I would go with basic text boxes or dropdownlists using validators.
Mark Redman
+1  A: 

If you have two text boxes labelled hours and minutes then you need to deal with case where the user types into both of them.

3 into h and 35 into m => pretty clear. 3 hours 35 mins

nothing into h and 95 into m  => 1 hour 35 mins (probably update the display to show that)

but what about

2 into h and then 95 into m => does that mean 3 h 35 or 1 hour 35

I've used too many annoying UIs where changing a field zaps other entries to be confident that I can devise an unastonishing set of behaviours.

Hence I would go for a single box into which we can type 3h or 1h 35m or 95m and have a separate read-only display of the interpretation.

There seems to be an opportunity for a nice widget to allow a mouse driven entry, in the same way as a calendar widget allows date entry. A little clock with dragable hands?

djna
+1  A: 

Well, separate hours and minutes fields is the safest but slower to use than a single field. You can default the hours to 0 if you don’t expect many durations over 1 hour.

Maybe it depends on your population, but I expect users will be able to handle hours and minutes in the same text box if you provide a prompt, such as “Time duration (hrs:min):”

With that prompt, accept any initial unbroken string of numbers as the hours and any subsequent unbroken string of numbers as minutes, so that all of the following input are treated as equivalent.

  • 2:30

  • 02:30

  • 02:30:05

  • 2.30 (or maybe not: while great for keypad entry, but you may want to make an exception for the decimal point to allow the user to enter fractional hours, such as 2.75 for 2 hrs 45 min.)

  • 2 30

  • 2 hrs 30 min

  • 2 hours, 30 minutes

  • 2jaQp 30!!!!

I see no reason to require that the minutes be less than 60. The user should also be able to express the time as:

  • :150

When the focus leaves the field, auto-correct whatever the users enter to the specified (hrs:min) format to feedback the interpretation you made.

If all you need for your purpose is a rough approximation of time (or your users are only estimating anyway), then consider option buttons or a dropdown list with ranges of duration (e.g., 0 to 5 minutes, 5 to 15 minutes, 15 min to 1 hour, Over an hour.). Or if there are definite bounds on the durations and the intervals are functionally linear, you can use a labeled slider.

Whatever input format or control you use, it should be compatible with the source of information. Where do users get this duration? What units, format, intervals, and degree of precision are used there? How do users think and talk about the time among themselves?

Michael Zuschlag
Your example of :150 will not work with the rest of the answer as it will be interpreted as 150 hours. Anyway, I don't think this freedom is any good for the user as it is something he will not expect and generally will not know how to use it
Josef Sábl
By "initial string of numbers" I meant the initial string when it begins with a numeral, so :150 has no initial string of numbers, so hours are 0 and minutes are 150. I can't see how unexpected freedom will be a problem. Most users will never discover it (they'll never think of typing "2 30"), but those that do may find it useful (typing a colon is relatively awkward on many keyboards). Unexpected _limitations_ --now _that's_ a problem.
Michael Zuschlag
A: 

I think there should be no client side correction for the minutes greater than 60 as somebody suggested. It would only be confusing and generate unnecessary problems.

User entered the data so he should understand what he typed and there is no need to correct him.

I would leave these fields as filled by user. On the server side I would just calculate total minutes as:

$total_minutes = 60 * $_POST['hours'] + $_POST['minutes'];
Josef Sábl
A: 

Thanks for all the feedback.

What I finally ended up doing was, having a single textbox that shows the time duration in the format "xxhrs yymin"

The user can edit it and when focus moves away from the textbox, it recalculates the duration and reformats the text into the canonical form.

The parser to interpret the text entered is fairly liberal.

It's a set of regular expressions to match any number followed by 'h' or 'm' or 'd' to represent hours, minutes and days. If it doesn't find any 'unit' with a number in front of it, it assumes you have typed in a pure number as minutes and will interpret it as such.

So if the user types:

"1.5h", it will reformat to "1hr 30min" upon leaving the textbox.

"90 min" will also be reformatted as "1hr 30min"

The parser only looks at the first character following the number, which means you can enter "1 day, 7 hours and 19 minutes" and it will recognize it correctly.

Of course, it would also recognize "2 holes and 19 mice" as "2hrs and 19min".

I think I can live with that.

HS