Calendars and Date Range Selection

One thing that bothers me about “design patterns” is that they don’t always seem to be the best method of solving a design problem. In many cases, patterns are patterns simply because they are popular. This of course is a phenomenon not limited to design (music, for example, is another case in point). However, it becomes particularly frustrating for designers when a sub-optimal pattern then gets in the way of better designs because the pattern becomes something that people expect. Significant modification of the pattern is seen as negative, even if those modifications are demonstrably better. But you can’t do something better by doing the same thing as everyone else.

One example of a design pattern being a poor solution to a problem is the use of pop-up calendars to allow date range selections on form fields. Here’s an example of what I mean. I’ve chosen an example of a single calendar for selecting ranges because I think it illustrates better the points I’m about to make. A more common example is the “from/to” calendar: separate calendars for the “from” date and the “to” date, usually as separate fields on the form.

The best thing about a calendar in this context is that everyone understands what it is. It has a very recognisable “shape.” The traditional printed calendar grid is arranged so that you can easily see what days of the week specific dates fall on. “What day is the 23rd?” “When is the last Sunday of the month?” “Is Easter on a Monday?” and so on. This means the arrangement of the numbers on the grid is determined by the sequence of the days of the week in the first (top) row.

It is here we have the first problem for date range selection. Different months have differing numbers of days, and the first of the month usually falls on a different day of the week. The calendar starts and ends at a different point on the grid from month to month. Most calendars show a “mason’s mitre” pattern at the beginning and the end of the month to cater for this, perhaps supplemented by a colour. Sometimes they completely leave out the days not in that month. So, the calendar control is an irregular, two dimensional shape that needs interrogation before it can be used.

The second problem is one of size. Because it has to be a grid, two things happen: firstly, it takes up a lot of vertical space. On the web, vertical space is usually more at a premium than it is on a wall – the native habitat of a calendar. Secondly, any extra data has to fit into the space afforded by the intersections of the grid. Compressing a calendar into the space typically available for a range control on a web page means that the grid can usually only support numbers supplemented by colours and perhaps one other indicator before it becomes saturated. Past a certain size, it also becomes hard to acquire the right dates on the grid with the mouse (and seldom are logical tab orders built in). Calendars aren’t good at being small.

The final problem is that most calendars used in this way deal with months only, regardless of what the date range might typically be in the context of use. If you want to set a range in years and months, a year control is added. Depending on the design, this means you have to skip to the same month in the next year, then navigate back or forward from there. So, calendars are often awkward and may not fit the time scales needed.

For date range controls, I think a better solution would be a time line in most cases. Time lines have the following advantages over calendars in the context of date range selection:

1. They are a regular shape. Their linearity reflects the passage of time.
2. They can display a variety of data in a small vertical space.
3. Being a regular, one dimensional shape, they don’t need to rely on selection with a mouse pointer in a two-dimensional space. They are more suited to keyboard controls.

The main disadvantages times lines have compared to calendars are their occupation of horizontal space. They are also not generally used for range selection outside specialist applications such as video editing.

I’ve been thinking of how a time line might replace a calendar in the context of booking a room at a hotel. Most people only stay in hotels for a few nights at a time, so large ranges aren’t needed here. If they were though, I think the time line format could cater for that better than a calendar simply by virtue of a clearer “fast forward” control.

Here’s a wireframe for a time line to replace a calendar control, similar to the example given above in this context (click to enlarge):

This would not only allow you to choose a date range by selecting the start and end dates (here indicated by the white days), but also allow you to see when rooms are available, and how much they are on each day. Further encoding could also be possible with the use of textures or other devices (although this would probably need a key, which isn’t very desirable).