Alternate titles: Date picker, Date selector.
The user wants to find or submit information based on a date or date range
The calendar picker is seen activated in a variety of ways:
On activation, a box with a month-calendar is laid over the current page, prompting the user to select a date in the box. It is most common to only show one month, but some interfaces show up to 3 month calendars next to each other to ease the click-burden of the user and provide a better overview.
The month-box calendar comes with several different shortcuts:
For some interfaces, it makes sense to not allow the selection of certain dates. An example often used is to only make it possible to select banking days, days in the future, or days within the few forthcoming months.
When designing for efficiency in web application, an area that often gets little attention is the contexts of input. On most desktop computers, there are ways of inputting data: via keyboard or mouse.
The calendar picker is often a mouse-only pattern, where the user selects a date by clicking on it. While the solution provides a great experience, it can be considered cumbersome for expert users. Using a calendar picker is the easy way of inputting a date.
Consider also having a speedy way of inputting a date – maybe one where the user does not have to change input devices – to go from the keyboard to the mouse – but just stay on the keyboard and manually entering the date as text.
For accommodating text inputs, consider using the Forgiving Format pattern to lessen input errors.
Use the Good defaults pattern to better data and spelling accuracy on input errors by pre-selecting appropriate dates.
What defaults to pre-select depend on the context, but will most often be the current date or time. If you however were designing a public transport route planner, you might default the start time to a half hour from now, as most travelers won’t be starting their journey right away when searching for a fare.
If the user is selecting a date range, it is good practice to never let end-date be before the start date. That means listening to the start-date for changes and changing the end-date if the start date is set to anything bigger.
Display complete weeks, even when a month does not begin at the end of the week. Grey out visible dates from previous and next months, but be sure they are still selectable.
Make sure that link targets are big and thus easy to click on.
The calendar picker is a familiar graphical interface that is commonly understood among users. It helps the user easily choose a date or date range for use in submitting information or filtering data.
In some countries it is typical to display a calendar with Sunday as the first day of the week, where in many European and Asian countries, Monday is typically depicted as the first day of the week.
Some countries (E.g. Germany and Scandinavian countries) use week numbers for general planning purposes. In these countries, using the week number is almost as common as using the month name for describing a date range. Consider displaying the week number for each week row.
“Do not use in isolation, when the user is more familiar and efficient with another way of inputting a date. Some users prefer inputting a date via a text field.”
This is the problem I am facing. How do you decide on a universal date format in the text field? People in the UK or Asia might not be comfortable with the MM/DD/YYYY format used in the US and vice-versa.
ISO recommends YYYY-MM-DD but how many sites/applications use this?
IMHO you should probable go for a hybrid solution. Use the Forgiving Format and let them enter the date as they want (it’s easy to distinguish ISO YYYY-MM-DD from the other two) and for the US vs UK dates (DD/MM or MM/DD) do an ‘auto-complete’ that shows a calendar-picker on the dates you are assuming (just choose one of the two as basis).
This way a user can start entering a date as they want and then it either A) matches what they expected and they just move along, or B) it mismatches the pop-up and they correct the text to conform with your assumed format, or C) it mismatches the pop-up and they click on the correct date.
I really think there is no “one way solution” for your problem here…
The key point is that you have to give the user choices:
â€œDo not use in isolation … Some users prefer inputting a date via a text field.â€
Regarding different notation systems month/day/year versus day/month/year you again have several options. The simplest option would be to show the “proper” format in or below the text entry box.