Select element; the good, the bad, the very bad and the down right ugly

Reading Mikkel Bo Schmidt's article reminded me of how important the small details are, but not only that, how difficult it can be to make things better.

Mikkel rather skimped on the details of the select element so I thought I would go further.

The Good

Perhaps the most obvious good part is that everyone recognises the select element, it has been around for so long that any regular computer user will know how to interact with it, and many are even aware of how to use the keyboard to skip alphabetically.

The select element is a very compact way of displaying a range of options, it is just a single line and can even take up less width than the text of the options it contains, although this is not recommended as if you select a long option you will not be able to read it, reducing the usability.

The other important benefit is that it works on every device no matter the spec or OS*. Developing a replacement is not a simple matter, does your solution work on every device? Have you considered all OSs, does it work with a screen reader? How much bandwidth is used? Does it work with a keyboard, does it flow with the context of a form, does it support your current and future libraries, will it look dated and require refreshing the look?

I have seen plenty of "clever" new ideas which work brilliantly on the tested devices and then is completely unusable on others. For example recently the website gsmarena.com had an advert which stopped navigation on a nexus 7. There was no way of closing it as the close button was always off screen. What this clever full screen advert did was stop me from using the website. Another control which can cause issues are light boxes. Often they will appear in the middle of the screen, now if this is combined with a minimum width which is larger than the resolution of the screen then you can get impossible to close light box.

So in summary custom controls can easily fail without appropriate testing whereas something as common as a select element will have a far lower chance of irritating your users.

The Bad

Perhaps one of the worst things  about the select element is that you cannot see all of the available options without opening it. Obviously if there is a large range of options then even a custom solution will struggle to display them all at once, but if there are only 3-5 options it would be nice if you did not need to click to read them all.

The Very Bad

As mentioned one of the flaws of a select element is the iOS implementation. While Android and Windows Phone intelligently use the whole screen to present the available options iOS gives you just half the screen to scroll through the options.



Older versions of Internet Explorer have problems too if you specify a fixed width for the select element which is smaller than the width required to display the options text then it will simply be truncated. There are workarounds to this particular issue, but such a common and mature control really work better by now.

The Down Right Ugly

Perhaps the most annoying aspect is that a change to the OS can disrupt your behaviour unexpectedly. iOS 7 altered the behaviour of the select element in respect to wordy options. If your option element contains a long piece of text then it simply gets truncated with an ellipsis, rather than the previous behaviour of flowing the option on to multiple lines. There is a workaround to the issue, but as with all workarounds it can be prone to failure with updates. While I would always recommend seeing if you can keep your select options light on text and really focus on minimising the options length this behaviour is obviously unexpected and shows that relying on standard elements can lead to problems, often it is just small alignment issues, but in this particular instance it can result in the absence of text which prevents task completion.

Don't custom elements have the same problems? Of course they can, but as long as you are not using hacks or undocumented features, and testing has been performed across a wide range of devices, custom elements should be no less reliable than standard elements, but be warned replacing them does require a lot of consideration.

And Never Forget Accessibility

So you thought about adding decent keyboard interactivity into your custom select element, well that is a good start, but how about a screen reader. While iOS may struggle to display a select element well under certain circumstances it does manage to read out the text for anyone using the screen reader functionality. In fact accessibility is a great built in aspect of the select box. If you are creating a non-semantic custom version of a select element remember to use aria role element to help those accessing the element with a screen reader and keyboard.

Comments

Popular posts from this blog

IE9 Intranet compatibility mode in Intranet websites

Multi-select with shift on HTML table

Intersystems Caché performance, woe is me...