Responsive Design: Why and how we ditched the good old select element

The standard select element as rendered in Chrome/OSX

Good things first

So why not just use it?

  • The number of selectable options we have is often counted in hundreds which makes the standard select element hard to navigate.
    Example: When specifying the unit type on an invoice line, the complete list contains hundreds of possible units. It’s not just hours, meters, liters, kilos, pounds and pieces — but also crazy units such as hogshead, syphon, ‘theoretical ton’ and ‘super bulk bag’. Tradeshift deals with global trade and compliance and we must be able to provide all these options. Standard option selectors would turn into haystacks.
    A more common example is country selectors. I often find myself struggling to select United States in most selectors, no matter how smart the sorting of options has been done. For ‘popularity reasons’ United States is often found at the top of country list. Other times Afghanistan tops the list due to alphabetical sorting. Sometimes United States is far down the list, just after United Arab Emirates. Sigh! In addition to this, keyboard search is not available on most mobile devices. This forces the user to flick through the options manually. Searching is slightly better on desktop though, but it’s still limited to searching from the first letter onwards, so typing Emirates on your keyboard is not going to give you United Arab Emirates. You get it… and we've not even started talking synonyms yet.
  • The user often has to modify the options in the lists provided.
    Example: We provide a set of default taxes that the user can apply to each invoice line item. Often, however, legislation and taxes change and we must provide the flexibility for the user to add and change the default options. We don't want the user to go to the engine room (aka settings pages) while creating an invoice. For a fluent workflow, users should update properties like these in context, else we risk the product becomes harder to use than say a word processor template. Unfortunately, the select list cannot technically be extended with inline interface for mingling with taxes. We could of course show a modal dialogue with an interface to modify the taxes list. We'd then return the user to the updated select element when editing options is done. It’s an option, but quite a UX derailment that we've seen cause confusion to less experienced users.
  • The same input value can be generated from different selection paradigms.
    Example: Payment terms can be expressed as a relative measure (e.g. Net 30 days), or an absolute value (e.g. Dec. 10th, 2013). One could imagine many solutions combining radio buttons, calendars and selects. None of them seems to provide the kind of simplicity we were aiming for. We don't want two distinct inputs to select one value.
  • Select element UI interaction makes bad use of screen estate on mobile devices.
    Example: On an iPhone 4 the select element takes up 54% of the screen space (520pt of 960pt vertically). This allows barely five options to be visible in the list. This simultaneously limits gesture space to the same 54% of the screen (Android does a slightly better job in many cases, though).
More than half the space is taken up by barely five options in the select element. Flicking through many options is a pain.
  • Hierarchical data can be a real pain to deal with using the standard select element.
    Option groups which is a part of the select element’s features, have limited usage when you deal with complex hierarchies. Country selection offering sub-selection of states is an obvious example. Standard solutions typically involve lining up multiple select elements. So interaction goes like this: first the user picks one option in one list, then closes that list, interprets the UI adding or unlocking another select element, which must then be clicked, etc. Not totally insane on a desktop browser, but on mobile the pain grows and the visual/contextual relations are easily blurred. I recently heard the previous Principal Designer at Twitter, Josh Brewer, quote someone that Mobile is a magnifying glass for your usability problems which seems right, and in this case it definitely corresponds with Tradeshift’s own usability studies.
  • Styling the select element is poorly supported.
    There’s a whole bunch of reasons for the historically limited options for styling the select element — and even more scripts/hacks exist to overcome these limitations. Bottom line is that if you want your selectable options to fit nicely into your design in various browsers you're pretty far into Hackland. And even if you go with one of these very nice styling scripts, you've not solved any of the interaction issues listed above — you may actually have added a few issues if your hack has changed the scroll wheel or touch behaviours or eliminated the standard “search feature”.

So what can we do now that the cookie cutter solution does not make the cut?

The solution

Phone size view of invoice creation: Stacking rich content layers allows the freedom in designing that we need
The indicator, here on the invoice due date field, tells the user, that the field must be populated via a picker.
User clicked the invoice due field and gets default options with current one highlighted.
The second layer presents more fine grained options for specifying an exact due date.
Focus is back, user can click or tab on…
Only four out of hundreds of possible options are listed. Search allows the user to select from the remaining hundreds.
Searching quickly brings up options from the huge list.
User picked a value and is now back at the initiating field.
Reopening the unit picker provides the newly used unit as an option in the short list.
Pickers first came up during discussions about dealing with complex selections on smaller devices. (Phone illustration: teehanlax.com)

Extended use

The invoice is here a hub for navigating and interaction/manipulation.

Implications for the overall design

--

--

--

UX consultant, UI dev. Ex-Designit, Made by Makers, 6 years at Tradeshift. Working with startups.

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Mikkel Bo Schmidt

Mikkel Bo Schmidt

UX consultant, UI dev. Ex-Designit, Made by Makers, 6 years at Tradeshift. Working with startups.

More from Medium

Internal tool platforms in 2022 — part 1

High-Rise Jeans and Recycled Plastics; Lots of New Trends Bloomed in the 1990s

OFFICE ARCHITECTURE: BEYOND CYCLE, TOWARDS EVOLUTION

Deploy meilisearch on Heroku.