Skip to content

Web design is a study in accidental complexity. For example, while there’s no inherent aesthetic value in putting text on top of images, it’s a mainstay. Instead this kind of layering creates complexity. It constrains the text, the image, and sets up a duel for the user’s attention. Two dimensions ought to be enough.

Few habits complicate web design quite like undue layers. There are enough maligned modals to declare position: fixed forever broken — not technically, but in practice. We’ve permanently lost viewport height to a storm of sticky headers. And each layer burdens both design and code. Poor z-index.

Luckily, we have superior alternatives to every layer. Place text before or after images. Move modal content inline or extract it to a new page. Let headers remain on top. Instead of adding a loading overlay, make your site so fast that it can do without. And if the end result looks empty, redesign.

The web works best for designers, developers, and users alike when it is constrained to a single plane. We can shift the time spent on layering content to be used on improving the content itself. There is no need to compete with your own interface. Draw attention once per pixel, and keep form flat.

—   ¶

A web browser’s back button is more than a link to the previous page. It is also the navigational equivalent of undo. Going back should show the previous page, exactly as it was last time we were there. Conversely, the forward button is redo. These buttons manipulate history — they should not mutate state.

Luckily, the browser is a capable time machine by default, at least for regular web sites. It will cache content, remember form values, reset scroll bars, and do lots of other things required to preserve history. Just make sure to keep Cache-Control: no-store out of your response headers.

However, for web apps, where we make our own little world of routes and state, it’s up to us to tackle time travel. And while an implementation as polished as the browser’s may be out of scope, a little consideration goes a long way.

An expired session is not an error when going backwards. Navigating history should never clear data or result in a spinner. It should not show any sudden 4xx or 5xx errors because of a fetch. Previous form values should be restored, even if invalid. And navigating history should always work — even when offline.

—   ¶

Home screens have too many red badges. I have a new notification about enabling notifications. My email client counts three unread spam messages. The settings app has exactly one new system update. Twitter’s tab title tells of five new tweets. I follow hundreds of people — there are always new tweets.

Unread counts are everywhere in modern interface design. They are tasked with retention and growth, often implemented without restraint, and typically end up ignored by most users. But just as in computer science, when it comes to what’s unread, there are only three amounts that count: zero, one, and some.

Most unread counts should stay at zero. This is the kind of feature that works best as opt-in. Better to err on the side of not-annoying. Even if important, many prefer to check counts themselves, at set intervals. And instead of counting to one, show a dot. But not a dangerous red dot. Make it blue, or green.

If there are some notifications, show a more prominent dot or even an ellipsis. There’s probably no actionable difference between 4 or 8 or 16 unread items. However, if there are always some notifications, just remove the indicator. Nobody needs another ignored attention grabber. Leave the user alone.

—   ¶

CSS is neither code nor markup. It’s not a query language, a configuration language, or a DSL. Instead, CSS is a style sheet language — a world of its own. Yet we haphazardly import rules from other fields. It’s far from given that our ideas about globals, inheritance, and modularity apply to the world of CSS.

The closest thing to a style sheet is not found in programming but in design. More than anything a style sheet resembles a style guide — a codified design specification. For what is a style guide but a set of design rules, invariants, and exceptions? And in both cases the ultimate goal is design consistency.

Good design is consistent. There are ground rules that apply by default, with extensions and exceptions as required. In other words, cascading inheritance is not a complexity brought by CSS, but an inherent challenge for any design language. Whether expressed in *.css or *.js, whether the cascade is implicit or explicit, inheritance is a fundamental property of good design.

This perspective informs one approach to writing CSS where we embrace cascading over isolation and inheritance over repetition. We use our limited pool of developer discipline for explicit reliance on global styles, instead of expecting consistent application of a written style guide to isolated components.

In this approach, any style that can be global should be global. Local styles should rely on styles defined further up the chain. Whenever possible, prefer unitless values and percentages to absolute measures. Prefer declarative centering to explicit offsets. Prefer intrinsics like currentColor to variables. Prefer em to rem and rem to px. Prefer extensions, and never reset.

—   ¶

Software is a multiplier — it can empower users but it can’t induce behavior. Behind every successful app stands a pre-existing motivation. In other words, while you can always lead users to your landing page, you can’t make them pay. Great software makes people better at things they already want to do.

However, on the road to great software, finding an idea that serves an existing motivation is just the first step. We may know which market to fit, but how do we product? How should each feature be designed to best help the user?

An early decision is whether or not the interface should mandate a workflow. This is the difference between a wizard and a spreadsheet, or a chatbot and a text editor. Wizards constrain users: first do this, then do that. It’s the same with chatbots: answer this question and I’ll ask you the next. On the other hand, spreadsheets mandate nothing: it’s a blank canvas — an empty slate.

If you know the domain better than the user, for example if the software is an interface to your organisation, go for a wizardly approach. Be a guide, provide hints, and correct mistakes along the way — all in as few steps as possible.

On the other hand, if your idea covers a process the user knows well, be a tool. Provide the features they need, monitor usage, iterate and improve. Aim for a flat set of orthogonal but complimentary features. Provide the tools as best you can, then get out of the way. Your users already know what they want to accomplish, because technology trails incentive.

—   ¶

It is usually more productive to talk about feature scope than about priorities. While slight shifts in priority are seldom actionable, scoping requires decisions. Scoping scales products by their amount of features, and not by overall quality. Tradeoffs must be made and features must be cut — at every level of the stack.

The first step in scoping features is to get everyone on the same page. For this, words are often not enough. A shared understanding is better achieved through detailed sketches and interactive mockups. Too much code is written based on a false assumption of agreement. Make a feature obvious, then decide its scope.

The next step is to decide on which features to keep and which features to cut. Scoping is about tradeoffs. Each potential feature has an expected cost, utility, and interplay with other features. These tradeoffs should be difficult as they decide what the product will be. And iteration does not preclude planning.

When features are fleshed out and scoped in it is finally time to build. At this point there should be no fundamental questions unanswered or important thoughts unsaid. If there are split opinions it is time to disagree and commit. Any feature of uncertain scope should be pushed for re-planning in the next iteration. Plan more, code less, and always know where you’re going.

—   ¶

When designing for the web it’s easy to forget that cross-browser testing is only half the story. Variations in hardware and operating system can have just as much to say. There’s a panoply of possible platforms — all with their own inputs and outputs, quirks and constraints. Sometimes the only way to handle the «other»-slice of the hardware pie is a healthy dose of technical restraint.

For example, consider the differences between a 27″ desktop monitor with 2560 × 1440 px at 144 Hz, and a 13″ HiDPI laptop screen with 1440 × 900 px at 60 Hz. While both may be amazing displays, neither can handle any design.

When it comes to animations, the desktop monitor has the upper hand. Its high refresh rate and low DPI will render any hardware accelerated animations buttery smooth. On the other hand, a laptop with a high DPI screen and an integrated GPU will often turn non-trivial animations into spinning fans.

When it comes to text, a high DPI laptop running macOS can make any font look good. However, many of these same fonts will not be optimized for the low DPI of the desktop monitor. When combined with how Windows renders fonts the result can look a weight off, a shade off, or even like anti-aliasing is turned off.

When it comes to viewport space, the desktop has plenty. But few sites have good support for a 2560 px wide window. On a 1440 × 900 px laptop you’re left with an effective viewport height of about 800 px after the operating system and browser have taken their toll. There’s little room left for a fixed header.

Critically, you cannot get a feel for these differences in a virtual machine. You need the actual hardware. So, if resources for cross-hardware testing are limited, keep it simple. Constrain keyframes to transform and opacity. Remember that font-family: system-ui is always an option. And when it comes to viewport size, make sure to be responsive in both width and height.

—   ¶

Years ago there was a discussion on how web apps should address their users. Should the link to a user’s profile say Your profile or My profile? On the one hand, if the app is perceived as a tool — an extension of the user’s own faculties — then My profile works best. On the other hand, if the app is seen as an interface to a service, then Your profile makes more sense.

Since the preferred nomenclature will differ between users, the best solution is probably to avoid the issue altogether. Just say Profile and move on down the backlog. Where this model really shines however, is in user experience design.

There will be parts of the experience that should belong to the user (as tools) and other parts that belong to the app (as the interface). Knowing the difference makes it clear when to be traditional and when to be bold. Critically, an interface should never make unexpected changes to otherwise intuitive tools.

Scrolling in a web browser is a good example. We expect it to work consistently across sites. It is a tool intrinsic to the browsing experience. So in cases where the interface changes how scrolling works our intuition goes out the window.

A more interesting example is a browser’s viewport. While it’s fine for an interface to respond to the viewport size, resizing the viewport itself is a tool of the user. And while web apps seldom change the window size they often come close by limiting the usable viewport through modals and fixed elements.

—   ¶

It has long been difficult to write test helpers in Go because you’ve had to keep track of file names and line numbers to exclude helpers from output. This has resulted in some impressive but complicated assertion libraries. Recently, Go 1.9 improved the situation greatly by introducing the Helper method:

The new Helper method, added to both testing.T and testing.B, marks the calling function as a test helper function. When the testing package prints file and line information, it shows the location of the call to a helper function instead of a line in the helper function itself. — The Go Blog

To try this out, I wrote myself a little assertion library. And it’s great! Go can finally have test helpers that tick every box: intuitive signatures, minimal additional complexity, and accurate reporting of file names and line numbers.

package example

import (


func TestExample(t *testing.T) {
    is.Equal(t, 1, 1)
    is.Nil(t, nil)
    is.Zero(t, "")
    is.Error(t, errors.New("error"))

    is.Above(t, 1, 3)
    is.Slice(t, []int{})
    is.Element(t, []int{1, 2, 3}, 3)
    is.Substring(t, "example", "ample")

See the project page for more details.

—   ¶

The ultimate goal of frontend development, as a specialized field that sits between digital design and backend development, should be to disappear — to innovate itself out of existence. And I think we’re getting close.

In time, more frontend tasks will be done by designers, though not in code. Prototypes are reaching a fidelity comparable to the finished product. It won’t be long until design tools learn to export complete components as actual code. Picture a tool between Sketch and Unity — an integrated design environment.

When design tools export trees of connected components, developers won’t have to infer intent from static mockups. We’ll no longer need the lossy translation step called a handover. What’s left is connecting endpoints to components, components to routes, and serving the resulting app to users.

While serving the content far from simple, it’s always the same: compile, optimize, minify, compress, distribute, localize, cache, serve. These are tasks to be solved once, by a generic proxy or an external service. But what about the rest of frontend — the wiring glue between routes, components, and endpoints?

These wires are just another layer of code, another step of the stack. It’s a layer as complex as any other, but not one that warrants its own field of development. Any technique unique to frontend should change to match the rest of the stack. Practices should apply across layers, and layers are better built together.

—   ¶