Sketching in Code

Flexible dreams for a responsive world

Last week’s Artifact Conference focused on the challenges of designing for multiple devices simultaneously. One frequent suggestions on stage and off was rough sketching, on screen or on paper, but it’s tricky to get there. The problem is easiest to see for designers on the Web, but it applies to a wide range of digital projects.

The challenge isn’t just devices – designing for a particular device with its given constraints isn’t (usually) that hard. HTML, CSS, and JavaScript have long had tools for abstracting just far enough away from the device that sites can work even in unexpected places. The challenges come from the multiplicity. I used to spend a lot of time helping designers and clients move from “it looks like this in print” to “it probably looks like this on the Web”. That was largely about surrendering control, which was difficult enough, but this is frequently about controlling just enough to create multiple variations with a single code base.

What does a sketch of a page look like when that page morphs itself to fit differently in different containers? What does a sketch of a site look like when that site may present different content (and different types of content) to different users based on their past encounters with the site? What does a sketch of a program look like when it handles many different kinds of input in many different kinds of circumstances?

One answer – the classic answer for those of us walking around with notebooks full of dot grid paper – is multiple sketches. Breakpoints become critical as “it looks like this when…” becomes a mantra.

At the same time, though, I rarely feel comfortable creating site (or code) details on paper when I know the result will be electronic. I spent way too much time explaining how paper and screens are different to saddened designers to want to inflict that pain on my own projects. My notebooks are largely filled with words, with occasional pictures.

At Artifact, Jen Simmons suggested what felt like the clearest path forward: starting with content, adding HTML, and then adding CSS (and JavaScript if needed) to it. In some ways her approach is like taking a time machine back to 1994, using markup to create a basic page, and then lurching back to the present to annotate it with media queries, viewport-aware stylesheets (that are fun to play with), and layout options that don’t entirely exist yet.

“Sketching” in that context is very different from drawing or even calculating breakpoints that regulate the appearance of a grid. It’s going back and forth – with real content, not lorem ipsum – to layer on different pieces and see how it goes, starting narrow and growing wide. Detail can come as the design evolves. It means, to take a theme from the larger conference, designing components with their own content and styles that then fit into other pieces but don’t need to be redesigned every time they change context.

(For an appropriately sketch version of the Artifact talk, see part 1 and part 2.)

I want the same toolkit for other kinds of code. Not necessarily the visual appeal, though that can be helpful in some contexts, but the sketching. I often find myself writing placeholder code, usually as a one-off and often because I need something to fill a gap while I build tests. I haven’t yet found a way to write programs – other than borrowing other people’s code, of course – that lets me sketch out a broad outline and then fill in details. I can start with a simple set of details, and then embroider, but switching from the detail view to the view of the whole is difficult.

As much as programmers like to complain that the Web – HTML and CSS in particular – “isn’t really programming”, I suspect that in this case the Web may already have made possible an approach that I want to reach in code. We iterate over code, tweaking and testing, but mocking (to take just one example) doesn’t provide the same kind of ability to work at different granularities without sweating the details. Scaffolding sometimes let us ignore details, but the details usually lurk in unstated but strongly held opinions, waiting for us to trip over them.

The more time I spend with the Web the more I want to bring the “Web Way” to programming.

tags: , ,