Inputing dates is going through changes on the internet, and in web/user interface design as well. Currently, I'm implementing <input type="date">, as this provides excellent usability on mobile devices.

iPhone datepicker

On desktop browsers, <input type="date"> is mostly implemented as a clickable calender, which pops up when clicking an arrow in an input field.

Chrome datepicker

However, this has certain disadvantages:

  1. The <input type="date"> field isn't widely supported in browsers, particularly older versions of Internet explorer. To correct this, i'm using a traditional javascript datepicker in those cases. This causes extra upkeep and maintaince costs;
  2. Even in the browsers that support <input type="date">, it isn't used among a lot of websites yet, so users are not yet familiar with the particular design their browser uses (mobile browsers may be the exeption);
  3. Date formats in <input type="date"> are lacking at best;
  4. Inputing dates by clicking calendars is painfully slow;

Any viable alternative would, in my opinion, be:

  1. Providing options for boundaries and validation;
  2. Independant of date formatting;
  3. Looking good;
  4. Very understandable;

What alternatives to calendars exist for inputing dates on website?

(images originate from Joe Larson's blog)

  • Great question! Nov 30, 2012 at 12:33
  • Shortcuts like "[today]" and "[tomorrow]" buttons can accelerate the entry of common dates, keeping the slow calendar input for less common dates.
    – MSalters
    Nov 30, 2012 at 15:13

5 Answers 5


It's better to ask yourself what ways people think of dates, and model a solution on that. Personally, I think a text input field with a date picker is a great solution as I have yet to find anyone that doesn't understand that or who has trouble using that.

Granted there is variation in the quality of date pickers, but that is another question.

When in doubt, copy people that have done a lot of UX testing on date pickers. A good example is Hipmunk.

enter image description here


What kind of date input/widget you choose greatly depends on the information the user needs to input. In most cases, the user may not know the exact date, so leaving out the calendar forces them to take an additional step of finding their own calendar to look up the date, becoming slower and less usable. For example, if they are setting up an appointment for next Saturday, they probably don't know the date of next Saturday, so without providing a calendar, you are giving them the added frustration and trouble of looking up the date separately. For this case, the calendar is probably your best option because there is no other existing format that will display dates in such a universally recognizable way.

An example of a case where the user would not need to look up the date is if you're asking them to input their birthday. This is something that the average user would know off the top of their head and would not need to look up to determine the date. This is where you can get a bit more creative since you're not confined to the typical calendar format - drop downs, scrolling, text fields, etc. However, the fastest way for a user to input this date would be a simple text field. The only advantage that I can see of using month, day, year drop downs or other formats would be to avoid confusion over the ordering of the month and day (MM/DD/YYYY vs. DD/MM/YYYY).

In most situations, the best solution would be to have a text input with a calendar widget attached that opens when the input is active. This allows the user to quickly type the date if they know it or use the calendar to select a date if they need it.


Even if clicking calendars could be slow, it's a universal solution that doesn't depend on the date format used at the local geographical region. Moreover, users are familiar with wall calendars and have a corresponding Mental model for them.

You may use other solutions (like human-friendly text input allowing users to simply type in date like "March, 5th", etc), but all of them will have some limitations: it may be difficult to support every geographical region and language you'll need, or may require extra validation, or you will need to introduce something new to your users (and they will have to spend their time to undertand how things behave).


If clicking a Calender is to slow for you, the next best solution would be a regular textfield. Provide the usual placeholder text (MM/DD/YYYY) so the user knows how to enter the date and you don't have to handle all the different types of dates.

I think this is the best way on desktop browsers after a datepicker.


Browsers are pretty awesome nowadays. Working with typed inputs is a good idea, however they don't provide a consistent UX, what you're maybe looking for. HTML5 support on typed inputs is being adapted by the browsers, but some of the controls are cumbersome. They don't provide validation, they don't provide clues for the user. Also choosing the right solution to you date picking problem depends on the platform where it's consumed. Is it a mobile/touch website, or is it a desktop website?

  1. For a mobile website which is being used on touch devices, your best bet is a scroller component or a calendar view. The interaction model is spinning and swiping and tapping. The used UI elements should have large-enough areas to avoid "fat-fingering". The difference between a scroller-type date picker and a calendar view also depends on the context. They both let you pick a date, but does it help to see where the day in the month is?

  2. For a desktop website a calendar, with the basic functionality like changing months and selecting dates with clicks. Swiping and spinning doesn't apply here.

For how to present that, tied to an input or just display it on the screen, it doesn't really matter in terms of what the users are interacting with. That depends on how much space you have and what the constraints are.

You should check out Mobiscroll Calendar and Date Picker for your mobile websites.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.