Entering military time on web

22 Jul 2008 - 11:56am

Last reply:
6 years ago

13 replies

1089 reads

shannonsorensen

2007

Hello,

I am working on a web site where folks need to enter a time. Currently
they use and are comfortable with military time on a green screen. I'd
like to reduce potential errors by using a select input, but what a pain
it is when using a keyboard. Other considerations are using standard
time ,autocomplete and just a entry text input.

Does anybody have other suggestions I can I can throw into the mix and
test with?

Comments

22 Jul 2008 - 12:12pm

Steve Schang

2008

What kind of errors are you trying to prevent? My experience with 24-hr
time is that it is easier to enter because each time is only used once
each day. For example you can't get confused as to which 12:00 o'clock it
is, it can either be 12:00 or 24:00.

Are you working on a U.S. military application? If not I might refer to
military time as 24-hr time. Most countries use the 24-hr notation as
their standard way of referencing time.

Currently they can enter anything they want, for example they could
enter "eleven in the morning" or "11pm" or "11:00 am" ect. The entry
just gets read and acted upon. So right now nothing is an error.

The new system needs be able to track and store entered times, so they
can know longer be freeform text.

> -----Original Message-----> From: Steven Chalmers [mailto:steven.john.chalmers at gmail.com]> Sent: Tuesday, July 22, 2008 4:23 AM> To: discuss at ixda.org> Subject: Re: [IxDA Discuss] Entering military time on web>> I agree with steve.schang. What are you trying to fix? Can you> simply use the same input mechanism they are using on the green> screen?>> You say that you would like to reduce potential errors but what> errors are they experiencing right now?>>> Steven Chalmers>>> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .> Posted from the new ixda.org>http://www.ixda.org/discuss?post=31500>>

22 Jul 2008 - 2:50pm

Fredrik Matheson

2005

In that case, I'd say it's more a case of the users having enjoyed the
luxury of entering imprecise data and that it's merely a matter of making
them aware of the change to more precise time notation.
We use 24-hour time notation here in Norway and I find it far more precise
than AM/PM time – I can never figure out whether 12 AM is noon or midnight
;-)

You can enter the time in many ways:

• one text field for hours and minutes: you'll need a bit of logic to make
prevent erroneous input

• two text fields, one for hours (max value ≤23) and one for minutes (max
value ≤ 59). A common touch is to add steppers to each box, allowing
increments, or even better, using the up and down arrows to
increase/decrease the number

• two drop-downs, for hours and minutes

• my personal favorite, the time picker in Lotus Notes, which is one single
"drop-down" (not an HTML component but similar in appearance) that includes
hours and minutes, the latter in 15 minute increments. It's the best
interaction design I've seen for this problem anywhere, and its 15 minute
increments aren't much of a limitation in practice.

- Fredrik

22 Jul 2008 - 2:59pm

shannonsorensen

2007

Thanks Fredrick for the advice.

The second two bullet point solutions you mentioned are the area of concern. These folks are keyboard users, steppers and drop-downs can be cumbersome. Especially the drop-down when selecting times like 9am “09:00”, I would need to hit zero 9 times.

In that case, I'd say it's more a case of the users having enjoyed the luxury of entering imprecise data and that it's merely a matter of making them aware of the change to more precise time notation.

We use 24-hour time notation here in Norway and I find it far more precise than AM/PM time – I can never figure out whether 12 AM is noon or midnight ;-)

You can enter the time in many ways:

• one text field for hours and minutes: you'll need a bit of logic to make prevent erroneous input

• two text fields, one for hours (max value ≤23) and one for minutes (max value ≤ 59). A common touch is to add steppers to each box, allowing increments, or even better, using the up and down arrows to increase/decrease the number

• two drop-downs, for hours and minutes

• my personal favorite, the time picker in Lotus Notes, which is one single "drop-down" (not an HTML component but similar in appearance) that includes hours and minutes, the latter in 15 minute increments. It's the best interaction design I've seen for this problem anywhere, and its 15 minute increments aren't much of a limitation in practice.

- Fredrik

22 Jul 2008 - 3:09pm

Steven Chalmers

2007

Shannon: Thanks, that helps a lot.

Since your users are comfortable entering military time you should
take advantage of that since it simplifies the UI in that you don't
need to include a place for them to enter AM versus PM.

The edit box in which they will type the time should only allow
numbers and the ":" symbol. Any other characters should simple be
ignored. No beep, nothing.

The form should give the instruction to enter time in millitary
format.

The edit box should have supporting javascript to allow somewhat
flexible input. For instance the user should be able to enter the
following values for 7 am:

700
0700
07:00

When the user tabs out of the field the value should be checked for
validity and then reformatted to the proper military time
presentation of "07:00".

Don't confuse user input with what the system processes. Outlook is an
awesome example of a time field being able to accept a reasonably large
array of time formats and internally translate them to something usable by
the machine.

There's a tenet in programming that sounds roughly like "input anything,
output perfectly", meaning that nearly any value in the known universe can
be entered into a system, and something will always come out and will come
out in a consistent, reliable format.

Technically, you'd want something as free as a normal text field. And then
when it blurs, have a Javascript event magically parse this text field into
a nice looking string. Just like Outlook.

Personally, I hate dropdowns because they fly in the face of this type of
interaction. Combo boxes would be nice too, but there isn't native support
for that kind of thing (there are webkits and what not).

> The edit box should have supporting javascript to allow somewhat> flexible input. For instance the user should be able to enter the> following values for 7 am:>> 700> 0700> 07:00

I think this is the right approach. I'd add "7" and "7:00" to the list
of acceptable inputs for 7 am. I think this logic works:

1 or 2 digits => hour + :00
3 or 4 digits => hour + minutes

(ignoring everything except numbers)

24 Jul 2008 - 1:26am

Matthijs Rouw

2008

I don't really agree that a forgiving format should be implemented
here. This might very well be a matter of process than just
technical. And sometimes, a rule is simply a rule and people need to
learn about that once - important is how you teach them. Programming
a forgiving input field costs heaps and maybe the vast majority
already uses military time - waste of resources?

This is something that only one group can tell you; the users. Ask
many of them, implement their main suggestion, test whether they
indeed like what they thought they'd like.

This because there are more possible solutions:
- You could use a singe field with the colon character in there.
Input could go via typing 4 numerical chars (only). Disadvantage:
you'd have to type a leading zero.
- You could use two fields, one for the hours, one for the minutes,
with a colon in between. Disadvantage: they'd need to push the Tab
button but I guess that could be done automatically as well.
- You can use an informational label for the field,e.g. 'time
(24h)'
- You could process the data they enter in real time, and give
feedback on that by changing information next to, or underneath the
input fields into '= 7.23 pm' or a full sentence, if you like.

Hmm … I'm not quite sure I understood your point about hitting hitting zero
nine times to enter "0900". If there are two fields/drop-downs, you press
tab to enter the field, press "9" (and the field knows that must mean "09"
as the first number can't exceed 2), and tab past the minute field, onto the
next field.
As Steven points out, *one* text field with a bit of logic added to it could
interpret various numerical inputs and reformat them into proper 24-hour
notation.

Matthijs: I have to respectfully disagree with nearly everything in
your post.

Ensuring valid input based on process is nearly guaranteed to fail
and ultimately would cost far more than implementing my required
javascript.

I don't believe there is only one group that can tell me what the
right choice is here. The input from a usability testing group would
be much more useful than asking the users. Amazon.com doesn't ask
users: "How would you improve our book buying process?". They
watch users to see where they are having troubles with the book
buying process and then redesign those trouble spots.

For the single field with a colon character the user would not have
to type the leading zeros in "0030" to indicate 12:30 am. Typing
"30" would fill from the right and would display ":30", clearly
meaning 12:30 am. It would be trivial to zero pad this entry prior
to insertion in the database.

I agree that the disadvantage of two fields is the requirement to
tab. Auto-tabbing can be annoying if you don't expect it. Hitting
tab after entering the hours jumps over the minutes field because the
auto-tab put the focus in the minutes field.

Processing the field in real time is exactly what I proposed. If the
users are indeed used to military time what would be the point of
converting it to am/pm?

"Restricted format" approachs (as splitting input in many fields, or
worse, using pull-down menus) add:
- innecessary keystrokes or clicks and / or
- need to move the hand off the keyboard to the mouse and back, and
- mental preparation steps (splitting time in hours / minutes)
The last two are the most time-consuming tasks in KLM-GOMS.

Adding a couple of seconds to the task may not seem to do any harm.
But by the 1000th input, we've taken away more than half an hour of
user's life. Talk about killing me softly with your GUI.

Allowing freeform text, and validating / translating it back in a
transparent way, will always be the most efficient approach.
Requesting anything more than the minimum needed input (that can be
as little as just one character, as Micah pointed out) is a waste.