When I first wrote the responsive design article, it didn’t feel like I was doing anything especially revolutionary. If anything, it felt like I was writing down a technique that’d finally capitalize on a very, very old idea—something John Allsopp said an age ago:
As designers we need to rethink this role, to abandon control, and seek a new relationship with the page.
What made “A Dao of Web Design” feel so important is that John’s reminding us that the Web is a fluid design medium. There’s never been anything quite like it—not really. We’re designing interfaces that are effectively edgeless: they can be accessed on any kind of device, on screens of any size.
John’s also reminding us that as soon as a page is published online, we can’t predict how someone experiences it. Their screen might be wildly smaller or larger than mine, sure. But any number of factors might change the user’s experience: their network might be punishingly slow; their data plan could be stringently capped; they may use their voice to interact with my design; they may not see the screen like I do. In other words, we’ve never had any kind of control on the Web. And that lack of control can feel scary, sure—but if we approach it properly, it can be incredibly powerful.
If I had one wish for the responsive design’s next decade, it’d be for us to retire that idea of control—that idea of the page. Because I think our industry’s still learning to move beyond it.
In my experience, most organizations structure their responsive workflow around three key concepts: “mobile,” “tablet,” and “desktop.” The definition of these words are fuzzy, of course. If you ask a roomful of stakeholders to define one of these terms, you’ll get a roomful of different definitions. But when it comes time to design or build a responsive interface, organizations still use these terms in three clear, tactical ways:
- Each term’s assigned a pixel value, which usually corresponds to popular screen widths.
- Those widths are used to generate mockups for a page’s primary breakpoints.
- Once those designs are handed off to engineers, their widths are turned into media queries.
I want to be clear: this is a fine process, one that’s often a boon to busy teams with many, many competing priorities. But as a process, it does has some pretty significant limitations, which are worth noting.
First and foremost, the viewport widths we design for today are incredibly short-lived. Screens get bigger and smaller at a dizzying pace. And that means breakpoints targeting today’s screen resolutions may not age well on tomorrow’s devices.
Additionally, focusing on two or three key layouts often means that the “in-between” states don’t get as much attention from digital teams. (Filament Group’s Todd Parker calls these the “awkward teenage haircuts” of a responsive layout, and I love that term.) And as devices and viewports continue to evolve, our users will likely start seeing those previously-ignored breakpoints.
Finally, and maybe most importantly, it’s giving our teams an illusion of control. By focusing on a handful of viewport widths, I worry we’re bounding ourselves off from just how flexible the web is. We’re focusing on two or three ideal layouts, even though our design’s being viewed on an infinite number of devices and screen resolutions. In other words, we’re leaving our designs exposed to the things we didn’t consider: the devices we didn’t test on, the assistive technology we didn’t design for, the network conditions we didn’t anticipate.
What’s the alternative? Well, I don’t think there’s one easy, clear answer. But I can share one concept that’s been helpful for me: namely, seams.
A “seam” is a term I use to describe where a responsive design breaks, which happens as screens change their shape—as they get wider, narrower, shorter, or taller. In Responsive Design: Patterns & Principles, I dedicated a chunk of the final chapter to talking about seams, and how I use them to shape a responsive layout. (You can read an excerpt from the chapter on A List Apart, if you’d like.) Heck, you’ve probably seen a few seams in your own responsive work: a four-column layout becomes too cramped; two pieces of content might become too close, or overlap each other; a big, impactful headline starts crowding out the content around it. When I’m working on a responsive design, I spend most of my time searching for seams. Because once I’ve found a seam, I can change the design to cover it up: simplifying a layout; repositioning an element; refining the typography inside a component; and so on.
In recent years, I’ve realized that seams aren’t tied solely to visual layout, or to the size of a screen. Seams can appear once I start interacting with a design in ways I didn’t originally intend. If a user has a keyboard attached to their phone, is the responsive navigation bar I’m designing still usable if they’re tabbing through it? If someone’s increased their browser’s text size, does my design respect that preference? If so, is the layout still usable at increased text sizes? These are seams I need to account for, too.
This idea of seams has been incredibly useful in my work, especially as I’ve started working with more design systems. When working with a page that’s, well, not really a page, but a collection of design patterns, it can be incredibly helpful to treat those patterns as tiny responsive designs. A pattern might share some breakpoints with the broader “page,” sure—but it usually has its own needs for adaptation, its own breakpoints. Its own seams.
Paper that has edges, ratios that can be repeated. A canvas. And here’s the thing. Creating layouts on the web has to be different because there are no edges. There are no ‘pages’. We’ve made them up.
How should we do it on the web? Remember the goal is connectedness and this feeling of belonging. We do that by defining the constraint from your content. The constraint could be derived from an advertising unit, or from a thumbnail image from tons of legacy content. Whatever it is, start there. Don’t start from an imaginary page…. Embrace the fluidity of the web.
Here, Mark’s suggesting an alternative to designing from the canvas in: defining the boundaries of your page, designing a grid on that canvas, and then filling that grid with stuff. Instead, he suggests that designing from the content out can create more interconnected, more harmonious layouts.
For me, that process begins with seams. But whatever approach you use, I think much of what Mark describes—that connectedness in the midst of fluidity—is critically important to responsive design, both now and in the future.