Hello, my name is Ian and I’m a grumpy, old (yet at the same time not quite middle-aged) web developer and accessibility specialist.
I have a confession to make: sometimes I don’t enjoy using the web.
I’m a fairly average person. I can usually use a mouse and keyboard without any trouble, although I have a bit of RSI that makes it uncomfortable sometimes. I can see fairly well, although I do have prescription glasses that I don’t wear as often as I should. Nothing particularly unusual for a person who has been staring at screens and hitting keys for 35 years(-ish).
I think it’s fair to say that I’m an advanced user of the world wide web, though. I’ve been using it quite a lot since the mid-nineties and I’ve been a developer on a couple of fairly big websites.
So why, when I visit sites, do they sometimes baffle me or require more than a bit of thought to use? Why do they make my computer feel like I’m using some archaic device?
Maybe I’m the only one who thinks this, but I suspect not. And if there’s nothing wrong with me, maybe there’s something wrong with the web?
I don’t think that performance, usability, accessibility, and other problems happen because people are bad designers or developers, or have bad motives, but because sometimes we make bad decisions.
In this article I want to talk about what people want from the web and how we can make decisions that support them.
The problem
Let’s get a few basic ideas out of the way.
The modern web is terrible
I’m not just talking about the aggression and misinformation on social media, or the behavior of tech giants as they shape our culture and politics. I’m talking about its design and implementation. Not all of it, of course, but some of it.
The web at the tail end of 2019 is slow, clunky, bloated and inefficient. How can it be that high-end mobile devices and even high-end desktop computers are, effectively, required to run basic modern websites?
Running the Twitter web application in a browser leads to an increase in energy and memory consumption and far more computational cycles than you might expect. When you get down to it, a site like Twitter is a text document with some images and a few buttons. Sure, there are lots of interactive elements but not a lot of complex or unique interactivity and nothing that we couldn’t have built ten years ago and had run on the hardware of the day quite adequately.
Although web accessibility has never had such a high profile as it does right now, the reality is that there are major problems with a lot of websites and applications, both small and large. While there are examples of very accessible products out there, the overall standard is, unfortunately, far below where we’d like it to be:
Four modes of activity
I think there are basically four ways that people spend the vast majority of their time using websites and web applications. They want to:
- discover new content through the use of search engines and promoted content within websites.
- be informed and entertained by consuming content in the form of text, images, videos and interactive content.
- be productive with online applications such as email, calendars, spreadsheets, and documents.
- create new content or share their content with others
Sure, there are other things that people do but other activities are predominantly combinations of these four. For example, buying a product from an online store involves discovery (finding the item) and productivity (paying for it).
The fourth mode of activity, the creation of content, is, logically, the least used of the categories. Someone will write a Tweet on Twitter once but it may be read a million times – the balance between content creation and content consumption is almost always heavily skewed towards consumption.
Greater complexity equals more mistakes
Not a startling revelation, to be sure, but we forget this all too often. Making something that is complicated is more difficult than making something that is simple. As Voltaire wrote, “common sense is quite rare” but I hope this is a truism that we can agree on.
Ultimately, the more complex something is the more difficult it is to get right. It requires more skill and more effort, and requires it at every level. The best designers in the world may find complex interactions trivial to design, but it may not be so trivial for the developer who has to implement it.
There is a trend in design towards creating simpler interfaces, however this seems to stop at the component level. Workflows are minimized as much as possible, and this is usually a good thing, but then within the same interface a custom dropdown will be used that could be perfectly adequately handled by a native dropdown select form field. This can be particularly obvious in interfaces designed primarily for mobile devices; the page layout is often more streamlined than the desktop equivalent but interacting with a custom dropdown is more difficult due to overloading of the same interaction for both scrolling and selecting an option. It’s just as easy to accidentally close the custom dropdown as make a selection which is why relying on the native version that is designed for this problem is usually a much better idea.
I’m going to tell you something that you might not want to hear: when someone is trying to read a news story, buy car insurance, or add an event to a calendar, they haven’t based their use of your site over a competitor’s on whether you have a custom form control instead of a native one.
Accessibility is easy / hard
Spend any time reading about accessibility and you’ll hear both sides. And both are right. There is a lot of accessibility that is easy. That native dropdown select form field I mentioned earlier? There’s not a lot that can go wrong with that, but making a custom version is something entirely different.
For it to be both accessible in the technical sense and usable in the broader sense you’ve not only got to think about what it will look like and how it will behave with basic interactions using a mouse or touchscreen, but also how it will work with a keyboard, a screen reader, voice input and maybe other things as well. It’s easy to say, as a designer, that it should work the same way as the native version but all that does is leave it up to the developer to figure out what the behavior should be across multiple platforms and devices. And then they have to implement it.
If only someone, such as the creators of web browsers, had done this for us already…
I don’t want to tell you that custom controls are bad, sometimes they can be the right approach, but it’s important to understand the cost that comes with them.
It’s also not the case that native is always accessible. There is an idea that native means accessible by default – if only this were true! See Scott O’Hara’s Having an open dialog article for evidence of how wrong this can be. However, starting with a native implementation is almost always going to be easier than designing and implementing everything from scratch.
So, what do people want from the web?
Based on what I’ve already talked about, I think people want a few things:
- security and responsible use of data – if you’re collecting data from people using your website you have an obligation, both legally and morally, to transport and store it safely, and to use it only for the purpose people expect it to be used.
- an accessible and usable experience – who wants an inaccessible and unusable experience?
- ease of access to their mode of activity – attempt to prioritize for each of these modes but provide ways of switching between them; when someone is consuming content they probably don’t want to be creating it, but might want to switch to that creation mode to respond to what they’ve consumed.
- performance and efficiency – I’d really prefer it if my device didn’t get hot as soon as I visit your application and it would be nice if it didn’t cost me a small fortune when I’m paying for data by the byte.
Not solutions, exactly, but some ideas
Despite my earlier assertion that I’m grumpy, I do like to end things on a positive note.
There are things that can be done to undo some of the problems on the web and for the most part they require only a change in the way we look at web design.
The hard part is not, I think, in changing our approach but in changing the view that other people have. I can assure you that it won’t be the people using your sites that will be hard to convince. They’ll just be happy that their laptop fan doesn’t turned on whenever they want to type in to a text field. However a designer may find that a product owner wants more “sizzle” or a product owner might find that a designer doesn’t feel that they are being sufficiently creative.
Designers
Sometimes designers are seen as the people who make things usable, at least on a good day, but designers are also critical to an accessible and performant web. Their decisions cascade throughout the process.
If you’re a designer, there are a few things I’d like you to think about:
- If all you have is a picture or mock up of what you want, then you haven’t finished designing yet. Document or annotate your designs with information about basic structure (relative heading levels, types of lists used, etc.), content and focus order, keyboard interactions, and anything else that you think is relevant. Not only does this provide instructions for developers but also becomes a record of your decision making when designing.
- Differentiate your work based on ease of use rather than purely the visual design – apply this to every part of the design, from individual components to full workflows.
- Make native controls your starting point – use custom controls when you have evidence of their benefits and not just because of personal preference. That doesn’t mean you can’t make changes to the styling of native controls, but keep them subtle enough that they are still familiar – no more text input fields without borders please!
- Unless you have good CSS authoring skills, talk to developers about what is possible without having to use custom or highly modified components.
- Create a complexity budget – if you really cannot live with that default control but lack the evidence to support a change, maybe indulge yourself a little bit balance it against the added complexity throughout the design and development process; by recognizing that what might be a simple visual change could add hours to development and testing you’re more likely to make the right decisions.
Developers
It easy for developers to fall in to a trap of thinking that every website is an application, to decide that they need to use React or some other framework before they even know what features they need to build.
It’s also easy to indulge your desire to learn a new framework or add a new library because this is what you find fun and interesting. But entertaining ourselves is not the job of a good developer. As much as you would expect a designer to make decisions based on what the people using your website need, developers should do the same when choosing a framework or deciding to not use a framework at all. Just maybe you really don’t need all that JavaScript.
Make sure that product owners and designers are aware of the consequences of their decisions. Developers are at the end of the creation process and sometimes they are the only people who see the full impact of what might seem to be a trivial design or feature decision. Being the last person in the assembly line doesn’t mean you have to be adversarial, but if you know that what a designer wants might mean days of extra work in scoping, implementation, and testing when a simpler alternative exists you should speak up.
Product owners
Yes, product owners are responsible for this as well. Product owners not only set the tone for the design and development process but also need to be aware of their own preferences and biases.
I distinctly remember being told that I needed to add a carousel to a home page of a site. Being the curious type, I asked what it was going to be used for. “We’re not sure yet, but we know we want a carousel” came the response. Don’t be this person.
Think carefully about features of all types. For example, tracking of users can be one of those things that causes a spike in CPU or memory usage. The person using your website doesn’t see a direct benefit, all they know is that your website seems a little slow. Be mindful of what you are going to use tracking data for. It’s not a bad thing to know how people are using your website and making improvements based on that information, but are you really doing that? Maybe you thought you would, but six months later you’re only using that complex link tracking to see how many people visit your home page. Be ruthless in cutting out the unnecessary.
Make sure that the people in your team have the skills they need for creating an accessible, usable, performant, and secure experience. Modern web design and development is difficult; there is no shame in not knowing everything. As a product owner you can make the decision to provide the time everyone involved needs to design and develop a complex feature so that it is accessible, usable, performant, and secure. It might take training, research, extra time for development and testing. Not providing the time and resources for these things is likely to result in a sub-par experience for the people using your website or application, and potentially costly redesign and development in the future.
Make sure you support communication in your team. Go read my advice to developers – if you don’t encourage that conversation about the cost of implementation you will be missing out on information that you can use to make better decisions.
In conclusion…
The web is terrible when we, as designers, developers, and product owners, make the wrong decisions. Or make the right decisions for us, as individuals, but not for the people using our websites and applications.
With a little thought and a little understanding about how our decisions affect other parts of the process it is my belief that we can make better decisions for everyone.
