Provide Good Defaults
When it comes to user interfaces, people’s initial impression is usually the most telling. Take a look at this search interface from the California Department of Corporations Web site, pictured in Figure 1. Not only are there no useful date defaults, there is absolutely no indication of what range of dates would be acceptable. Could a user perhaps search as far back as 1913? It looks like we haven’t come far in making dates easier to handle since the invention of the Gregorian calendar in 1582.
Let’s take a look at how some popular ecommerce sites handle default calendar settings. Figure 2 shows the Web site for the upscale Iron Horse hotel in Milwaukee.
As you can see, the default settings for this date filter produced zero search results—not exactly what I’d expect from a hotel that caters to my every desire. Plus, the resulting no search results page commits several of the sins I outlined in an earlier column, “Starting from Zero: Winning Strategies for No Search Results Pages.” The biggest frustration is that the zero search results page reuses the same date values that just failed to get any results, so the customer is no wiser than before about what might be the soonest date available for a romantic get-away. At this point, the best outcome is that the frustrated customer might pick up a phone and call—costing the company at least $25—while the worst outcome is that he or she will simply give up and go to a more usable site. Poor defaults for search parameters lose customers even faster than overbearing ads, and nothing will bring them back.
Show Only Valid Date Values
Providing good defaults is just the beginning of a successful search process. Effective calendar designs must also prevent customers from selecting invalid dates—that is, dates that either fall outside the range of supported dates or would return zero results—by making them unavailable and appear dimmed. Unfortunately, even otherwise top-notch sites often do not do this. For example, take a look at Figure 3, which shows this error on the Kayak site, which allows customers to select dates that are too far in the future, causing an error.
But the difficulties with selecting valid dates do not stop here. Take, for example, TripAdvisor.com, which is shown in Figure 4. When a customer selects a departure date (6/15/2010), then tries to select a return date, TripAdvisor does not in any way indicate the selected departure date or show what return dates would make sense. If someone inadvertently selects the wrong departure date, then selects a return date that occurs before the departure date (6/10/2010), TripAdvisor not so helpfully changes the return date to the next day after the departure date—a change that is both arbitrary and destructive. Worse, the system never brings this arbitrary change to the customer’s attention.
A much better approach would be to indicate the departure date within the calendar a customer uses to select the return date, clearly indicating dates that occur before the departure date and making them unavailable, so the customer cannot select them accidentally. However, on a site that does not prevent a customer from selecting a return date that is before the selected departure date, the system should at least indicate the problem rather than trying to divine the customer’s intent and taking some arbitrary action on behalf of the customer. As shown in Figure 5, a more successful design approach on Orbitz.com disables invalid options and makes it very clear which dates a user can select.
Requiring less thinking of customers results in fewer errors and unpleasant surprises, which means you’ll have happier customers. Any design that makes it more obvious what to do with a calendar is a big win for your user experience.
