2

What is the better input type for a year entry field:
A scrollable “flipper” or a numerical keyboard?

iOS flipper vs numerical keyboard

2
  • The correct answer very much depends on the date range for the actual use case: Acceptable credit card valid dates are few years into the future (like @Jamezrp explained), birth dates are about 100 years into the past usually (and sometimes few years into the future, e.g. in kindergarten application forms and budget planning), historic dates with year-precision or better go back almost 5000 years, astronomic dates can go millions of years both ways etc. Sometimes it’s also better to use relative options like “5 years ago” instead, or even group them as in “more than 20 years ago”.
    – Crissov
    Apr 24, 2015 at 7:48
  • Also, you are asking about a year input, but your screenshots show a year-month and a day-month-year selection instead. Please be more specific.
    – Crissov
    Apr 24, 2015 at 7:56

4 Answers 4

3

In the process of developing a new app (releasing next week), we ran into this exact problem. We originally included a date picker, but went back to the drawing board because we realized we didn't ask the right question. For us, it was straight text inputs, no pickers or options. So, apologies, but you're not asking the right question either.

What is the use case you're solving for?

Ours was with a credit card expiration date, specifically for handling a transaction. And not just any transaction, a donation specifically, for non-profit use. Meaning the biggest case would be that someone is riled up and wants to give, and the person holding the card reader (a volunteer or non-profit organizer) will have only a short window when the donor has the emotional motivation to decide on that gift. Which brings up the following pieces of information to digest:

  • Credit Cards are 0-4 years in the future, meaning only 5 possible selection choices.
  • Time is critical, so whatever's the fastest is important
  • Considering how critical time is, making the process as error prone as possible is equally important
  • Considering how critical error-proofing is, any potential errors (and with any user choice there is the possibility of error) that cause the user to feel stupid are worse than common mistakes.

Those four pieces of information, as well as basic in-house testing, made it very clear that the traditional date picker (for iOS or Android) did not cut it. The physics engine on iOS is smooth, but no one knows how hard/soft to swipe to get the correct selection. It's not easy. It's dynamic, which is too much to handle for some people. Internally we found that we'd constantly go back and forth with selections...FOR 5 OPTIONS!?! That's unreasonable.

Furthermore, there are actually 2 selectors to use: Month and Year. While Apple apps can use multiple selection options, we couldn't. Even if we could though, the reason above made it an untenable solution.

So we made it a text field with some basic logic that's existed for years. Manual text entry. Let me repeat that.

Manual text entry.

It's simple, everyone knows how to do it (including people without a smartphone), and it doesn't include the stupid factor. People mistype all the time, nobody cares about that. Our testing internally proved it, and more importantly, people made more mistakes but were happier with it. Weird, right? But it makes sense: dynamic fields can lead to confusion. Static ones don't because they are static. There's a permanence to them, which leads to trust. And if the user trusts that they put in the date wrong by accident, they can live with that and fix it. But if they can't trust the input from the start, then they'll feel like they made the mistake and that it's their fault.

TL;DR all text with some logic is best, but depends on the use case.

2
  • 1
    The flipper is a usability nightmare, whether Jony Ive wants it to be a standard or not. It's a case of flash over function -- Apple got too excited about their physics engine. Apr 24, 2015 at 6:21
  • @plainclothes utterly agreed, it's categorically the worst platform vendor authored control I've ever seen.
    – Jammer
    Feb 2, 2016 at 5:42
0

Scrolling from 2015 to some older years can be a pain, I suggest a two digit (not four) entry field. It is the fastest way, and the first two digits in a birth year are unneeded.

3
  • 1
    I thought that whole two digit year thing didn't turn out so well (^_-) Apr 24, 2015 at 0:09
  • Welcome to UX.stackexchange. There may come a time shortly where having someone chose 19 | 20 may make sense. Of course if it's 2020 and the birth date is 75 it can be "assumed" that the first two numbers are 19. However user mistakes do happen.
    – Mayo
    Apr 24, 2015 at 0:31
  • @plainclothes That‘s true for storage, but not so much for user interfaces.
    – Crissov
    Apr 24, 2015 at 7:51
0

The scrollable “flipper” for one important reason.

When in that format, it shows relationship to other data points (the years before and after) and this helps to focus the user’s mind in a time-based thought process, which is the desired cognitive state for recalling and asserting this type of information.

Users lose focus or forget what they’re doing; Give them what they know and let them choose from a meaningful data set, even if it may be slightly slower, because it’s a better user experience.

1
  • This can be easily fixed with a proper label and an example. For a date, the label just needs to read date type (ie. expiration date, birthday, etc.) and the example the format (MM/YY, DD/MM/YYYY, etc.).
    – Jamezrp
    Apr 24, 2015 at 7:12
0

I prefer the scroll-able in iOS. A key UX principle is to be consistent with industry standards. Jakob Nielsen had this on his famous 10 usability heuristics for UI design (see "follow platform conventions" Furthermore Most of the time for current dates and birth dates the user wont do much scrolling.

You can also put multiple wheels if your date ranges are very wide. For example look at the middle design where you can allow them to quickly hone in on their birth decade then their birth year to eliminate excessive scrolling. However if your range gets really large in the 3rd design (lets say its a history quiz game you could break it down by century then decade then year but at that point i would just go with a plain text input field for the date)

enter image description here Also this is a very common convention in iOS so many iOS users will be familiar with this. I like the look and feel of this especially if its only done once. If you often entering dates of a large range I might avoid this.

Take a look at the default iOS event adder in their calendar app when you choose a date. It has been like this since the iPhone 3 if i remember correctly. So iOS users are most likely going to be familiar with this convention.

iOS add and event

Now if it lives in a web page you could make the argument for the other design so it's consistent across experiences but I personally would use an abstraction say PhoneGap to have it use the native default date picker for that device.

**Just an alternative thought in favor of the scrollable wheel , it may seem sleeker and slightly more enjoyable but I doubt it would win any performance battles vs text field say in a GOMS KLM or any other performance test. **

2
  • 1
    Your screenshot shows how to select near dates and a time. The question is about years.
    – Crissov
    Apr 24, 2015 at 7:54
  • @Crissov yo are absolutely right. I edited it with mockups of the thought I had in mind. I agree its most likely not the best way to do it always but just an argument in favor of doing it this way in some instances. Apr 24, 2015 at 14:06

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.