Why shouldn't I ask my users to enter times using military format

Question

I have a form that asks users to enter a start and end time for an event. For many years, we have allowed them to enter the times by selecting the hour (1-12), minute (1-60), and AM/PM from three drop down boxes. This has worked fine without complaints from customers. However, today I was hit with a request to change the input to one text box for the user to enter time in military time (aka 0000 - 2359). In my gut I believe this is a bad idea but am having trouble coming up with any hard facts.

What are the best reasons I can give that this would be a bad idea?

If there is a better solution for entering time, what would it be?

Also, FYI the users filling out the form run the gamut from very little skill with computers to advanced users. They are in no way military related.

Update: All my users are local and no other forms (web or print) use military time as the standard.

Answer 1

Three dropdowns are a nightmare usability-wise. You can cut these down to two by eliminating AM/PM and moving to 24-hour format, but still: a dropdown with 60 items is overkill.

I'd much prefer to enter time "manually", provided that these input boxes will be intelligent enough (say, they should be able to convert 18 to 1800, 0 to 0000, allow : as a separator, etc.). Plus do not allow users to enter incorrect data in the first place.

To answer your question: I see no reason to disallow your users to do what they want. After all, they are users.

Answer 2

I can see why you think this is a bad idea, silly users input wrong format etc.

However have you considered a jQuery Masked input box?

Answer 3

"They are in no way military related."

That's a good enough reason for me. It's an uncommon format that, while not exactly "user-hostile," is nonetheless not the way most of us are used to seeing dates, and requiring your users to do the conversion in their head will lead to arithmetic errors eventually.

That said, drop-down boxes aren't great either. Best to go with 2 input boxes and an AM/PM dropdown, in my opinion.

Answer 4

Honnestly, I think using AM/PM format is a bad practice, but that may be because I'm used to the 24 hours scale.

One reason against is that if all your users are used to the 12H scale, then most of them might still enter 1:00 instead of 13:00 for 1:00. Since the PM is not here, it will result in mistakes.

However, one good reason to do the switch is simply because it's the international standard.

Depending of what you want to put the emphasis (speed or functionality) you can use a time picker that would rely on regional setting to diplay the time in the user format or use a clock-like control. If speed is important, you might prefer a simple mask-textbox.

Answer 5

It may not be a bad idea. Imagine the case where users must enter that bit of information lots of times, for example because they are in call support. Or they may find the dropdown boxes not usable enough, even after having tried them. They may prefer that other format.

It is usually a good idea to talk to the stakeholder and ask him: "Why do you want it this way?" you can then contrast their ideas with yours, but if yours are only that you have the "gut" feeling that this is not right, guess who will win the argument. The gut feeling is not a valid business argument - especially when the business is not yours.

So in short, do what your customer wants - just make sure that they understand their options well, and point out to them any inconvenience that they may have foreseen - once you find one, that is.

Answer 6

You might want to consider using the jQuery timepicker (or Telerik DateTimePicker in Time-only mode for WinForms) and also build in support, on the backend, for multiple formats in the event that javascript is disabled.

Answer 7

In my own frames, I accept times and dates in a wide variety of formats. When the field loses focus, I'll try to parse the input and format it into the "correct" or "official" format. This gives the user a nice way to enter the data and a visual cue when something is wrong.

For example, in a date field, I'll accept "1" as "01.12.2009" (current month+year). In a time box, I'll accept "1030", "10 30", "10.30" (i.e. I just filter out anything which isn't a number). "010409 1125" becomes 1. April 2009, 11:25am.

Answer 8

Well, from a user interface standpoint, this could be a mistake simply according to some of Jakob Nielsen's user interface heuristics:

"Match between system and real world." If your users are not used to entering dates in military time, asking them to do so for your app can be distracting at best, and frustrating at worst.

"Error prevention" You are not eliminating error-prone conditions, but possibly introducing them.

There is also the question of why this change is being made. Are customers complaining? Is data coming in incorrectly? As mentioned by others, are your users used to military time? Any interface change should happen for a reason, IMO, because you're going to change the user experience and there will be ramifications for that; it's just a matter of how large those ramifications will be. My assumption is that data entry errors are supposedly going to be avoided -- but are they? Asking a user to enter a time as "XX:XX" and parsing out the semicolon (or, as Aaron Digulla stated, ANY non-number characters) and then converting it as needed seems less likely to result in errors than asking a user to enter a time in a format they are not used to using daily.

My concern would be that a user wants to enter 3:30 PM, and, while not paying much attention, simply enters 330. This is now 3:30 AM, and the user will never know the difference, because the app takes the information and happily assumes that this is what is meant. However, allowing the user to enter the time in "XX:XX" format and having an "AM/PM" selection makes much more sense.

As far as hard facts, well, I don't have them either. But if your boss/client won't be swayed by Nielsen's heuristics, I'm not sure what can change their mind.

Answer 9

date/time input through select boxes is a horrible UI design.

but, if some of your users come from the few countries that stick to AM/PM for time format, then forcing the "military" format on them without assistance from the program is also bad. use something like the jQuery masked input plugin.

if i was doing this, i would use a masked text input and a "PM" checkbox: if the value is more than 1259, the checkbox is disabled. otherwise, it's clear by default.

Answer 10

Hmmm, describing the 24 hour clock as "military time" and then noting that the users are not military makes me a more than a little twitchy.

It will depend on your users but I think that it is more than reasonable to expect people in contemporary society to understand the 24 hour time format and to be able to enter times using that format (given that I would - possibly naively - expect that format to be in use for bus, train, plane and other timemtables almost universally for the simple reason that its unambiguous). Perhaps this is not true worldwide - but it is certainly true across Europe.

That said, changes need to be made for a reason - "if it ain't broke..." is a very sound maxim for a working site and whilst I wouldn't ever willingly use am/pm for time entry I don't have a problem with use of dropdowns for time entry - especially as one can type "into" them. In this case I think that going from drop downs to text boxes is most likely an opportunity to introduce errors (although again it rather depends on the users).

Answer 11

Few outside the united states knows the words "military time". They also prefer 24-hour format.

If you want globalization, you can do one of the two:

• use accepted and de-facto standards, such as ISO8601 date format, 24h time and speak English
• dive into the nightmare of the vast regional-based localization complexity (some unfortunate programmers have to do it anyway. Then they support AM/PM, unicode and never-showing-yellow-color for certain cultures)

Answer 12

Why not use a TimePicker control of some sort?

You shouldn't force non-military users to user a strange to them time format.

Answer 13

I cannot believe how much consideration this idea has gotten. Forcing your user to do things your way, because it's "more efficient" is a terrible idea.

Your forms should be both streamlined (power users can enter data quickly from the keypad) and comprehendible (first time users can navigate successfully). The conversion to 24 hour time will throw people immediately. I lived in Quebec for almost six years and still had troubles switching back and forth from 24hour time. DON'T DO THIS.

Answer 14

Just in addition to all the rest of comments you should thing about one more thing.

Programmers and designers usually think the client pays us just for creating what he tells us to... That's only half true. They pay us, even if they don't realize it, for telling them what they need, what's best for them.

Of course, the final decision is always theirs, as the pay, but if you feel it is wrong and you think you know the business model better than them, then do not blindly accept whatever they told you to do.

Answer 15

Oh my.

My advice is to quit and find a different project.

We did a scheduling app for a "military customer" - and even they could not agree on what constituted "military time". Half of them wanted something called "Zulu Time" - the other half wanted "GMT plus offset" - then some wanted local time in 24h format. Contrary to what our contract specified, a Colonel insisted we use "Zulu" - we made the change for political reasons (in violation of our contract) - and then HE missed showing up for a scheduled event, because he thought it was in local time. Then contract management came down on us like a ton of bricks.

(never mind that the published schedule also used an obsolete "offset" that was a cold-war holdover meant to "fool the Russians").

In that this is just me sharing a war-story. . .

The real answer is to Elicit Requirements from your customer. Get those requirements SPECIFICALLY written into your contract. Make sure that the stakeholder who is actually writing your check, agrees. Develop to that specification exactly. When someone complains tell them to pay for a contract mod. You'll probably be changing this back and forth among many different settings for the next 10 years. You'll have steady work, and you'll understand why military contracts frequently go way over budget and are never on schedule.

Answer 16

In any case, assuming that all input is by logged-in users, you can provide multiple mechanisms (and certainly multiple ways if displaying time) and make the choice a user preference. But I'd strongly recommend that whatever you do, for any given user times should be entered and displayed in a consistent manner.