
Why Users Abandon Forms with Select Menus - antimid
http://uxmovement.com/forms/why-users-abandon-forms-with-select-menus/
======
kileywm
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.

~~~
navait
Zip code is usually a better way if it's relevant - you can fill in the
state/town automatically.

Obviously, there are situations where that would not apply.

~~~
eric_the_read
Even with ZIP codes, they don't always map to a single state.
[http://gis.stackexchange.com/a/167333](http://gis.stackexchange.com/a/167333)
lists 13 zip codes that map to multiple states, never mind cities.

------
EdiX

        More users start forms than finish them
    

Imagine if the opposite happened!

~~~
coldtea
What's so special about the opposite? It can easily be achieved.

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".

~~~
mwfunk
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. :)

~~~
coldtea
Yeah, mostly tongue in cheek response.

------
CamperBob2

       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.

------
molecule
This strikes me as somewhat of a mish-mash:

\- 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.

------
ramanathanrv
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.

~~~
blacksmith_tb
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.

------
mschuster91
There's another solution: cascaded dropdowns.

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 :(

~~~
detaro
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...

------
agateau
I disagree with the article for two reasons:

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.

~~~
fibbery
I think that's why they were suggesting to make it a button with a radio
button inside it(?), but that seems kind of wacky to me

------
asimuvPR
Devils advocate here: use select menus to reduce the amount of support tickers
from users. The html form version of the automated telephone menu.

~~~
rubidium
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.

I always pick the most dire issue.

------
girzel
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...

------
kazinator
> _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.

~~~
CM30
To be honest, that reminds me.

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?

~~~
kazinator
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.

------
StillBored
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..

~~~
wccrawford
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.

~~~
StillBored
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.

------
protomyth
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.

------
some_guy1234
Uhh, how about some forms ask for too much information, or are too long!

