In the enterprise software I help build, we have a date-picker with years in a normal select element. I've gotten the question to revert the way the years are displayed so they are displayed from high to low.
So to scroll up to go forward in years and down to go backwards in years.

I'm going to advise against it, but the only arguments I can come up with are about the convention. Both Android and Apple have year selects that go from low to high.

The only arguments I can think of that would speak for reverting it to high to low, are that fact that "up" is more synonym with "going forward". And that social feeds are normally displayed with most recent posts at the top.

Could you, smart people, think of more reasons to do it one way or the other? I would like more arguments in my arsenal, before going to the product owners.

The datepicker is component based. So it's used everywhere from birthday input to daterange pickers and your normal situations where you need to select a date. Users will primarily use it on desktop (previous Java app was only accessbile on desktop), but since our user base hasn't really shifted yet to using the new webapp we don't really have reliable data telling us if it will be used on mobile devices. We have some data, but that's primarily us testing it. We have plans to accommodate tablets, but tests have shown that most parts of the app are well accessible on later mobile devices too.

  • Is this for mobile or desktop? Commented Jul 27, 2017 at 13:47
  • In what context does the software use years? For dates (2017, 2016, etc) or age (1 year, 2 years, etc)? Commented Jul 27, 2017 at 13:51
  • I added context. It's primarily for desktop and since the datepicker is component based, it will be used for both dates and age. Age will be limited to current year and only previous years, but still, should those previous years be above it, or below it. Commented Jul 27, 2017 at 14:36

2 Answers 2


Putting myself in the user's shoes, I would advise that the current year would be highlighted, where to go up would show years in advance, while scrolling down would be years that have past.

This way, the most current (or most common) year is easiest to find.

  • That is the current way we've implemented it. The starting year in normal situations is the current year, while age has a starting point of current minus our average user age. Do you have any more arguments to support why the user wants/expects that? Commented Jul 27, 2017 at 14:44
  • I just think that it is the most convenient, it doesn't make me think. Much like an auto-populated field function. The only reason I wouldn't do it that way is if you're designing for something that uses something like a multi-year commitment.
    – sjsteve
    Commented Jul 27, 2017 at 15:34

Forget my comment above, bin it and go with the user typing the year on a numeric pad for mobile, no onscreen required for desktop, obviously.

Drop-downs for super lengthy items are a poor user experience.

  • Currently users can type in a full date in their local date format or use the datepicker that has a select for years, which by default also works on user input (typing in 1989 would select 1989) it's just that the user doesn't see what he or she is typing. I'm afraid that the select box for birthdays are always quite lengthy because of the age range that can be entered. But beside that, I'm actually looking for arguments on why to do a certain ordening. high - low. low - high Commented Jul 27, 2017 at 14:48
  • Well we've been through this before and DDLs are almost never recommended for DoB ux.stackexchange.com/questions/5119/… Commented Jul 27, 2017 at 14:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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