2

Is it best practice to have text fields or dropdown + textfield combination form month year? Does it changed if the month is listed as 01 vs January? (The ^ indicates dropdown)

Note: Users use the form often where speed is most important metric.

Option 1 - both freeform with placeholder text :

[MM][YYYY]

Option 2 -month as dropdown:

[01 ^][YYYY]

Option 3 - month as dropdown with year as placeholder:

[01 ^][year]

Option 4 - month as dropdown with name listed out (Google method):

[January ^][Year]

2

Something relevant for choosing data format : The source of the user's input:

If you know the source from user's input is formatted in some way you will want to maintain that format, because you don't want the user to make unnecessary mental conversions. Examples of this are expiration days in credit cards or invoices (at least in my country).

If there're are no clues about the source, question: Would most selected years be ...?:

  • Frequently not showed in the first options of the dropdown => Text input for year.

  • Mainly recent years => Go with the dropdown. Here you get the advantage of avoiding unnecesary typos within text inputs.

About the month, I prefer dropdown because it's a known and short list and there's not too much to go wrong with it. Also the month as a number has more cognitive load and could lead to more errors (is more probable that in a rush anyone could get wrong with the number-monthName association, again: unless the source is in the same format).

  • 1
    Thanks. The fields are for home date-of-purchase so the years may not be recent. – user52330 Jan 29 '15 at 19:05
  • I've added more reasons that could be useful. – Alejandro Veltri Jan 29 '15 at 19:24
0

If speed is your most important metric then probably option 1. There are in-line editing and checks that can be done to improve accuracy that you lose by not using droplists:

  1. Ideally the MM and YYYY letters get replaced as the user types it in. The placeholder text should be clearly differentiated from input text so as you type. For example it would look like "0120YY" if you were in the midst of writing Jan 2014, the YY would be in a light gray and the 0120 would be black.

  2. Auto insert and remove spaces and special characters. If the user types in 012014, it should auto insert a space so it reads 01 2014 for better readability. If they type in 01 2014/ it should remove the extra space and the excessive character. There are a few ways you can improve readability, this is just one example.

  3. On focus, allow a mini calendar selector to appear as well allowing them to see the month change as they type and the year. It also allows them to use the selector if they choose to do so. Obviously this adds a bit of extra effort in terms of build.

  • I may not have been clear in showing that the two fields are independent. Does that change your thinking? – user52330 Jan 29 '15 at 19:03
  • Typed input is still recommended when speed is your primary goal. I do recommend combining into 1 field if possible as 2 tends to be a bit fidgety since not everyone knows to use the tab key and if it auto jumps to the next field then often times it jumps when the user doesn't expect or doesn't jump when the expect it to if they need to edit a typo. This is based off experience interviewing and testing users for an internal facing webapp. – skwokz Jan 29 '15 at 19:12
  • If I were to add "Reduction in errors" as the secondary goal, would you advise differently, e.g., month as dropdown with text "January, etc."? – user52330 Jan 29 '15 at 19:14
  • I don't know your users, but for the few internal apps that I designed and tested, the users were strongly against dropdowns since they felt it slowed them down a lot. Inputing dates was much faster using the keypad on their keyboard for them than clicking on the mouse or using arrow keys to select. I tend to try to have the mini calendar to supplement as well since it allows for both input types. If your users are very mouse driven, it may not slow them down a lot. The noted they were diligent to always check their inputs. – skwokz Jan 29 '15 at 21:14
0

General Usage:

mockup

download bmml source – Wireframes created with Balsamiq Mockups

Without any context, spelling out the month (Jan, or January) in a dropdown probably cause less confusion as compared to "01" in a dropdown or a freeform digit input box.

I'm speaking as a user from North America, we rarely enter months and year without the day (unless you're referring to credit card expiry dates). We say it out loud as "January 2015", not "1 2015". So using the word removes the mental translation. There's also only 12 months in the list. So it's a reasonable number of choices even if the user does manually click on the month instead of typing in the dropdown to access the right month.

As to the Year, the choices are rather numerous so a text input makes more sense. Since there's only 1 way (in numbers) to write in the year, there's no mental translation needed.

Credit Card Usage:

mockup

download bmml source

The other common exception case I want to bring up is for Credit Cards. Because the numbers are printed at the back of the card in "MM / YY" format. It makes more sense to provide text inputs for user in that exact same format so they can type it all in exactly as its printed on the card.

  • Than you for the details response. All of our users are from North America. I didn't think about "we rarely enter months and year without days" concept. Very insightful! – user52330 Jan 29 '15 at 19:16
  • You're welcome. :) Only reason I mentioned that is that it's common in Asia to rattle off birthdays as a string of numbers. A set of text inputs fields will make more sense there. – nightning Jan 29 '15 at 19:21
0

Your question didn't specify the use of the form. I'm currently working on a form which allows sales people to enter dates by selecting calendars. They have dozens of actions to perform on each sale including sale date, cancellation date, payment due date, delivery date, and last day to request a return.

They go through many such sales forms at one time. I solved that problem by using calendars where they select the day in the month by selecting the day in a calendar. There are a limited amount of months (no more than 180 days from the current day).

EX:

+---------------+  +---------------+
|      JAN      |  |      FEB      |
| 1 2 3 4 5 6 7 |  | 1 2 3 4 5 6 7 |
| 8 9 ..........|  | 8 9 ......... |

Now this solution obviously does not work in every use case but in this case it presents a very fast way for the sales force to enter the requisite information.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.