The User Experience

In my future, and maybe yours, artisans (developers, artists, writers) will make money by having other people use (read, watch, listen to) their creations. There won't be tricks, there won't be gimmicks. People will know what they are getting.

Software does not become obsolete, it only becomes more obsolete. Maintaining static material or niche services and tools is incredibly cheap. Link rot is laziness / carelessness, and project sunsets are the online bullies' way of saying you don't matter.

As more and more developers produce more and more software, quality will rule over novelty. Users will give you their time, and in turn, users will expect respect.

A Credo

I make a lot of things for the web, and I spend a lot of time using things other people have made for the web. The following are my thoughts on what respect means, when engineering and designing a web for others to use.

It is a credo: a statement of beliefs that drives how I build for the web.

Webpages

• Do not nest scrolling elements

  Particularly if the scroll-nested element is the primary focus of the page, or will have the mouse over it most of the time, or will be touched a lot on a touch device. Unless you disable scroll bounce (not recommended) and can guarantee that document.height < window.innerHeight, this means you should autoexpand any textareas that will hold more content than their min-height.

• Avoid scrolling horizontally

  Unless you are sure the user is on Firefox or Opera (the two browsers that don't have slide-to-navigate-back), everything should fit into the horizontal space alloted.

  In <code> elements, white-space: nowrap should be white-space: pre-wrap. If you have to write overflow: scroll, you're doing it wrong.

• Scrolling to navigate is faster than clicking to navigate

  Do not paginate. Do not collapse trees into click-to-reveal lists.

  You should only paginate when the DOM exceeds what a browser can reasonably handle, which, right now, is somewhere between 1,000 and 10,000 elements.

  If you paginate to elicit more page views from your readers, your soul is already lost and this page is not for you.

  For that matter, the user should never be required to perform some action that is trivial for the page to do automatically. For example, Twitter's "X new tweets". DOM manipulation while retaining scroll position is tricky, but I think Twitter's engineers can handle it.

  See also Mike Bostock on scrolling, though I think he's being a bit too permissive.

• Clicking to navigate is faster than hovering to navigate

  If you have a hover-activated dropdown that recedes on mouseout, you should pin it on mousedown.

• Cursor movement should never be used to scroll

  Adjusting a viewport as if the cursor is some magnifying glass has never been, and will never be, intuitive.

• Do not use <frameset> and <frame>

  And avoid iframes whenever possible.

• Prefer CSS over Javascript

  Use position: fixed instead of adjusting an element on scroll.

  Never animate a Javascript emulation of position: fixed.

• Do not use animation

  Animation should only be used in the most dire circumstances. For instance, to indicate to the user how to reverse an action.

  Parallax counts. Animation should never spike my CPU or make scrolling skip around. Use requestAnimationFrame, if you simply must animate.

  If you animate something as a splash on page load, or on some hover action, that animation should never again be seen for the duration of the user's session on the site. localStorage and cookies are widely supported. Use them.

• Do not manipulate focus.

  Do not automatically shift focus to an input box. If you like, intercept the keystrokes, but the user may have just pressed Ctrl+C to copy something, and refocusing kills their selection.

  Likewise with double or triple clicking, which selects words and paragraphs, respectively. Setting focus to anything else will kill the selection.

• No pop-ups

  There is no greater sign of disrespect or stupidity than a input box that pops up asking for an email address. If there was a remote chance that I might have subscribed for updates before, it has since evaporated.

  I have begun a policy of immediately closing any page that does this to me, even if the popup's close button is obvious, no matter how interesting the content may look.

• No position: fixed banners

  position: fixed is fine for a toolbar, or navigation (as long as it's small), but not for information.

  Europe, your tracking cookie warnings are ridiculous. Your legislating entities are as ignorant as ours in the U.S.A., only they move a little faster.

• Thou shalt not intercept browser (or OS) key shortcuts

  ⌘+t is sacred, as is ⌘+shift+{ and ⌘+shift+}. My browser really shouldn't let the webpage steal these shortcuts (thankfully, it doesn't let a page cancel ⌘+w), but for the page to intercept the default is just impolite. E.g., YouTube videos, most Flash things, and Gmail's compose.

• Thou shalt not hijack links

  If I ⌘+click a link, I want to open it in another tab. If I just click it, I want to open it in the current tab. Links, of all things, should behave exactly the same as if I had Javascript turned off. If your link is more than just a link, it should be a button, and that button should look like a button.

  One exception may be a logout link, which is in a tricky situation: users expect the "logout" action to look like a link, but best practices require a POST to trigger logout (to combat XSS).

• Clicking buttons should change something

  There are two different types of actions on the web; read-only actions (GET, HEAD, OPTIONS), and read/write actions (POST, PATCH, PUT, DELETE). Buttons should never be just links. If I see a button that describes itself as a link (e.g., GitHub Gists have a button: "chbrown on GitHub"), I get confused. Why is this apparent link escalated to button status? Is it going to follow his GitHub account? (Actually, it is just an over-stylized <a>.) Likewise, the "Fork on GitHub" banners on most gh-pages templates; clicking it doesn't actually do what it says it will do (fork the repo on GitHub)—it's just a normal link to the repository on GitHub.

• Responsive sites should be responsible

  If your responsive site slows down my browser, or prevents me from seeing parts of your site, recall what "responsive" means, which is something along the lines of "reacting quickly."

• Try your best to be what you look like and don't play tricks

  If a paragraph of text is not underlined, it shouldn't be a link. If you say "PDF" and use the Acrobat icon next to your link, it should go to a PDF. I will likely alt-click it, to download it, but if it's a link to another page, I'll end up with a bit of HTML that has a link to a PDF, instead of the PDF.

• Ligatures

  Don't. This isn't 1800, you aren't Johannes Gutenberg, and the web is not printed. At most enable them in a print-only stylesheet.

• Minimizing click regions

  A checkbox isn't very big. Wrap your [type=checkbox] inputs in <label></label> tags whenever they have an accompanying description.