Read the Tea Leaves Software and other dark arts, by Nolan Lawson

A lot of the advice we get as programmers comes with an expiration date. It’s valuable for exactly the lifespan of a particular framework or tool, and then we can safely ignore it when the next framework rolls around.

Other advice is timeless. I consider Joel Spolsky’s blog, Joel on Software, and his associated books on UI design, to fall into this category.

Even though Joel worked at Microsoft on such now-ancient products as Excel 97, his advice rings as true today as it did the last century.

Some of my favorite bits of wisdom from Joel’s blog:

• Users never read your longwinded error messages.
• Don’t rewrite your software from scratch.
• It’s always easier to write code than read code.
• Small annoyances add up to big usability failures.

One of my favorite pieces of advice from Joel is one based on empathy. Let’s call it the bathtub principle.

The bathtub principle

Joel says:

Hotel bathtubs have big grab bars. They’re just there to help disabled people, but everybody uses them anyway to get out of the bathtub. They make life easier even for the physically fit.

In the same way, Joel argues that we should design UIs for the least-capable among us – those with poor sight, or limited motor skills, or limited linguistic capacity. The reason being: if you can design a UI that your grandparent can use, then you’ve probably designed a UI that’s pleasant for you to use as well.

As a concrete example, consider the familiar “File Edit …” menu at the top of most Mac OS X windows. These menu items are “half an inch wide and a mile high,” because you can keep scrolling your mouse up past the top, and still be able to click on them.

This UI pattern is a godsend for arthritic folks. They no longer have to struggle with a stubborn mouse that just won’t point at the right spot. But even those of us who are adept with mice will appreciate this feature. It’s just easier to use.

Microsoft only belatedly realized the value of this design, and early versions of Windows forced you to position your mouse at a very precise distance from the edge of the screen in order to hit that Start button. Later versions of Windows fixed this by allowing you to jam your mouse all the way to the corner.

Offline-first

When I try to convince my peers that offline-first is a valuable design principle to embrace, I’m often faced with the response, “But people are rarely offline! Our users might spend a fraction of their time in the subway, or in an airplane, or on the road. Why should we code for an edge case?”

This perspective is badly mistaken. If you focus on the “offline” part of “offline-first,” you’re missing the point.

Offline-first is about more than just users who are literally offline – instead, it’s a corollary of the bathtub principle. If you design your UIs for people who are disconnected or only infrequently connected, you create better interfaces for everyone, including those who are online with fast connections.

That’s because, in the offline-first mindset, your primary data interaction is with the local data store, rather than a remote data store. Local data stores are always faster than remote data stores, so this leads to snappier, and therefore better, user experience. (Don’t believe the marketers trying to sell you their cloud service du jour. The speed of light happens to be a fixed constant in our universe.)

As a real-world example, consider php.net. You may notice that the autosuggestion box is ridiculously fast – much faster than we’re used to seeing with, say, Google’s autosuggestions. You type, and the words appear as quick as your keystrokes. How about that.

If you want to know what enables this otherworldly speed, it’s simple: they’re just using localStorage. When you first visit php.net, a fat 1-megabyte wad of JSON is immediately downloaded into localStorage. By the time you’ve absorbed the UI and clicked the search box, all the APIs are available locally for you to query. That’s it.

Web vs. native

Web developers should take note of this mentality. It’s a trick we’ve been using in the native app space for a long time, and at the risk of sounding smug, we’ve been doing pretty well as a result of it.

I consider myself both an Android developer and a web developer. When I write an Android app, one of the first things I think about is how to design the tables and schemas for the SQLite database. From there, I translate that vision into UI elements that the user actually interacts with, and then only later do I think about how to update the local data store with data from the server.

This is offline-first in a nutshell, and many native developers are already doing it. It’s second nature to us. It’s in our blood. To a lot of native developers I talk to, “offline-first development” is just “development.”

Given the recent success of native apps vs. web apps, this is an area where web developers could really benefit by taking a lesson from native developers. And fortunately, we no longer have to give up on the web as a platform when we give up on the notion of an ever-present Internet connection.

Today, there are a variety of tools that web developers can take advantage of to adopt an offline-first mindset. Most notably, we can take advantage of new in-browser databases like Web SQL and IndexedDB. Here’s a list of some tools that can ease this process.

Just remember: offline-first isn’t only about those who are offline. It’s about making a faster and smoother experience for everyone, regardless of whether they’re offline, intermittently online, online with a poor connection, or surfing on a cool 75 mbps FiOS connection.

Offline-first is for everyone. Offline-first is people-first.