CHAPTER 9
,DATE FILTERS: Successful Calendar Design Patterns
Provide Good Defaults PAGE 142
Show Only Valid Date Values PAGE 144
Minimize Clicks PAGE 146
Retain Customer-Entered Values PAGE 148
Consider if You Need Your Customers to Enter Dates PAGE 149
In contrast with the decimal Hindu-Arabic numeral system that was invented in India around 1,500 years ago, the Gregorian calendar has only been in use for approximately 428 years. As a consequence, humanity as a whole has had a bit less practice with calendars and dates than with numbers. Thus, date filters often cause even more usability issues than the numeric filters mentioned in the previous chapter, especially when they neglect basic design best practices. Dates are also among the most complex and time-consuming controls to manipulate: When asked to enter date values during usability tests, people often literally groan in pain. Yet many user interfaces stubbornly fail to safeguard customers from inadvertent errors and simply refuse to retain the calendar information customers so painstakingly provided. Sloppy or indifferent design of date filters can lead to unhappy customers. This chapter focuses specifically on date filters to show you how to design date filters that are as intuitive and pain free as possible.
PROVIDE GOOD DEFAULTS
For user interfaces, the initial impression is usually the most telling. Look at this government search interface from California's Department of Corporations Web site, pictured in Figure 9.1. Not only are there no useful date defaults, but also there is absolutely no indication of what date range input might be acceptable. Can the customer perhaps search as far back as 1913? Unfortunately, from the looks of this page, we have not gone far in making dates easier to handle since the invention of the Gregorian calendar in 1582.
FIGURE 9.1 No date defaults in California Department of Corporations' Web search
Failure to provide good defaults extends far beyond government Web sites. Figure 9.2 shows a Web site of an upscale Iron Horse hotel in Milwaukee.
FIGURE 9.2 Default dates at the IronHorseHotel.com produce zero results
As you can see, default date filter settings produced zero search results—not exactly what you would expect from a hotel claiming to be “catering to your every desire.” The resulting no search results page commits several of the sins covered previously in Chapter 1. The biggest frustration is that the zero search results page just reuses the same date values originally used to get the zero results, so now the customer is no wiser than before about what might be the soonest date available for a romantic getaway. At this point, the best outcome is that the frustrated customer might pick up the phone and call the company, whereas the worst outcome is that he will simply give up and book their travel on a competing hotel site.
SHOW ONLY VALID DATE VALUES
Providing reasonable defaults is just the beginning of the search process. Successful calendar designs must also prevent customers from picking invalid dates by graying-out or disabling date values that are disallowed or return zero results. Unfortunately, even otherwise top-notch sites often choose not to do this. For example, Figure 9.3 shows the KAYAK site that enables customers to pick dates too far into the future, causing an error.
FIGURE 9.3 KAYAK.com enables customers to select dates too far in the future
But the difficulties with selecting valid date values do not stop there. Take for example, TripAdvisor.com, shown in Figure 9.4.
When the customer picks a departure date (6/19/2010) and then launches the return date picker, the Web site does not indicate the departure date the customer just selected, nor does the system in any way indicate which return dates occur before the departure date and are therefore unavailable. If the person happens to be unlucky enough to pick the “wrong” departure date that occurs after the return date (6/13/2010), TripAdvisor “helpfully” moves the return date to 1 day following the departure—an action that is both arbitrary and destructive. Worse, the system never notifies the customer of this action.
FIGURE 9.4 TripAdvisor arbitrarily moves the return date to 1 day following departure
Note—Most people assume they entered the information correctly unless the system clearly tells them otherwise, so when they discover that the system arbitrarily changed the information they entered, they lose trust in the site.
A much better approach is to indicate the departure date on the return calendar and clearly indicate the dates that occur before the departure date, so the customer does not pick them accidentally. This prevents potential errors and confusion even before the customer has a chance to enter anything. If the customer still chooses to select a return date that occurs before the departure date, the system can then move the departure date or leave it blank, but in either case it should indicate the action it is taking on behalf of the customer. As shown in Figure 9.5, a similar approach is successfully implemented on Orbitz.com, which disables bad choices and makes it clear which dates to select.
FIGURE 9.5 Orbitz.com makes it obvious which dates to select
Less thinking equals fewer errors and surprises, and fewer errors mean more happy customers. Any design that makes it obvious what to do with the calendar is a big win for your user experience.
MINIMIZE CLICKS
TripAdvisor also demonstrates why, when it comes to dates, it is important to usability test and actually take the time to count the number of clicks needed to enter a date a few months in the future. As can be seen in Figure 9.4, the TripAdvisor calendar shows two months worth of dates at the same time. Unfortunately, fancy JavaScript code enables the calendar to scroll only a single month at a time. This design effectively doubles the time it would take to book a flight because in addition to clicking once for every month, the customer now has to wait for the fancy calendar scrolling to come to a complete stop before they can navigate to the next month. I hope you are beginning to see why people groan during date filter usability testing.
UX design expert Alan Cooper proposed a much better calendar design that scrolls continuously in his exceptional book About Face. This scrolling calendar design pattern was successfully implemented by the KAYAK iPhone app, shown on the right side of Figure 9.6.
FIGURE 9.6 KAYAK date picker versus scrolling calendar in the iPhone app
Contrast the elegant scrolling calendar design of the KAYAK iPhone app with the Web form calendar picker shown on the left. Note that the KAYAK Web application actually duplicates (and grays out, which adds to the confusion) the flanking and trailing dates for each month. In my opinion, it is features such as this that make KAYAK's mobile interface much more intuitive than its Web application.
Note—Luke Wroblewski explores the topic of mobile search Web forms in more detail in his perspective at the end of this chapter.
Regardless of how fancy your calendar picker is, make sure your form is accessible and allows people to simply type in the dates they want by tabbing around the form fields. I once consulted for a client that proudly showed me his enterprise search date entry interface that disabled the manual entry and instead popped up the date picker “in order to avoid errors.”
Note—It is critical to always allow for keyboard date entry, particularly in the enterprise environment, because people are often much faster and more accurate at typing in dates or cutting and pasting into the form field than they are reaching for a mouse.
RETAIN CUSTOMER-ENTERED VALUES
Date values are hard to enter, therefore it makes a lot of sense to retain any customer-entered date information for as long as possible. Unfortunately, many sites do not take the trouble to do so. Figure 9.7 shows the search form that results from being transferred from KAYAK to Southwest Airlines' Web site. Dates are not included as part of the search query transfer, defaulting instead to today's departure date and a return date one day in the future.
FIGURE 9.7 KAYAK.com drops date selections when transferring the search to Southwest Airlines
Recently, Southwest Airlines implemented a “sticky” date design that retains the dates even when the customer starts the search process over. That is a great improvement. However, what if the customer is considering multiple travel dates or trying to compare several different travel dates to find the best price? Because dates are so tedious to enter, at the very least, retaining date information entered in the same session usually makes the interface much more consumer-friendly and enables people to be a lot more efficient.
Note—Retaining date information is practically a necessity in some consumer and enterprise applications, like Web analytics, where people often use several date periods over and over in various queries throughout the site.
In cases in which the customer interface needs to display several previously entered dates or date ranges, a drop-down selector showing several previous entries is an effective option. Two possible designs, with the select preceding and following the date entry field, are shown in Figure 9.8.
FIGURE 9.8 Date drop-down selectors enable customers to select from dates used in the past
The drop-down selector is an excellent design pattern that borrows freely from the design of the Internet browsers' URL entry fields that have similar functionality. In my usability testing, a wide range of people understood and used date drop-down selectors effectively. Drop-down date selectors are versatile, used to recall individual dates or date ranges, and help minimize clicks for repetitive date entry tasks. They are the perfect kind of partially hidden “Easter Egg” functionality, that creates sheer delight when discovered unexpectedly.
Note—Only provide the active drop-down selector when past dates are available to populate it. When the drop-down list is empty, the selector arrow should be removed or shown in a grayed-out disabled state.
CONSIDER IF YOU NEED YOUR CUSTOMERS TO ENTER DATES
A lot of times, particularly in an enterprise system, the date range is the default “knee jerk” control the designers reach for when creating simple object management screens and reports. Many times this interface control is a complete overkill. One of the alternative design patterns I call Presets with Custom Date Range is shown in Figure 9.9.
FIGURE 9.9 Presets with Custom Date Range offers speed and flexibility
Presets with Custom Date Range is a simple yet effective design pattern. This pattern presents several preset date ranges (for example, Today, Last 7 Days, and so on) that are frequently used by customers. If a custom date range is desired, the customer can click the More link that opens a section with standard date boxes and calendar pickers allowing the customer to enter a custom date range instead. In many cases using this design pattern instead of a simple date range picker can save time and cognitive load on the person using the interface, while still allowing complete input flexibility with only a single extra click.
In many cases, date ranges are orthogonal to the task at hand, yet many designers and engineers reach for the date picker as a kind of knee-jerk reaction. Instead, challenge yourself on your next project. Consider if your customers will not be better served by an interface that, instead of forcing people to search through several different date ranges, helpfully suggests the best time to travel to Thailand? Or the user interface that helps people find the dates that offer the best price on a dream Alaskan cruise? When booking a summer vacation, do most people care if they travel in July versus August? Don't make your customers choose a date range. Instead invent pages that invite browsing and searching to allow people to leave the dreaded date boxes blank. Your customers (and your clients) will both thank you.
The following excerpt is taken from Lukew.com (www.lukew.com/ff/entry.asp?1014), by Luke Wroblewski
Trust me, no one likes filling in forms—especially on mobile devices where one-handed, on-the-go data input and slow connections are common place. As a result, designing forms that make mobile input faster, easier, and less error-prone is crucial. Here's a few ways it can be done.
To illustrate, let's look at two mobile forms for booking a hotel: one from the Expedia mobile Web site, the other from the KAYAK iPhone application.
Expedia's mobile Web site has made several modifications to the desktop version of [its] hotel booking form: The layout has been optimized for slender mobile screens; the “search near” set of options has been listed out; and the room count input uses a set of “+” and “−” buttons instead of a drop-down menu for input. Yet, there's still room for improvement.
- The form uses a free-form text input field that requires users to provide clarifying information on another screen if a mistake is made. And in many mobile contexts (fat fingers, one-handed typing, on the go)—mistakes do happen.
- The date selection field makes use of a calendar pop-up that requires people to tap a small “>>” target to advance to the previous or next month.
- The set of inputs for guest count uses (up to) three drop-down select menus for input, which require manipulating a list of options in a pop-up list.
KAYAK's mobile iPhone application also allows people to book hotels, but it features a few additional mobile optimizations.
- Current location is available as a single-click input in addition to a free-form text input. This allows people to search for hotels where they are now without typing.
- The free-form text entry field provides inline suggestions as you type. This not only reduces the amount of typing required (it only took me three characters to see Monterrey, Mexico), but it reduces errors as well. On the KAYAK form, there's little need for the clarification screen Expedia requires.
- The date selection calendar allows people to use a simple scroll gesture to move between months instead of tapping a small target to change months. Users can just flick the calendar itself up or down through direct manipulation instead of having to use the “>>” control Expedia requires.
- The KAYAK form doesn't use any drop-down menus, opting instead for “+” and “–” buttons that are easily tapped on a touch screen. (I'm not sure why Expedia uses these for room count but not guest count as both inputs only need to support a small number of possible values.)
In aggregate, these small enhancements go a long way to making forms on mobile devices faster and easier for people to complete. For more on form design, check out Luke's book about Web form usability, visual design, and interaction design considerations: Web Form Design: Filling in the Blanks.
REFERENCES
Cooper, Alan, Robert Reimann, and David Cronin. About Face: The Essentials of Interaction Design. Indianapolis: John Wiley & Sons, 1995.
Nudelman, Greg. “Starting from Zero: Winning Strategies for No Search Results Pages.” UXmatters, February 9, 2009. Retrieved May 17, 2010.
Wroblewski, Luke. “Better Mobile Form Design.” LukeW Ideation + Design, March 9, 2010. Retrieved May 17, 2010.