I've seen this before in IT tech support. Invariably there's some drop down where none of the selections apply to my issue, but it's required to pick one.
- It predominantly addresses the lowest-common-denominator subset of users: beginning / un-savvy users who are using a site / its forms for the first time, but the article attempts to make a point by referencing behaviors of familiar, advanced users: navigating a form's fields using the keyboard: Most forms begin with text fields where users type in their input. But when a select menu appears, they have to move their hands from keyboard to mouse to select an option. This interrupts their typing flow and slows them down.
- Discourages the use of select menus because they are 'hard to read' and require 'dexterous mouse maneuvering', but both of these can be mitigated via CSS.
The article has good points and has some good recommendations and is useful for its target use case, but the absolutist prescription, 'The Only Time to Use a Select Menu', seems to only address a specific case: using a form on an unfamiliar site for the first time, which would be fine for the article if were stated as such. However, there are many times when a select menu is appropriate: familiar users who use a site multiple times, when available space and / or menu population precludes the use of radio buttons, etc.
The article suggests radio buttons instead of most select menus.
I can appreciate the ease with which one can skim radio buttons vs select options; however, once there are more than a few options, the sprawl of radio buttons can be a little ridiculous.
The screen space required to display 50 states via radio buttons vs select menu is tremendous. At that point, I suspect it would be difficult to determine where the list of radio options end and the next form field begins.
Even with ZIP codes, they don't always map to a single state. http://gis.stackexchange.com/a/167333 lists 13 zip codes that map to multiple states, never mind cities.
To top it off, most of the author's complaints about drop-down menus apply doubly so to radio buttons.
Selecting with the keyboard? My browser lets me select a menu, type a letter, and jump to the first entry starting with that letter. I've never seen that work with radio buttons (though I admit I haven't tried it recently).
Selecting from a long list on a phone? Selecting a menu on my phone gives me a popup menu that scrolls independently of the rest of the page. Selecting from a list of radio buttons requires a scrolling action that changes my location in the page. If I want to return to a field above the list of radio buttons, I have to scroll back.
My non-expert advice: Never use radio buttons for a set of more options than you can guarantee will fit on the screen simultaneously. If your UI has any mobile users, that probably limits you to four options, maybe less.
I was wondering myself what the use case for 50 options would be, then I thought about countries. However, a select list is usually far from ideal: are there 'popular' choices at the top? is the list grouped by continent? is my country "united kingdom" or "great britain" or "england"? is the drop-down set to display an absurdly small (i think the default often is) number of options?
If you insist I enter my country to conform to the exact string you've chosen for it, please let me just type it into a well-implemented auto-completing text box.
One common reason is if your form contains multiple
select menus. Research shows that forms with select
menus often get abandoned. This is because they take
more time and effort to complete.
No, actually, in my case at least, it's because they often don't include the option that applies to my situation. When that happens (and there's no 'Other' selection option) I'll either pick something at random, or abandon the form.
> But when a select menu appears, they have to move their hands from keyboard to mouse to select an option. This interrupts their typing flow and slows them down.
Simply not true. They do not have to; they just don't know that when the keyboard focus is on the list or combo box, they can go through the selections using the arrow keys.
But even for those who know the keyboard shortcuts, long lists are annoying, like long lists of countries (most of which will never produce a paying customer for that site), or lists of of years starting from 1900.
Why do sites use drop down menus for years like that?
I mean, in new browsers (or older ones with Javascript) you can add perfectly good calendars for things like date of birth, booking date, etc. In other ones, you can just let them type in the value in some restricted format. Who honestly cares if someone claims to be 150 years old?
Moreover, if you want to be able to filter out bogus entries, you have to let users enter bogus info. If you put in too many constraints, you hamstring your ability to tell bogus from good. For instance if you reject 555-NNNN phone numbers because 555 is fake, the determined user will enter a more convincing fake phone number.
> long lists of countries (most of which will never produce a paying customer for that site)
On the other hand, it's extremely frustrating to arrive to this step, fill in all your details, and there, right at the end, open the country list and... it's just a handful of large English-speaking countries including one that neighbours your own country, but not yours.
What would you suggest in order not to have an annoying long list of countries, but still allowing everyone to order even if you did not expect customers from Luxembourg or San Marino?
One common, nasty example is a list of countries in online shops. Many at least either pre-fill based on IP geolocation or stick the most common target countries at the top, but there are also some sites that sort alphabetically, or worse, group by continent and then sort.
This can be solved by having only one dropdown visible with the continent; once this is selected, a dropdown with the country appears below, and optionally a third dropdown for the county/state (e.g. USA, optionally in Germany but no one requires the state in Germany anyway).
Downside of this approach, though, is that browsers cannot auto-fill.
On a sidenote, I remember that you can "annotate" input HTML elements to ease auto-fill (besides the obvious type=tel/fax/email). Can anyone please give me a hint? I seem to be too stupid to find the guide for this again :(
I find the multi-dropdown pattern even more annoying. Yes, the individual choices are smaller, but then I have to click/tab-select the next drop-down multiple times, wait for fold-out animation, understand what the options are, repeat, and there often are strange bugs, e.g. if you try to fix an error. Non-dropdown selects next to each other are better for this pattern IMHO, but take space.
Searchable dropdowns/autocompleting text fields really should be part of the HTML standard...
The biggest complain I see from users is the Mobile Picker part of the argument. It does make like a pain when you cannot read the options in their entirety. An improved picker would be better. I am not really convinced of the other arguments.
Also, putting items in the menu is some random order is not real helpful.
Well, call me crazy, but I'm going to go out on a limb here and postulate that in the context of this discussion, the people finishing the forms are presumed to be the same people who started them. You could probably also find loopholes if you take into account things like time travel paradoxes but I'm not sure if it really adds anything. :)
I think your assumption of what a form is, and the implied behavior it exhibits, is different than mine. How do multiple people pick up a single abandoned form and complete it?
Edit: Oh, nevermind. I read your example more closely. I guess, the question is in a digital context, how are different users completing forms than the ones starting them. Unless you are just making a point about how it's theoretically possible, even if more likely in an analog context.
>I guess, the question is in a digital context, how are different users completing forms than the ones starting them. Unless you are just making a point about how it's theoretically possible, even if more likely in an analog context.
Well, it was more of a tongue-in-cheek reply -- I tried to hack through the seeming "impossibility" the parent mentioned.
That said, I can see several ways to achieve that in a digital context:
a) the users can be in the same physical space. So one starts 10 forms etc, and then ten others sit on his computer and finish them.
b) we could build a fancy networked way to share forms ("collaborative form completion"), or just use something like remote access / VNC etc to be able to keep the users each in their own space.
c) or merely share accounts. A user logs in as X1 to X10 and starts 10 forms, then 10 users login in the same accounts with the same shared credentials and finish them.
I like c), I think that neatly satisfies the preconditions that I think would most likely be present and cause problems with a) and b). It wouldn't necessarily work on multi-page forms that store data in the session, but that still leaves quite a few systems where it's possible, and not really hard to accomplish. :)
It does happen. I am from a third world country and one year my friend worked on the databases for counting election results. In certain regions where the ruling party rigged the elections, there were more votes (for preferred candidates) than registered voters!
The internal database checks would not allow this and the minister in charge of elections called him in the middle of the night to complain that the system was not working :)
The article is postulating only a theory. We have seen the opposite true in credit card forms where users have to input card expiry date. No matter what sort of formatting we did, users always typed expiry wrong and our JS would point it out. We finally had to abandon input text boxes in favor of select boxes for card expiry month & year. We measured the eventual success rate and that turned out to be higher as well.
My guess is that since the scope is so narrow (1 out of 12 choices for month) and selection is very obvious, perhaps people made lesser mistakes here. Select boxes are more effective in mobiles as typing takes more effort than tapping.
This is something that is badly implemented on many, many checkout forms, partly due to using selects/dropdowns (since they conceal how the choices are formatted), but mainly because an amazing number of sites seem to think it's reasonable to offer only January, February, March instead of the 01, 02, 03 that actually appear on all credit cards. This not only stops you from focusing that element and typing to choose it, but opens up the possibility the user will choose July for 06, for example.
Uh, apparently the author didn't notice that on a couple platforms, you can generally type into a select box and it will act sorta like an autocomplete. I do this all the time for US state select boxes, I tab into them and press 'T', 'T' which generally gives me 'TX' which follows 'TN'.
Select boxes are for long exclusive lists. I would like to see all the US states in a radio grouping... Not..
I hate that US states are so commonly in a dropdown/select field -- it is so much easier to just type the 2-letter code into a textbox!
(As a web developer, I of course totally understand that sometimes you need to ensure the input is the 2-letter code and not the full word or not mis-spelled... but it's not like zip code are dropdowns, and those are often more important than the state in terms of matching up to an existing record in some database somewhere.)
The author, and a lot of computer users. My parents would have no idea that that kind of thing could work. Even if they were told, they would likely forget because they do it so seldom.
Well, computer users aren't the problem its all the UX "experts" that have never read a HID document for any major platform (especially desktop ones).
I don't care if grandma once a week has to reach for the mouse to fill in an select box. What I care about are the applications/sites that break any number of imput devices (particularly keyboard, but frequently desktop touch, or pen based) because they think they know better and decide to invent some new paradigm without understanding the existing ones. This is part of my gripe with much of the last 10 years of windows, which broke a lot functional paradigms without replacing them with an alternative. Or they 1/2 broke something.
Take the right click on the task bar to open an applications system menu which worked from windows 95->vista. That operation now gives one the nearly useless option to pin the application. Now when a window is offscreen and I need to move it onscreen, and the app developer broke the alt-space keyboard combination you have to know that MS changed (and didn't really document it anywhere) the behavior too the very mac like, shift click. Pretty much the only place in windows that the mouse buttons have keyboard modifiers. Its like the guy who wrote it couldn't figure out how to add a "pin to taskbar" option to the system menu.
1. Many computer-illiterate users always click to switch from one input to another, so clicking on a select does not make them much slower
2. Many users are not aware that the text part of a radio button is actually clickable and will loose time precisely aiming at the round circle to select it. And they are unfortunately often right to aim at the circle because of the many loosely design pages which do not make the text part of a radio button clickable.
Select menus are bad, but multiple select menus are a new level of anti-user hostility. With single select at least you can use the keyboard; with multiple select you're in for keyboard-plus-mouse-plus-squinting pain, and a real possibility of screwing it up and having to start again.
I run a site where user input often takes the form of long select menus. I'm typically dead against javascript "helpers", but this is a use case that just screams for ajax and dynamic field munging. I still haven't gotten around to doing it, though...
39 comments
[ 2.8 ms ] story [ 90.3 ms ] threadI always pick the most dire issue.
- It predominantly addresses the lowest-common-denominator subset of users: beginning / un-savvy users who are using a site / its forms for the first time, but the article attempts to make a point by referencing behaviors of familiar, advanced users: navigating a form's fields using the keyboard: Most forms begin with text fields where users type in their input. But when a select menu appears, they have to move their hands from keyboard to mouse to select an option. This interrupts their typing flow and slows them down.
- Discourages the use of select menus because they are 'hard to read' and require 'dexterous mouse maneuvering', but both of these can be mitigated via CSS.
The article has good points and has some good recommendations and is useful for its target use case, but the absolutist prescription, 'The Only Time to Use a Select Menu', seems to only address a specific case: using a form on an unfamiliar site for the first time, which would be fine for the article if were stated as such. However, there are many times when a select menu is appropriate: familiar users who use a site multiple times, when available space and / or menu population precludes the use of radio buttons, etc.
I can appreciate the ease with which one can skim radio buttons vs select options; however, once there are more than a few options, the sprawl of radio buttons can be a little ridiculous.
The screen space required to display 50 states via radio buttons vs select menu is tremendous. At that point, I suspect it would be difficult to determine where the list of radio options end and the next form field begins.
Obviously, there are situations where that would not apply.
Selecting with the keyboard? My browser lets me select a menu, type a letter, and jump to the first entry starting with that letter. I've never seen that work with radio buttons (though I admit I haven't tried it recently).
Selecting from a long list on a phone? Selecting a menu on my phone gives me a popup menu that scrolls independently of the rest of the page. Selecting from a list of radio buttons requires a scrolling action that changes my location in the page. If I want to return to a field above the list of radio buttons, I have to scroll back.
My non-expert advice: Never use radio buttons for a set of more options than you can guarantee will fit on the screen simultaneously. If your UI has any mobile users, that probably limits you to four options, maybe less.
If you insist I enter my country to conform to the exact string you've chosen for it, please let me just type it into a well-implemented auto-completing text box.
Simply not true. They do not have to; they just don't know that when the keyboard focus is on the list or combo box, they can go through the selections using the arrow keys.
But even for those who know the keyboard shortcuts, long lists are annoying, like long lists of countries (most of which will never produce a paying customer for that site), or lists of of years starting from 1900.
Why do sites use drop down menus for years like that?
I mean, in new browsers (or older ones with Javascript) you can add perfectly good calendars for things like date of birth, booking date, etc. In other ones, you can just let them type in the value in some restricted format. Who honestly cares if someone claims to be 150 years old?
One reason is that it's a (extremely) lazy / dead simple way of getting around the need to do input validation on the year field.
On the other hand, it's extremely frustrating to arrive to this step, fill in all your details, and there, right at the end, open the country list and... it's just a handful of large English-speaking countries including one that neighbours your own country, but not yours.
What would you suggest in order not to have an annoying long list of countries, but still allowing everyone to order even if you did not expect customers from Luxembourg or San Marino?
One common, nasty example is a list of countries in online shops. Many at least either pre-fill based on IP geolocation or stick the most common target countries at the top, but there are also some sites that sort alphabetically, or worse, group by continent and then sort.
This can be solved by having only one dropdown visible with the continent; once this is selected, a dropdown with the country appears below, and optionally a third dropdown for the county/state (e.g. USA, optionally in Germany but no one requires the state in Germany anyway).
Downside of this approach, though, is that browsers cannot auto-fill.
On a sidenote, I remember that you can "annotate" input HTML elements to ease auto-fill (besides the obvious type=tel/fax/email). Can anyone please give me a hint? I seem to be too stupid to find the guide for this again :(
Searchable dropdowns/autocompleting text fields really should be part of the HTML standard...
Also, putting items in the menu is some random order is not real helpful.
10 users start 10 forms each, but leave them incomplete.
100 other users then finish one each of those forms.
So you have 10 users starting 100 forms and 100 users finishing said 100 forms, thus "more users finishing forms than users starting them".
Edit: Oh, nevermind. I read your example more closely. I guess, the question is in a digital context, how are different users completing forms than the ones starting them. Unless you are just making a point about how it's theoretically possible, even if more likely in an analog context.
Well, it was more of a tongue-in-cheek reply -- I tried to hack through the seeming "impossibility" the parent mentioned.
That said, I can see several ways to achieve that in a digital context:
a) the users can be in the same physical space. So one starts 10 forms etc, and then ten others sit on his computer and finish them.
b) we could build a fancy networked way to share forms ("collaborative form completion"), or just use something like remote access / VNC etc to be able to keep the users each in their own space.
c) or merely share accounts. A user logs in as X1 to X10 and starts 10 forms, then 10 users login in the same accounts with the same shared credentials and finish them.
The internal database checks would not allow this and the minister in charge of elections called him in the middle of the night to complain that the system was not working :)
My guess is that since the scope is so narrow (1 out of 12 choices for month) and selection is very obvious, perhaps people made lesser mistakes here. Select boxes are more effective in mobiles as typing takes more effort than tapping.
Select boxes are for long exclusive lists. I would like to see all the US states in a radio grouping... Not..
(As a web developer, I of course totally understand that sometimes you need to ensure the input is the 2-letter code and not the full word or not mis-spelled... but it's not like zip code are dropdowns, and those are often more important than the state in terms of matching up to an existing record in some database somewhere.)
I don't care if grandma once a week has to reach for the mouse to fill in an select box. What I care about are the applications/sites that break any number of imput devices (particularly keyboard, but frequently desktop touch, or pen based) because they think they know better and decide to invent some new paradigm without understanding the existing ones. This is part of my gripe with much of the last 10 years of windows, which broke a lot functional paradigms without replacing them with an alternative. Or they 1/2 broke something.
Take the right click on the task bar to open an applications system menu which worked from windows 95->vista. That operation now gives one the nearly useless option to pin the application. Now when a window is offscreen and I need to move it onscreen, and the app developer broke the alt-space keyboard combination you have to know that MS changed (and didn't really document it anywhere) the behavior too the very mac like, shift click. Pretty much the only place in windows that the mouse buttons have keyboard modifiers. Its like the guy who wrote it couldn't figure out how to add a "pin to taskbar" option to the system menu.
1. Many computer-illiterate users always click to switch from one input to another, so clicking on a select does not make them much slower
2. Many users are not aware that the text part of a radio button is actually clickable and will loose time precisely aiming at the round circle to select it. And they are unfortunately often right to aim at the circle because of the many loosely design pages which do not make the text part of a radio button clickable.
I run a site where user input often takes the form of long select menus. I'm typically dead against javascript "helpers", but this is a use case that just screams for ajax and dynamic field munging. I still haven't gotten around to doing it, though...