Expecting the Unexpected: Edge Cases in Web Design

By Richard Westenra Published July 16, 2014 in the Distilled, Web Design categories

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:

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:

password-req.gif


The world's worst password requirements list (via kottke.org)


Can we all agree that you should never place password restrictions that force users to create weaker passwords? Great. Moving on.

Responsive layouts

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.

Accessibility

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:

Colour-blind users:

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:

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.

Blind users:

Many blind users browse the web with screen readers, which read text to them out loud. The key part of this is ‘text’: They can’t read images (yet) and most JavaScript is out as well, so it’s critical that important information is contained in server-generated text, and that you include a description of your images in their alt-text attribute.

A useful exercise is to try to use your website with your CSS and JavaScript turned off: Is your website still easily understood? Can you still accomplish most tasks? If not, it might be time to revisit your markup to make it more semantic. It’s also important to include fallbacks where possible, especially for crucial functionality that might not always be supported (e.g. JavaScript, canvas, Flash, images, etc).

Visually-impaired 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).

Keyboard-only users:

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:

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:

Desc

See http://brokenmobile.tumblr.com and http://wtfmobileweb.com for more examples.

Edge cases to ignore

While it’s important to pay attention to potential edge cases, not all of them need to be accounted for. Often it’s simply not worth the expense to cater for fewer than 1% of your users. For instance, it’s important to ensure that websites work across all major browsers, but usually an error message with a polite upgrade request will suffice for users on older browsers and those with JavaScript turned off. As a general rule, once a browser’s market share dips below around 1%, I think it’s safe to ignore it. In our case, this means IE6 and IE7 are generally safe to ignore for our creative projects, while IE8 plods along with graceful degradation for the time being. Your mileage may vary, so check your Analytics data to find out the browser market share of visitors to your site.

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.

Conclusion

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.

This post is part of our Creative Team takeover on site with everything from visual dos and don'ts to Axl Rose. To get all the latest advice and news on creative pieces, sign up to our blog update.

Get blog posts via email