What are the different ways to have fields in an application for date, time, or both? What are the pros and cons for each?
The most common seem to be a combination of 2–3 drop-downs, or some form calendar widget. Are there other options available? Which one is the most user-friendly?
I do believe a regular textbox with an indication of the expected format is often enough. Like Kevin mentioned, if you use a date picker you should absolutely provide a method for direct entry. Many people prefer to simply type the date.
But this is what I do on Techinsurance.com...
Of course I have client and server side validation in place as well. The only other feature I added is that if they enter 12121999 or 12-12-1999 then the text is automatically formatted with slashes when you lose focus to the textbox. I adopted this technique in June and it has worked quite well for us so far.
03/03/1999 when 3/3/99 (or 3/03/99) is unambiguous too.
I definitely agree with Rahul, that it depends on the context. A calendar widget is super useful for going back or forward a few months, but not so great for picking your birthdate -- that'd be a clicking nightmare!
I personally hate those date pull-downs to pick your birthdate, also, as they tend to be a pain to hit your target selection, but I saw a nifty one recently in the sign-up flow at Kontain.com. As you can see below, they've laid out the options in a table instead of a list (and did the same for day and year) and I found that to be an awesome improvement. Yay!
07 ten times faster than you click the July field.
Feb 29 on non-leap-years or April 31st. It's also useful if the day of week is an important factor for the selection. Of course, you could just calculate the day of week for the user after they type in a date and also warn them if the date doesn't exist.
Commented
Dec 24, 2010 at 3:45
Remember that user-friendliness is a product of your audience and the domain of your app. For instance, if you're building a service like Kayak, you're going to be focusing on reasonably tech-savvy users who will be using date controls a lot during their experience with your app. On the other hand, Google and Amazon have broader audiences and fewer interactions, so they have different priorities.
With that in mind, here are some considerations:
Calendar control. These can be very useful when you want to communicate additional metadata about dates, times or time periods while selecting a date. For instance, on a travel site, a user may be selecting a date to book a hotel. You can use the calendar control to indicate which dates are fully booked. Since the calendar control most closely compares to its real world cousin, the calendar, you're doing users a favour by bringing interactions with dates and times into their mental model. However, there are use cases where calendar controls become awkward; since the control is modeled around displaying one month at a time, you're pushing control over skipping between months into (often) arrows or dropdowns again. That can be limiting if you're trying to give the user more freedom in picking a date.
Drop down menus. Often you'll see three in a row: [Day][Month][Year]. These work well when a user is just selecting a date they already know in advance, such as their birthdate. They don't work so well if you're asking the user to repeat a task involving dates, since most users will use the mouse and therefore have to click once on each dropdown to open it, once on each item to select it, and possibly scroll up and down a long list (for birth dates, it's not uncommon to have the Year menu start at 1920 and end at 2009). Make sure you take this into account if you choose drop down menus.
Plain text input fields. As others have answered, the nice thing about input fields is that you can accept virtually anything. In these cases, remember the principles of form design: don't enforce your database/backend formatting on the end user. Try to be as generous as you can in accepting as many formats as possible. Use client side validation to point out problems to the user before she submits the form (dates are very easy to validate in Javascript by giving the string the user filled in to the new Date() function and seeing if you get a date back).
Looking beyond controls, consider some common sense principles when dealing with dates:
Check whether the user didn't make a mistake. If you're designing a site for teens and someone says they were born in 1934, consider whether that should be an option and if it should, whether you should doublecheck with them to see if they actually are 76. Not for age validation purposes, but as a service to the user. Similarly, if you're designing a travel site, consider checking whether the user really intended to book a vacation to Hawaii in October 2011, not this October.
In most cases, specific time selections aren't necessary and probably don't map to the mental model of the user. When planning an event, the maximum granularity you're likely to need is in 5 minute intervals. Offer a control that allows users to select 12:00, 12:05, 12:10 etc rather than 60 options for every minute. The granularity you decide on can have a big effect on the usability of the particular control you choose to use (such as drop down menus).
Always look beyond standard controls and into the realm of information graphics as an option. Usually these will be complicated and expensive to implement, but they can be worth it if date/time selection is a core feature. For instance, hipmunk.com has a fantastic visual representation of flight schedules (read, not as input) that could be even better if it were interactive. In these cases, remember to consider your audience's expectations.
Programmers are lazy! Let the computer work a little and consider not even having a specific date field for initial date entry. Google Calendar, when creating a new event, simply allows you to say:
GC then figures it all out for you (including where), and, based on your user profile locale, will be intelligent about what 4/7: Dinner at Joe's place means. For subsequent editing, the GC calendar control is nice and easy to use. Consider the following and how easy this would be for users:
And... SHOCK HORROR what happens if the user doesn't know?? I've not seen this much but why is this not an acceptable date entry for some circumstances:
I know this is scary :) But Tog On Software Design, Bruce Tognazzini (original author of Apple Human Interface Guidelines) describes User Experience implementation is a bit like a magic trick: 'an illusion': looks easy, but underneath, all sorts of insanity is going on.
I'd get the software to put an automatic reminder 1d before saying 'hey, around about now you wanted to do stuff'
Also, use context as much as poss:
... if you have contacts or a social graph this should be easy to figure out; if not, ask.
When having date ranges, consider that month boundaries are a real hassle for calendar views that show only one month. iCal on the Mac is neat in this way because you can show any number of months so you can easily check what the exact dates of 'between 2 and 3 weeks from now' mean.
I normally just use a regular textbox and add the Jquery UI Datepicker to it.
When the user brings focus on the textbox by tab or clicking or whatnot the calendar control pops up temporarily beneath it - without disturbing text input:
The user can then either just type a date in any parseable format, or use the mouse with the calendar popup. Selecting a date with the mouse will simply type it in the textbox in the site's preferred format for the user and close the popup.
For time entry I found something similar done by someone I forgot who but with the (12 or 24) hours popping up in a tabular widget, selecting an hour then pops up a few choice minute options like 0, 15, 30 and 45. As before, just typing the time works just fine, ignoring the popup.
Also, a calendar control can be tuned to display more than one month at a time, I usually have it show 2-3 months next to each other - depending on the context of the date. Date entry in my case generally revolve around the current quarter though. A birth-date entry wouldn't work so well as someone already pointed out ^^
A common alternative to multiple drop-downs or widgets is standard formatting help text. Sometimes you'll see it inside the text field as the default value and sometimes to the right/below the field. Default text would say something like "MM/DD/YYYY" or "dd-mm-yyyy". Here's an example from Google's signup form:
This gives the user total control of what to input, and only uses one text field. One downside to this approach is the need for additional client-side validation to make sure they've followed the proper date convention.
MM/DD/YYYY, but the example is in M/D/YYYY format.
The first question is how many date entry fields you have in the application and how often they are used.
If you have to enter you birth day when you sign up and that's it, well, it probably shouldn't be a high priority for you.
But if you have a lot of dates there are some points to consider nobody else talked about yet:
You need to take care of the user's preferred date format (I'm not in the US, I want my dates to be in DD/MM/YYYY format, those US dates with the month at the beginning are difficult for me to read and type).
Also, consider the other controls around the date field, if it's a page that's built so the user interacts with it with the mouse you should have a date picker that can be user with the mouse only, on the other hand if you have text fields around the date the user is likely to be in "typing mode" and forcing interaction that requires the mouse (like multiple drop-downs) might be annoying.
And finally, your users are not my users, you should test it, give half the users a text field and half a graphical calendar control, measure how many users complete each form and how much time it takes each group on average to complete the form.
If it's important enough to obsess about it here it's important enough to test it.
My two cents: I'm blind and i think that the best thing is: 3 combo box! An alternative could be 2 combo box for months and days and a input text for the year but you should do a controll on this field... If i should think as programmer I preffered a single input text but if you think that in your site could be a "noob user" I think that the best thing is the first option :)
As for speed and ease of use nothing beats the simple numeric entry, e.g. 2010-09-21. Use a single textbox but (apart from the common "/" and "-") also accept tabs to move from one field to the next one. Hitting "[tab]" should insert a separator. As separator I prefer the dash, because it separates the fields more clearly.
Don't force people to type leading zeros.
I wouldn't uses text entry like abbreviated months like Bevan suggested because they take longer to enter. Also, how do you abbreviate? Three letters? Four? Like I said in my reply to Bevan it's especially a bad idea if you're working with an international audience; "September" may not be "Sept" in your user's language.
Talking about international audiences: not everybody uses the MM-DD-YYYY order (as a matter of fact, outside of the US almost nobody does). You may indicate the required order below the textbox. One way to avoid the ambiguity of dates like 05-06-2010 is to use the ISO 8601 format YYYY-MM-DD.
Give a text input where the user can type in the date along with a hint of what format they can use, but then accept any unambiguous format regardless of separators or number of digits. When the user types something other than the standard format, immediately update it to the standard format so the user sees exactly how you're interpreting the date in an unambiguous way. Adding a calendar icon to give users that want an option of selecting from a calendar is good too--users that want to type a date don't have to use it.
I was just doing some research on this. Calendar Apps are a good place to start. My favorite layout is the date with time to the right. I don't like the google calendar Date - Time - Time - Date format, but the datepicker and drop down are pretty clearly executed.
(I couldn't post the image of it, but I'd encourage you to check it out)
