Best practice for selecting month/year

Question

I have a form where users can choose a month and year to display a series of reports. (there is no need to choose the day - all the reports for that month will be displayed)

What is the best practice for this?

I can think of 3 options:

1. Two drop downs (one for the month, one for the year) and a "GO" button.

   • Pro: Makes it easier to change the year only ("let's see what was going on in the same month last year")
   • Con: Requires another click on "GO" to refresh the page

2. One drop down only, where months are listed as "JAN 2012", "FEB 2012" etc.

   • Pro: Can trigger an automated page refresh when the date is changed
   • Con: It is potentially difficult to scroll down or up many months

3. Date picker with just month/year

   • Pro: Very intuitive
   • Con: Requires JavaScript enabled

What do you think?

Answer 1

I think is important to point out that HTML 5 has a new input type=month which seems to be exactly what you want.

And altought most browsers doesn't support it yet that doesn't mean we should overlook that. Because they'll probably implement that in the near future, and then most users will be presented with their most familiar and fast UI for each device (think of smartphones presenting its number keyboard on the year textbox for instance).

So I would use a polyfill to workaround non-supporting browsers.

The best I could find was Webshims lib: http://afarkas.github.io/webshim/demos/#Forms-forms-ext

On most browser you will see this polyfill in action:

On Google Chrome (for instance) you will see this:

At first glance you can think they could look better, but if you try them out you'll see that both are way better than most solutions out there. With excellent support for keyboard and mouse, no dropdown for years (a spinner is usually better unless you have very few years to choose from), and lots of functionality to make your pick easier.

And what about customization? Or keeping the same look and feel on every browser (and maybe not on mobile browsers)? Webshims can handle that too: https://stackoverflow.com/questions/9067536/html5-forms-with-polyfills-is-it-worth-it

Answer 2

Dropdowns and textfields are always faster, assuming that the user can type somewhat quickly and can Tab through the form, and especially if s/he will be fetching multiple reports.

A date picker is intuitive and fail-safe, but the clicks add up if you're thinking of a standard picker; the ones that I've used only let me scroll through months and years.

For example, if the current month and year are selected by default and I want the report from August 2010, I'd have to click three times to reach August (from November) and then click three more times to reach 2010 (from 2013). The click-count will really add up if for some reason I need all the monthly reports for 2010 and I have to start from November 2013 each time.

Because I type over 70 wpm, my preference is actually a dropdown for the months (preferably with the months listed as numbers) and either a dropdown or textfield for the year.

In case any of you don't know, you can select an item from a dropdown menu without clicking it by Tabbing to said menu and then typing the option that you want. The user needs to be somewhat quick in typing "11" to avoid selecting "1" or typing "Jul" to select July instead of June. Numbers are easier to type quickly, obviously.

I've used some forms that don't allow me to quick-type for dropdown menus; in most cases its custom dropdown styling that's the cause. One site doesn't even let me press Enter to submit its form. Don't disable either function.

Answer 3

There are only twelve months but if there are too many years (hundred for age) it's much better to let the user type.

Answer 4

Date picker definitely sounds most intuitive of the three. In what way will Javascript enabled be a poorer user experience?

Questions to ask:

• Who are your users? Are they technical or non-technical? Non-technical may not get the step to click "Go" twice to refresh the page and become frustrated. A solution would be to have a short hover caption that tells the user if they want to change search parameters that they have to click "Go" twice.

• How many months/years of data will you have now? How about in the future? This may or may not eliminate 2, because if you have too many to scroll through, that'll be a pain.

• What will the date picker look like? How are you implementing it? Will it "look" appropriate within the context of the application you're integrating it in (like, no one would do this, but it's an extreme example - a Java GUI applet inside parallax website would look strange and discongruent). Will you be using a widget instead? How will the users navigate the date picker? With a left and right arrow on the side of a displayed month? What about year?