Christian Heilmann

Interfaces that have to die – the onchange select box

Thursday, July 10th, 2008 at 11:31 am

It is scary how some obviously bad practices refuse to go away and developers jump through hoops to defend them and make them work rather than using simpler alternatives.

My pet peeve is the “chess rules” select box (you touched it, it needs to move):

This is the most evil permutation of this interface idea. A lesser evil version is part of a large form that will change the rest of the form or – if we venture back into more evil lairs – submits it to reflect these changes.

The arguments for this interface are not many:

  • It saves the user one step of pressing a submit button
  • The action is immediate

(Ok, these are actually the same argument, comment if you know some.)

The drawbacks of the solution are immense:

  • People that use a keyboard will submit the form or leave the page without having selected the right option.
  • People that are dependent on using a keyboard for web access will possibly know that you can press the Alt+Arrow Down keys simultaneously to expand the whole dropdown before selecting with arrow up and down and enter.
  • Most people won’t know this though and a lot of people use keyboards and tabbing from field to field to fill out forms.
  • Forms are a terrible annoyance of our times – nobody likes filling them in. Most of the time we won’t keep our eyes on the screen but actually look up information on papers, our credit card or read up the fine print that – of course – is not on the screen but only in the letter we got sent.
  • I have no clue how something like that works with switch access or voice recognition – probably not
  • It is scripting dependent – no JavaScript, no service

The latter is actually a reason for some companies for using this from time to time. Too many links on the same page are bad for SEO - Google considers your page not content but a sitemap and ranks it lower. That’s why some companies start offering the first two levels of navigation as links and the rest as a dropdown in this manner.

However, that still doesn’t make them a good solution, it just means that you offer far too many options to your users to begin with.

Here’s what people do to make this work: Aaron Cannon on the WebAim mailing list


A coworker and I recently devised a way to make a slightly more accessible version of the onchange dropdown navigation box. Basically, using javascript, we determine whether they are using their mouse or the keyboard to select each item in the list. If they used the mouse, it works as usual, immediately taking them to the selected page. If however the selection was made by the keyboard, we display a spinner and delay x number of seconds. If the user doesn’t make another selection within that time, they are taken to the page they selected. If they do, the clock is restarted.

I am not attacking Aaron here, he probably was asked to find a solution no matter what and did his best to find a technical way. The big scare in this for me is “determine whether they are using a mouse or keyboard”. My guess is they check for the event type, but assistive technology like voice recognition must simulate clicks without being a mouse. The other danger signal is the timer and the spinner – this complicates the interface even further (“Is this loading?”).

I simply don’t understand why we constantly try to make things work because this is what the design spec says or this is what we saw somewhere else. How about really testing it with users and see what happens then?

Tags: , , , , , ,

Share on Mastodon (needs instance)

Share on Twitter

Newsletter

Check out the Dev Digest Newsletter I write every week for WeAreDevelopers. Latest issues:

Dev Digest 146: 🥱 React fatigue 📊 Query anything with SQL 🧠 AI News

Why it may not be needed to learn React, why Deepfake masks will be a big problem and your spirit animal in body fat! 

Dev Digest 147: Free Copilot! Panel: AI and devs! RTO is bad! Pi plays!

Free Copilot! Experts discuss what AI means for devs. Don't trust containers. Mandated RTO means brain drain. And Pi plays Pokemon!

Dev Digest 148: Behind the scenes of Dev Digest & end of the year reports.

In 50 editions of Dev Digest we gave you 2081 resources. Join us in looking back and learn about all the trends this year.

Dev Digest 149: Wordpress break, VW tracking leak, ChatGPT vs Google.

Slowly starting 2025 we look at ChatGPT vs Google, Copilot vs. Cursor and the state of AI crawlers to replace web search…

Dev Digest 150: Shifting manually to AI.

Manual coding is becoming less of a skill. How can we ensure the quality of generated code? Also, unpacking an APK can get you an AI model.

My other work: