In 1976, Swiss watchmakers Omega were responsible for constructing the scoreboards for the Montreal Olympics. They asked the International Olympic Committee how many digits the boards would be required to display for the gymnastic events, and were informed that three digits ought to be sufficient. No gymnast had ever achieved a perfect 10.00, and the IOC maintained that it was “not possible”.
Enter 14-year-old Romanian gymnast Nadia Comaneci. On the second day of the Montreal Games, she made her first Olympic appearance on the uneven bars. The judges agreed: Her routine was flawless. One of them approached Omega representative Daniel Baumat, who was working in the arena. “She asked what to do. I said that they could either put up 1.00 or .100 but that there was no possibility for a 10.00. Just as the federation had told me.”
Minutes later, the three-digit Omega board displayed her score: a perfect 1.00.
When creating a user interface, it’s easy to assume that everything will turn out like you expect. In my case (as a front-end developer), I have a bias towards assuming that all of our users are web-savvy digital natives with new Macbooks, 20/20 vision and fast internet, and that values provided will be similar to those used in testing. Unfortunately, reality has a habit of crushing expectations:
This is why you need to test edge use cases in your designs. pic.twitter.com/cqBToqiXlu— Bill Robbins (@billrobbins) July 9, 2014
Good UI design requires a solid understanding of your typical user’s needs and abilities, and standard (“sunny day”) use cases. If you spend your design process trying to account for every possibility then you’ll likely lose the forest for the trees, and your UI might end up looking like Microsoft’s Office support pages, which were once “so thorough, answering every obscure question, that it was hard to find the answers to the most common questions”. However it’s also important to take a step back every so often to question your assumptions. In this post I’ve tried to provide examples of when I think it’s a good idea to check your edge cases, and when to refrain from doing so.
Validating user inputs
Accounting for unexpected user input is one of the biggest headaches in web development (besides Internet Explorer). When creating any system which accepts user data, you must be prepared to receive and validate any of the following:
Null/undefined inputs (e.g. empty form fields)
Inputs at the extreme large or small ends of the expected range (e.g. My name is Hubert Blaine Wolfeschlegelsteinhausenbergerdorff, Sr. and I’m 3197 years old)
Users failing to follow the expected progress path (e.g. arriving via copy-pasted URL part-way through a multi-page checkout process)
Intentional security attacks (e.g. script injection or URL hacks)
Unit testing is a good way to avoid these kinds of problems, as it forces you to consider the ways in which your application could potentially fail. However it’s also very important not to establish rules that could frustrate legitimate users. For instance, if you must establish a maximum length for user names and addresses then be prepared to assume that your users have ridiculously long names and addresses. While we’re at it, the same goes for passwords:
Can we all agree that you should never place password restrictions that force users to create weaker passwords? Great. Moving on.
Over the last few years, it’s been great to see responsive web designs become standard. However, I’m still often asked by designers and consultants about what screen resolutions they should be targeting. My usual answer (at least, if I’m feeling argumentative) is “all of them”. While it’s true that a handful of screen sizes account for the majority of devices, there’s a great variety in the long tail. For instance, you might assume that any device less than 800 pixels wide is a touchscreen/tablet device, but maybe your customer is using a widescreen monitor rotated 90 degrees, or a 32“ TV screen running IE9 with a vertically-oriented task bar and the brightness turned up to 11. Furthermore, the number of devices on the market is enormous and growing all the time. Even if your design works across all standard screen sizes now, nobody knows what tomorrow may bring.
Hence, rather than try to target @media query rules at specific devices, it’s more practical to base them on your specific layout. That is, gradually narrow your desktop browser window and observe the natural breakpoints for your content. As long as the design flows well at every browser width/height (within reasonable limits), it should work on any device.
The classic example of edge cases in web UX is accessibility. Unless your content is of low value, it’s critical to ensure that your site is accessible to people with different needs - not only to avoid losing customers, but because it’s the right thing to do. Consider the following cases:
Nearly one in ten men are colour-blind, and 0.5% of women. Hence it’s important not to use colour differences as your sole means of visual communication (e.g. Don’t merely change an element’s colour to green or red to indicate success or failure: You must include a text message or icon as well).
The following resources are useful for checking your site’s accessibility:
Colorfilter - Simulator for live websites
Colorblindness Simulator - Simulator for uploaded images
CheckMyColours - Test color combinations of all DOM elements
Color Oracle - Simulator app for Window, Mac and Linux
Note: while you’re considering colour-blind users, spare a thought for users with low-contrast/low-resolution monitors too. Computer screens vary widely in quality, from crisp 27” iMac screens to old CRTs, projectors, and repurposed TVs. Your mid-grey text on a light grey background may look great to you, but it might be unreadable to many of your users.
A friend of mine in New Zealand has extremely limited vision in both eyes. The first time I saw her browse the web, I was floored to see her crank the browser zoom level up to 500%. The result made me wince, but it was the only way she was able to read. Visually-impaired users don’t expect your site to be pretty at maximum zoom, but they will expect to be able to use it. The good news is that if you’re doing responsive design properly then you’re already on the right track, as many of the same concepts apply (e.g. keeping your text line-lengths fluid and avoiding fixed-width absolutely-positioned layouts).
Computer mice present a problem for people with motor disabilities or those without the use of their hands. Some people use adaptations such as placing a stick in their mouth and using it to type keyboard commands. In other cases, the adaptations are more sophisticated, as in the use of special keyboards or eye-tracking software that allows people to use a computer with nothing more than eye movements. Make sure that your site does not rely on a single form of input, but can be used easily with alternative input devices. For form inputs, this may mean paying attention to the tabindex attribute.
Users on slow internet connections:
While not physically disabled, users with poor internet access are another group with a deviate web experience. When deciding whether to add a fancy retina parallax image slideshow with custom typefaces to your homepage, spare a thought for your user who’s stuck on an overloaded motel wifi connection and just needs to find your address or phone number.
And while we’re at it, let’s not forget the often woeful experience that still plagues mobile users:
I’ve been out of town over Easter and mobile broadband coverage around the UK is still, well,... crap— Gabriel Brown (@Gabeuk) April 22, 2014
Hi i’ve been on one to two bars of 3G service for the past week and let me tell you, your website sucks. Yes yours.— Winston the III (@suchwinston) April 16, 2014
Much of the mobile web is profoundly broken. And with mobile now projected to exceed 20% of global internet traffic, mobile users are barely an edge case any more: They’re a core part of your audience. As a result, there’s no longer any excuse for mobile experiences like these:
Edge cases to ignore
Focussing on the what-ifs that make up less than ten percent of your issues can quickly overtake your entire workload. To prevent this, contextualize problems within the bigger picture to determine whether they require attention. In the Distilled creative team, we constantly make cost-benefit decisions about whether a feature is worth supporting, based on how much time it would cost us versus how much it would affect the user experience.
There are also situations where catering to edge cases can leave the majority of your users in the lurch. Consider the case of MS Word’s autocorrect feature, which automatically converts “hte” to “the”. This autocorrection might fail in the tiny minority of cases where a user intended to type “hte” (e.g. in this article). However if the algorithm makes 99 out of 100 users happy, it’s probably a good result - especially if pleasing the hundredth user would frustrate the other 99.
When preparing a website for a diverse audience, question your assumptions about your user’s behaviour and reflect on your potential biases. Pay attention to the cost/benefit analysis to determine whether catering to edge cases is worth your time, but remember that, as web content creators, we have a duty to look after users with different needs.