Dropdowns: The Scourge

Thursday, February 18, 2010

It doesn’t happen much that I think about HTML. In a weird convergence of events, though, I find myself reflecting on SELECT boxes, aka “dropdowns”. Specifically, how they are my own personal bane, and how application developers can redress the scourge they have put upon us.

This is my story.


This is a screenshot from Mint.com’s account setup screen, wherein you can enter your username, password, and answer security questions for the account which match the security questions from your bank. The typical workflow goes:

  1. You answer your security questions at your bank’s website
  2. You go to Mint, you set up the account (account numbers, usernames, blah blah), and you fill in the security questions
  3. You hit a submit button, magic happens, and all your data gets pulled into Mint.
  4. Glory ensues

Except: Step number 2 isn’t really step number 2. It’s like step 2 through 108. With the 106 steps being “read every $*%!ing option in the “security question” dropdown list 5 times, maybe 10, to try to find a match to the questions that you answered on your bank’s site. Oh: they’re not sorted; they’re not worded exactly; they’re in no way thematically related. It. takes. for. ever.

To wit, pain:


Notice the size of the thumb on that dropdown. Notice how the questions are ordered in no sensible manner. Imagine using this for real.

I dare you to guess how many choices there are in that one option list. Now multiply it by 3, because that’s how many questions you have. By the way, Intuit now owns Mint.

And you thought that was bad

You will not be able to read the content of this image. You will, however, see that it is an HTML dropdown, based on the fact that there is a scrollbar on the right side. The thumb is a few millimeters tall, indicating that the list is very long.


This is part of a time-keeping application that folk in my company must use. This dropdown contains a list of projects. You go to this screen, you pick your project, you pick options from other dropdown lists, you enter how many minutes you worked on that application for the day. Repeat as needed.

Now, I figure that most developers work on at most 5 projects at any one time. Do you know how many projects are in the list in this screenshot? Can you guess? Now, in your head, do the math… 

5 / NumAvailableProjects = % of shit that is relevant

or something like that. It doesn’t matter. Math doesn’t matter. The size of that thumb in the dropdown is all that matters.

Your job as a user

Your job as a user of an HTML select is to pick an option from a list. Usually, you know exactly what you want. Or damn close. Probably you use this application every day. That means when you’re picking options from your Project list, you know 90% of the characters in the text string that makes up the OPTION. You’re not poking around, thinking “hmmmm, I wonder what options are available to me”. Most option lists you encounter aren’t a whimsical stroll through unknown possibilities (like, for example, “Which shipping method would you like?”).

Most of the dropdowns in your life contain XX% noise, and 1 thing you want. But you gotta get through the XX%, every single time.

When I was 15, I took a job as a meat room cleanup kid. I learned how to use a knife, how to clean a block, how to “bone meat”. Eventually, during college, I worked as a meat cutter. I “worked racks”, which meant taking racks of meat from the cooler to the case and back again. Meat rooms are designed for efficiency of meat movement. If it were still alive, a Delmonico could wheel itself from cooler to case… that’s how well most meat rooms are designed.

Imagine putting a 3-foot curb between the cooler to the meat room, then from the meat room to the supermarket floor. How, tell me, could you wheel that meat cart over a 3-foot curb?  HTML dropdowns like the one above do the same kind of disservice to a user: they significantly impede progress. If you’re a manager-type, you won’t understand anything I’ve written here, so let me put it into Manager-ese: It “has a negative effect on productivity”.

By the way, that dropdown is courtesy of QuickBase, a wondrous, extensible, powerful, enterprise-y application. Sadly, I know nothing of its wonder. All I know is that I have to pick a single project from that enormous dropdown list and I hate the application for it. By the way, QuickBase is an Intuit application.

You need to know

Take off your user hat, and put on your developer hat: You need to know that as the application developer, all those fancy things you do to get your enterprisey app to meet all the needs of all your big-dollar customers – to make your app behave as a JeeJaw for Customer1 and a Fahoozle for Customer2 AND a timekeeping application for Me – all the magic you have to work doesn’t mean a damn thing to people like me. What matters to me is the dropdown. I don’t want to marvel at your skill. I want to fill out my timesheet and do my real job. But I can’t do that quickly because I have to pick one option from a 523-and-growing list of projects.

I know, I know. “But that’s not how we designed it!”

Whatever. You wrote it. You own the Problem. Only you can fix it.

How to fix it

The current SELECT element in html is broken. Even 15 years ago, people knew it sucked. Every time you have to choose a date from an old-school date picker (month, day, year), you’re suffering from the failures of the HTML fathers to predict the grievous abuses that website developers would inflict. Every time you fill out your credit card details in an order form and have to scroll through an interminable list of expiration dates, you pay for their mistake. Perhaps you have some authority in your projects to suggest a correction.

I started with what is, frankly, the only awful part of the Mint.com experience. I’m going to end with the part of the application I interact with most frequently and which I consider the current best model for what SELECT lists should become. In other words, If I were in charge of the HTML spec, dropdown lists would have this functionality built in.


I’m making this image big b/c I want you to see it right away. Notice how the dropdown list itself is a type-in box. It is built for filtering. It’s built for action. Your job as account maintainer is to look at a line item and assign it to a category if Mint.com got it wrong. You know exactly what it needs to be. Or close enough. You know it’s a “coffee”. You know it’s “gas” for your car. You know it’s a tax of some sort. Mint’s category dropdown perfectly addresses this need. You start typing in the type-in box, and it filters down to whatever options might match what you’re searching for. You could have 300 categories and subcategories configured, or you could have 1000. It does not matter.

This is what that same dropdown looks like as soon as I start  typing the name of the category I want to put the expense in:


I do not need to know exactly how the category starts, either. This is critical: good searching lets you, the user, be “close enough”. For example, if I wanted to categorize something as “auto insurance”, but didn’t remember if the category was “car insurance or “auto insurance”, I’d just start typing “Insurance”. With a few characters of typing, it narrows down to the available options, and I can easily see that “Auto Insurance” is what I want. I arrow to the choice I want, hit “enter”, and I’m done.


The central concept is:

You know what you’re looking for

The standard HTML Select list is built around: “WE have no idea what you’re looking for. You choose”.

Let me break this down for you


“You know”


“We don’t know”

As a developer, you should…

Find ways to anticipate odious dropdowns in your applications. When you find them, consider a Mint.com style dropdown.

If you have good suggestions for canned/pre-built/jquery plugin/whatever examples of this, please share them with the rest of us.

Until you do so, realize that every dropdown that is populated by  a database query or some other external, non-hard-coded datasource has the potential to grow. Do not kid yourself thinking “it’ll only ever be a few elements”. It won’t. The thumb will get smaller and smaller, and some user will start to complain. And you know what:

They’re right.


Grant Copley said...

Great post! While reading, I couldn't help but laugh as this is a topic that my boss brings up regularly. Daily! He hates drop-downs more than anyone I know. I agree with you, HTML dropdowns suck.

Dan G. Switzer, II said...

A while back, I wrote a jQuery plug-in with similar functionality:


It allows for nested categories and typing to automatically filter the results.

We have an application that can get very big, very quickly, so we needed a way to better handle how users are able to select the options.

Marc Esher said...

@Grant, thanks for the feedback!

@Dan, thanks for the link. I'ma check it out now

Micky Dionisio said...

LOL Very nice post. Love the naming of your images!

drop downs = t3h suck.

bill shelton said...

great post, marc. i love it! thinking about a little deeper, for me, it comes down to 2 or 3 challenges in usability. 1. clicking and scrolling, 2. aiming the mouse pointer at a very small area on the screen, and 3. displaying lots of expanding information in a small visual space. scrolling is a pain. the "aim and click" problem is just plain wrong - you know, when you miss that every-shrinking thumb by accident, you once again have to click the widget, and start scrolling yet again. developers should not require users to be mouse cursor sharpshooters. at least with typing (which is still a primitive HCI, imo) and doing some kind of search, we have a better idea of what the user is looking for. the mouse is dumb and doesn't convey much of the user's intent - it only says, "I clicked on this x,y coordinate". combine that with a dumb widget and you get dumb and dumber.


Lola said...

Great post! I really hate long dropdowns where I have to scroll down forever. This is useful for us developers to keep in mind.

Allen said...

Overall I agree but we have to remember that "solutions" such as letting the user type to filter doesn't necessarily help either. Different people remember things in different ways. For example, the other day I went to listen to my Roling Stones playlist on m MP3 player but it wasn't there. Well, a few days later, duh, it was. Only I should've been looking for "The Rolling Stones" instead of "Rolling Stones".

So it's not just about giving our users tools to filter but giving them tools for the information to show up the way they think, not how we as developers think.

Marc Esher said...

@Allen, great point. Back in the "old days" when Autosuggest / filters were just making their way into websites, they were all about "the first few characters".

They've come a long way since then. I'm a fan of the jquery Autocomplete plugin, and it behaves "correctly", in that it performs a substring match, not a startstring match.

I've updated the original blog post to point this out as a feature of Mint's autocomplete (down toward the bottom).

Thanks for the comment.

Tink said...

I know this post talks of HTML but if your looking for this filtered functionality in Flex you may find this useful


Marc Esher said...

Very cool, Tink. Thanks! I'll keep that one in my toolbox, as I hope to be doing more Flex in the future