Why Users Abandon Forms with Select Menus
uxmovement.com
uxmovement.com
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.
More users start forms than finish them
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 :)
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.
- 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.
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.
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...
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 always pick the most dire issue.
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...
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?
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.
Also, putting items in the menu is some random order is not real helpful.