What the Date Picker Lacks

Figure 1. A common date picker user interface.

The common date picker is lacking in speed and simplicity when compared to typing a date into a text field. Typing a date into a text field is a relatively quick and easy process, usually ten keystrokes is enough to enter a date formatted as mm/dd/yyyy. What makes this task even quicker is that you only need eleven keys to enter any date (0-9 and /); using the number pad makes this even easier. On the other hand, selecting a date using a date picker can be a slower and more complex process. If you are selecting a date six months from the month initially displayed in the date picker, then you have to change the month six times before you are shown the appropriate month. The same or a worse problem arises when navigating through years. If the date picker allows navigation by year and month it is only slightly more problematic than only changing the month. On the other hand if the date picker only allows navigation by month, changing the year takes eleven more clicks. It also does not help that most date pickers use a cryptic system of symbols to represent moving forward and back one month or one year. These symbols are the single and double angle quotation marks – or something similar – pointed either right or left. The single angle quotes navigate through the months while the double angle quotes navigate through the years. This is not the most intuitive way to represent month and year navigation. All of these problems contribute to the relative slowness and complexity of common date pickers.

Speed and simplicity are important when filling out forms because users do not usually visit websites for this purpose. Users visit websites to obtain some kind of valuable information. Forms are just there for users to specify the type of information they need. In other words, forms are means to and end and should not hinder or irritate a user on their path to that end. The simple reason for this is that making users happy keeps them coming back to the site. So it should be our goal to make entering dates into a form as easy (quick and simple) as possible.

A Proposed Solution

Figure 2. A date picker with separate month and year displays.

The goal of the proposed solution is to simplify the date picker and make it quicker to use. We start by separating the month and year in order to reduce the complexity introduced by the symbols shown in Figure 1. It becomes easier to connect the meaning of the symbols because they are now grouped with their corresponding item, month and year. We can also use the same symbols to represent navigating forward and backward by month or year. This reduces the number of symbols for which users have to interpret the meaning.

Figure 3. A date picker with expanded month and year interfaces.

The next step is to expand the months so that any month is selectable with one click, as opposed to 1-11 clicks. This also allows us to remove the navigation symbols as they are no longer necessary. Reducing clicks increases speed and removing the navigation symbols reduces complexity because the user no longer needs to decipher the meaning of the symbols or their connection to any item. It is possible to expand the months because the number of months is finite and relatively small. Twelve months can easily fit into two rows when they are abbreviated.

Applying this same solution to the year navigation is more difficult because the range of input for years is application-specific. Displaying 60 years in the manner the months have been displayed in Figure 3 is impractical. It would make the date picker too big and would required more effort by the user to find the appropriate year. In this situation a drop down list would be a better method for selecting a year – better than displaying all sixty years and better then navigating one year at a time. As you can see, I have used an example where the range of input is restricted to five years. In this case it is practical to display all the years because they fit in one row. This has two obvious advantages over a dropdown list. First, it requires fewer clicks and mouse movements to select the appropriate year. Second, the valid range of years is immediately visible; whereas in a dropdown you must expand the list before you are shown that range. While this technique works for small ranges of years, at a certain number a decision has to be made between displaying all of the selectable years and using a dropdown list – or a similar UI element. That decision is application-specific and ultimately left up to the UI designer. I cannot suggest where that line should be drawn, because I don’t know myself. That is a question that may have to be – or has already been – answered by research.

The Date Picker Working Sample

You can take a look at a working example of my date picker. The example code authored by me is public domain, so use it for anything without any restrictions. You can easily identify the code I have authored; as it has my name, email, and URL along with a statement declaring it public domain. If you use the code in your own work, I would appreciate my name and URL be included.

Get the DatePicker.js File. The DatePicker class depends on jQuery.

Get the datepicker.css file and datepicker.ie.css file.

Replicating the Shadow

1. Make a copy of the overlay’s layers and merge and rasterize the copies if needed
2. Make the copy all black (I use a gradient map and set both ends to black)
3. Perform a Free Transform and set the Height/Vertical Scale to 50% and the Horizontal Skew to -45°
4. Apply the Gaussian Blur filter (I set it to .5 pixels for small images and 2 to 3 pixels for large ones)
5. Set the Opacity to 45%
6. Save the shadow layer only as a PNG

Drawing a Variable Size Shadow on the Map

After figuring out how to replicate the shadow, I moved on to drawing it on the map. The first step to drawing the shadow is getting its size and location. From replicating the shadow we know that the height is 50% (plus padding for the Gaussian blur). The width of the shadow is the width of the tooltip, plus half the height of the tooltip (and again, the padding). Half the height of the tooltip is added to the width to take into account the offset of the shadow’s top, right corner caused by the skew. Since the skew is 45 degrees, the offset is a one to one ratio with the height of the shadow. The position of the tooltip’s shadow is relative to the marker’s shadow. So I apply the same principles to the marker’s dimensions in order to calculate the position of the tooltip’s shadow.

Because the size of the tooltip is not fixed, the shadow needs to be able to grow vertically and horizontally. I accomplish this by dividing the shadow into four quadrants. Each quadrant contains the same shadow image, positioned to display its respective corner. The image’s positions in the first and third quadrants are straight forward. The image is positioned so the top and right edges of the image line up with the top and right edges of the first quadrant. The bottom and left edges of the image line up with the bottom and left edges of the third quadrant. The positioning of the image in the second and fourth quadrants requires some simple calculations. The image in the second quadrant is placed so the top edge of the image lines up with the top edge of the quadrant. The left edge of the image is offset from the quadrant’s left edge. The image in the fourth quadrant is symmetrically opposite from the second, bottom edge of image to bottom edge of quadrant and right edge of image offset from the right edge of quadrant. See the source code, the Tooltip.prototype.redraw method, for the calculations of the offset.

The code below is a sample of the xhtml generated by the Tooltip object to create the shadow. The parent div is the container for the entire shadow, it is outlined in black in the image above. The child divs represent the quadrants of the shadow. Each quadrant contains a reference to the same shadow image and the image is positioned relatively to the quadrant.

HTML Support

The tooltip can now take an HTML Element for its content. To do so, just create an element and pass it to the tooltip’s constructor. This technique is illustrated below.

Why has this technique not been applied broadly to visited links as well? It makes so much more sense than changing the color. You don’t have to think about which color corresponds to a visited link as opposed to a non-visited link. The color swapping doesn’t really help across different websites because there is no standard convention for which colors to use. The exception may be blue for non-visited purple for visited, but these are antiquated and clash with most websites’ color schemes. Using a check mark doesn’t require that users remember a link had a different color when or if they re-encounter it after they have visited the it the first time. Users do not have to compare one link’s color to another and try to remember which of those links has been visited and which has not. The check mark conveys the same meaning without requiring the user to think as much; it is a much better solution.

Evalotta pointed out that Paul Boag also uses this technique. If you know of any others, let me know.

What?

Today I present the Tooltip object for the Google Maps API. It is used to add quickly-appearing, easy-to-style (via CSS) tooltips to Google Maps’ markers. This is in contrast to the built-in tooltips of versions 2.5 and higher, which appear after a short delay and cannot be styled. You can view an example the new example of the tooltips in action which also includes a sidebar.

View the Tooltip source code. The code is free to use for any reason without any restrictions. Just credit me if you redistribute it.

Why?

I developed the tooltips for two reasons. First, I find it difficult to figure out which marker a sidebar entry belongs to. It is time consuming to look at the letter for the entry and find the matching letter on the map, especially when markers overlap and hide each other. It is easier if the tooltip appears above the marker when I hover over the sidebar entry. Secondly, sometimes I just want to quickly figure out what a certain marker on the map is without having to look for its corresponding letter in the sidebar. And having to click on the marker to pull up the location’s name is annoying, especially when it moves the center of the map. It just seems natural to me that when you hover on a marker, the name of the location should appear. Besides, it was a good exercise in extending the Google Maps API.

How?

Adding tooltips to a Google Map, using the Tooltip object is easy. I’ll explain the steps I use when implementing the tooltips. The constructor for the tooltip takes three parameters: the marker, the text, and the padding between the tooltip and the marker.

After I’ve created the tooltip, I set it to the marker’s tooltip property. Then, I add the marker and tooltip to the map via the addOverlay method of the GMap2 object. The last step is to add the mouseover and mouseout listeners to the marker to show and hide the tooltip.

Things to consider

• You may want to suppress the tooltip when the GInfoWindow is open. Since the markers do not have a property that indicates whether their info window is open, you would need to add listeners to their infowindowopen and infowindowclose events. For an example of how to do this check out the source code of the Tooltips with drop shadows example.
• Another possible extension would be to add a timeout to the hide method of the Tooltip object to delay how quickly the tooltip disappears.
• One limitation of the tooltip is that it currently only supports text. If you wanted more advanced styling, you could add support to the Tooltip object for inserting DOM Elements. The new version of the tooltip now supports DOM Elements for the content.
• The Tooltip object does not cast a drop shadow. If you want to keep it consistent with the Google Maps look-and-feel, this would be something to consider adding. The new version of the tooltip now casts a drop shadow.