Some lessons learned while creating a cross-device design

Recently, I released a small design project called Literate Code — an adaptive toolkit for laying out programming essays. I’ve come to a few insights in the process that I’d like to share here.

First off, on the question of mobile first vs desktop first. I find that for the best outcome, the two have to be considered concurrently. One reason for this is that what goes into the "mobification" of a page is fairly uniform. Multiple columns collapse into one; grid views become list views; sidebars get collapsed to the bottom; font sizes may scale down; images may disappear or resize; etc. There is a core of best practices associated with best-looking mobile pages. To derive your desktop design from the conventions used by the mobile design doesn’t seem like the optimal way - especially if your desktop and large screen versions feature special design elements.

How to you go about concurrent cross-device design? Start with the Information Architecture. Consider how each element of the layout represents an element in the site's overall Information Architecture. Draw a table: line each such element up against the X axis. Against the Y axis, arrange Desktop, Tablet, & Mobile. For each cell, decide (first of all) whether that element should show. If yes, consider in which way: grid vs list, number of columns, floated or collapsed to the bottom, etc.

It's a good way to approach cross–device design in a holistic, architecture–first way.

Secondly, responsive vs adaptive. When word came out about Responsive Web Design, I jumped on the bandwagon and started designing fluid pages; this meant using percentage-based widths for containers. Then two things happened: I learned about the work of Joni Korpi - which showed me how one can adapt to varying viewport widths by smart re-sizing of screen space using narrow columns. And, I had a (rather spirited) email discussion with Peter Collingridge from Enhanced Editions.

The gist of Peter's argument was: Web pages should follow established principles of print (and specifically, book) typography. In book design, line width provides the visual scaffolding upon which the layout builds; this isn't arbitrary. Certain ranges for line width yields best results in terms of readability (Robert Bringhurst recommends 45–75 characters for single-column pages, with 66 being "ideal"; and 40–50 characters for multi-column pages.)

So a "responsive" page has to be careful to stay within those boundaries - which is hard to do when that page is fluid. Line length is a design’s contract with the user, and violating that contract isn’t good.

I was convinced, and here’s why: cross-device design with static container widths (Adaptive Static Design) gives you a better way of utilizing screen real estate. Instead of resizing (responding?) pixel–by–pixel, you’re adapting column–by–column. Look at what happens to page margins as you resize a responsive page (try with the one you're reading). Text and margins resize simultaneously, right? Now try this with an adaptive page.

To appreciate this, look at what happens when you resize a "fully fluid" responsive page, one that uses percentage–based sizing in all viewport ranges. Text and margins resize simultaneously, right? When the browser shrinks, everything within it shrinks. Now try resizing an adaptive page — the one you're reading.

Now, you are creating and consuming margins as the viewport needs. When the margins on each side become consumed by the shrinking browser window, the text area gets reduced by two columns, one on each side. These released columns now create a new pair of margins for the text; this will be the next whitespace frontier to be consumed. And so it goes on: first, consume the current margins, then create a new set of margins by reducing the text area. When the viewport increases in size, the process is reversed.

This results in a more efficient use of whitespace. Why change the line width of text when there's plenty of whitespace to feed to the browser window? Seems silly. Also, the usability is better. The line does’t dance around with each move of the mouse. It changes in a split second to a different "good default". The contract between design and user is maintained. The line stays within boundaries given by optimal widths.

Basically, this allows one to use whitespace (the margins) to protect the integrity of the line of text. In turn, lines that stay constant in length or adapt column–by–column protect the integrity of the overall design. The question is then how to create several designs that each is optimal in the graphical, usability, and Information Architecture aspects, and then switch between those depending on the device (viewport width). I find this to be a compelling approach.

Reflections

One characteristic of cross-browser design is that the line between code, design, usability, and IA is blurred. Interestingly, this makes cross-browser design more Agile: you need to test more (simply because there are more devices to view the site on); iterate quicker (more code means that errors can multiply); and you need people of different skill sets collaborating. That is cool.

Update Updated the article to reflect the fact that this site is now responsive in the "adaptive static" way, and not in the "fully-fluid" way as of the time of writing.