Along the same lines
Loz Gray reflects on his eighteen-months working with the Guardian on their responsive site. There is so much experience here to learn from.
What stood out for me was the way they mixed static (flat) visuals with HTML prototypes during the design process:
Like anywhere else the Guardian is still, not struggling, but working its way through how best to deal with issues that arise in designing a responsive project.
Pages were produced as HTML wireframes, then went back to flat visuals1 (in InDesign8), then back in to HTML for production. As a process it’s not the best or most streamlined—even just thinking about the wireframing stage, the code I produced wasn’t production ready and didn’t adhere to the Guardian’s coding standards, so it got binned in the actual build.
This is exactly the way that we’ve been working here at Stuff and Nonsense this past year and we’ve been very successful with it. I think that success comes largely from the fact that we’re using HTML/CSS and Photoshop/Fireworks/Sketch for what they’re individually best at.
HTML/CSS aren’t good tools at all for designing ‘atmosphere’ and while I’ve said for a long time that it’s best to decide on some things like type sizes by testing in a browser before you open Photoshop, in themselves HTML and CSS are not good design tools.
I imagine that a graphics editor will likely always be better than a code editor when it comes to creative expression and implementation, but a tool that produces static visuals cannot easily help us communicate the nuances of a design, especially a responsive one. Photoshop is “bringing a knife to a gunfight.” So the answer must lie somewhere in-between.
Here’s how I explained how we work in my full-day ‘Fashionably flexible responsive web design’ workshop from a year or two ago:
Stage one
- Content inventory
- Structured content
- Design atmosphere
- Design a flexible grid
- Sketch content and functionality
- HTML design prototype (first iteration)
Stage two
- Test layouts early on real devices
- Iterate through sketches and prototype revisions
- Test regularly
- Correct only what looks broken in browsers
- HTML design prototype (second iteration)
Stage one
- Create detailed visuals based on prototypes
- Develop final responsive templates
(My full slide-deck is on Speaker Deck.)
What’s vital for us is that final trip into Photoshop in stage three, where we add that extra level of design fidelity, those added details. I still think that there’s nothing better for zooming in 800% to adjust the level of noise or texture than Photoshop or Fireworks, and that’s exactly why and when they should be used.
Loz goes on to say:
As a UX person I don’t want (or need in reality) to learn all the conventions the devs are using to output production ready code. As a designer probably even less so—you just want to play with the bits you need to.
This resonates totally with my experience. When I’m using HTML/CSS to help make a design. I’m using them because I want to reduce ‘friction.’ I want to be able to move elements around a coded page, just as I would using Fireworks. My code is likely going to be rough, and it’s allowed to be. It’s design code, not code that’s destined for a server.
That’s not always an easy thing to explain. I’ve had two instances in the last two years where this distinction between writing design code and production code has caused me problems. Last year, a very large website I designed almost went live with design code. It was only our insistence that they needed the skills of an experienced front-end developer to optimise and, in the case of our Javascript, rewrite it completely. Fortunately they did just that and the site launch was a success. The second was a large (and doomed) government project which I worked on two weeks out of four for a year.
We began the HTML/CSS aspect of this design project using a forerunner to what became Rock Hammer. The HTML and LESS (we weren’t using Sass then) files were structured so that I could find things easily and there were few dependencies to allow me to experiment freely. This worked very well until during one of my ‘off weeks’ a developer ‘helpfully’ restructured my files so that they matched the development environment. The number of HTML and LESS partials tripled meaning that I couldn’t find anything quickly and the design flow grated like someone had thrown sand in the engine. After a week of frustration, we reverted back to the original structure.
- It makes me smile every time I see someone refer to a flat or static ‘visual’ instead of a ‘comp’ or ‘PSD.’