Anna's Rules for Humanist Web Design
- Assume users are human. If you do something to a bot that hinders its ability to use your site, you've saved yourself time cleaning up after it, and done no real harm. If you do something that hinders a legitimate, human user from using your site, you've caused her stress and anxiety, and made her view your website—and its designer—in a more negative light. Do not hinder your users. This doesn't mean you shouldn't check to make sure your site isn't being abused, but it does mean you should do this, wherever possible, in ways which are either invisible to the user or do not detract from the user experience of your website.
- Avoid CAPTCHAs. Come on, people. It's 2015. OCR technology has evolved to the point where CAPTCHAs that are human-readable are also computer-readable; Google is running so low on books to digitize that we're starting to get CAPTCHAs with archaic or downright foreign characters, mathematical equations, and house numbers gleaned from Street View; and third-party CAPTCHA providers, including Google, have started tracking users to deliver easier—and certainly computer-beatable—challenges to users they ascertain are probably human. The end result of these issues is that not only do CAPTCHAs anger users, they're also increasingly-useless as a means of human verification.
On the other hand, there are far more human-friendly ways of ascertaining whether your users are legitimate. Increasingly-common are simple maths problems which resemble the skill-testing questions of Canadian sweepstakes, which can be randomly-generated so as to hinder a bot from anticipating their format for evaluation. Text-based questions related to the specific website, community, or brand they're being used on can also act as simple trivia gateways for users which bots not specifically-programmed for your website will be unable to pass. Asking, for example, what animal appears in your company's logo—which presumably appears on each page of your website and has suitable alternative text for vision-impaired users—is both easier for most users to correctly answer and harder for generic spambots to fool than all the blurred, squiggly letters in the world. Be careful, however, to follow Rule № 2 below when designing challenge questions for your users!
In addition to common-sense challenges such as the above, HTML5 specifies an event API for detecting whether an event—such as a click—is initiated by a human or not. While this API is not universally-supported, it can be used as an additional security check in some cases to avoid having to subject your users to more intrusive—or annoying—verifications.
- Don't punish incompetency or error. I was prompted to write these rules after being IP-blocked from a website after declining to answer a CAPTCHA. Not failing to complete it—though don't punish that, either!—but simply cancelling out of the form entirely when presented with it. This is bad: bad for me, the user, but also bad for the website, since it lost a user due to a terrible security measure that assumed that only a bot wouldn't want to complete a CAPTCHA. If a user fails to complete a challenge, by all means block them from performing whatever action she was attempting, but still assume the user is human and simply made a mistake. Unless a user's actions are detrimental to your system or to other users, assume good faith. There is less harm done to you by a user failing a verification check a hundred times than the harm done to a user—and to you—by the user being blocked for doing so.
- Avoid CAPTCHAs. Come on, people. It's 2015. OCR technology has evolved to the point where CAPTCHAs that are human-readable are also computer-readable; Google is running so low on books to digitize that we're starting to get CAPTCHAs with archaic or downright foreign characters, mathematical equations, and house numbers gleaned from Street View; and third-party CAPTCHA providers, including Google, have started tracking users to deliver easier—and certainly computer-beatable—challenges to users they ascertain are probably human. The end result of these issues is that not only do CAPTCHAs anger users, they're also increasingly-useless as a means of human verification.
- Code for accessibility. This is perhaps one of the most obvious yet under-adhered-to rules for web design. You, as a web developer, want your website to be available to as many people as possible, and moreover to work for as many people as possible. Unfortunately, it is often impractical to test your code's performance on as many platforms as you should ideally support, especially for small organizations or lone-wolf developers, which hinders the ability of websites to be as open as possible. Still, an effort should be made to make your website accessible in at least three different areas:
- Accessibility for impairment. Your website should be coded to allow users with impairment access it to the fullest extent possible. Use alternative text on all non-style-related images so users with vision impairment will be able to comprehend what sighted users are looking at, and make that text meaningful: an image which includes words cannot be adequately described with the alternative text, 'Site header.' If you use CAPTCHAs or other image-related validation systems, make sure appropriate alternatives are provided, as blind users are not robots. Use semantic markup where possible to allow users with screen readers to more easily-navigate your site, and also be aware that a paragraph that is not intuitively-structured (for example, one which does not open with a sentence relevant to the rest of its content) may be skipped over by blind users who are quickly scanning the page. Many screen readers speak in excess of 300 words per minute, and document structure which is not intuitive may hinder the usability of your site.
Blindness is hardly the only impairment you should worry about as a developer, however. Colorblindness can be equally-debilitating if your site uses colors which provide adequate distinction for those with normal vision, but lack value contrast for colorblind users. If your site hosts audio content, a transcript or subtitles go a long way to making it accessible to those with hearing impairment, and are even legally-required in some jurisdictions.
- Accessibility for devices. By "devices", I mean multiple things: the computers, tablets, smartphones, and so on that people may use to view your site; the hardware peripherals such as touchscreens, keyboards, and mice they use to navigate your site; and the software devices such as web browsers which help render your site to the users. When considering software devices like screen readers or magnifiers, there's a certain amount of overlap between this point and the previous one, but the way devices influence a user's interaction with websites goes far beyond simply allowing them to do so.
If you've seen the message, 'This website is best viewed in Netscape Navigator,' you were probably online in the '90s. If you've seen the message, 'Your browser is not supported. Please download Internet Explorer,' you were probably online last Saturday. Disappointing though it is, the standards and specifications which define the way websites are displayed still aren't universal across all web browsers. While testing code across the dozens (if not hundreds) of web browsers in existence clearly isn't practical, setting a minimum standard for what proportion of web users your site needs to support is a good starting point for determining in which browsers testing is critical. If you're making changes to an existing website, don't just make guesses about what browsers people use to access the site: put those analytics to work to make sure you're prioritizing support where it's needed.
Universally coding for both desktop and mobile platforms is growing more and more feasible, and the "one site for every platform" mantra is finally becoming a reality. Code from the smallest screen to the largest, and just as with browsers, remember that not all devices of a single type provide the same experience. Smartphones and tablets come in a variety of screen sizes, and so do computer monitors: and what looks, and works, amazing on one screen may not on another. As 4K monitors begin to penetrate the PC marketplace, support for higher resolutions will inevitably become as important as the mobile revolution made support for smaller screens.
And again, don't forget peripherals. If your website displays content when a user hovers over an element, remember that that will not be as intuitive to a user on a touchscreen who will have to tap the element to view the additional content—and if that element is also a link, a touchscreen user will have to tap it twice to actually click that link. If your site utilizes keystroke detection, bear in mind that someone using a foreign keyboard layout will not necessarily provide the same keycodes as your website is expecting—which is a good reason to never make your website rely on this, really.
And finally, make no assumptions about a user's browser settings. A user may have JavaScript disabled. She may have Flash or Java disabled, or not even have either installed at all! She may have disabled third-party cookies, so be careful if your site includes cross-domain content. Wherever possible, ensure that these technologies are used to add site functionality, not be the basis of it, and make sure your site at least works—even if with reduced functionality—without them.
- Accessibility for culture. Just as testing in every browser is impractical, in most cases, localizing your website beyond your target demographic provides huge headaches for little gain. However, this is no excuse to make cultural assumptions about your users. Take the trivia-based human verification question I proposed in Rule № 1: 'What animal appears in our company logo?' It seems like a simple enough question to ask your users, but what if English is not a user's first language? It may be safe to assume a user will know—or can easily find—the name for a dog or a cat, but what if your logo contains one of these birds? Even to a native English speaker, the question may pose problems. To an American, this is metonymically a parakeet, while to a Commonwealth English-speaker, it's likely a budgie—itself a shortened form of "budgerigar". All of these terms may be alien to someone whose vernacular isn't English, so it's probably best to take "bird" as an answer, too.
- Accessibility for impairment. Your website should be coded to allow users with impairment access it to the fullest extent possible. Use alternative text on all non-style-related images so users with vision impairment will be able to comprehend what sighted users are looking at, and make that text meaningful: an image which includes words cannot be adequately described with the alternative text, 'Site header.' If you use CAPTCHAs or other image-related validation systems, make sure appropriate alternatives are provided, as blind users are not robots. Use semantic markup where possible to allow users with screen readers to more easily-navigate your site, and also be aware that a paragraph that is not intuitively-structured (for example, one which does not open with a sentence relevant to the rest of its content) may be skipped over by blind users who are quickly scanning the page. Many screen readers speak in excess of 300 words per minute, and document structure which is not intuitive may hinder the usability of your site.
- Optimize performance for good. Making your website perform well isn't just a boon for your servers, it's imperative for providing a great user experience. There are way too many specific cases to go into about how poorly-optimized sites can cause users headaches, but I'll provide a few short examples of situations to avoid.
- Scale images before you use them. A very poorly-designed website from my local government displays the municipality's heraldic achievement and banner in its header. Sadly, the developer lets the web browser do the heavy lifting of scaling the image down to size—meaning the 175px-square image is nearly 4 megabytes in size, as the image loaded into the page is natively 300 times as large in area as it is displayed to the user. This wastes bandwidth, slows loading times, and looks terrible. Don't do this.
- Account for the vertical space of your advertisements. If your site isn't terrible, it loads ads after the rest of the content. This speeds load times of what your users are actually there to see. Unfortunately, if that's as far as you go in your optimization, it also means your content will jump down the page as the advertisements load in, distracting your users and possibly causing them to click on content they didn't want to. Code your ad holders to be the height your ads are, so the page doesn't have to fully redraw itself when the ads load in.
- Use nice advertisements. I've written extensively about ethical web advertising before, and don't have much to add to it here. The one unambiguous positive is that if you use advertisements that aren't evil, you can get the makers of Adblock Plus, the most popular ad-blocking extension, to show ads on your site. This gets more eyes on your ads, which means higher revenue. Play nice, and it'll pay off.
- Scale images before you use them. A very poorly-designed website from my local government displays the municipality's heraldic achievement and banner in its header. Sadly, the developer lets the web browser do the heavy lifting of scaling the image down to size—meaning the 175px-square image is nearly 4 megabytes in size, as the image loaded into the page is natively 300 times as large in area as it is displayed to the user. This wastes bandwidth, slows loading times, and looks terrible. Don't do this.
These rules aren't meant to be the be-all and end-all of website design. However, my hope is that if anyone here is thinking of coding themselves a website, this will give them a good starting point for making their website friendly to the people who use it. Your users aren’t machines that exchange content for ad revenue, they’re humans who will get tired of your shit if you cause them problems. Design the user experience of your site with that in mind and your website will be better for it.