Notes on a responsive design project, part three: design and testing

Part of the reason for writing these articles is that I wanted to give an honest account of a responsive project. With that in mind, I’ll state now: designing in the browser is hard. For me, I found it too hard.

My background, many moons ago, was as a print designer who grew up using Photoshop pre-layers and Freehand 3.1. My entire career has been spent designing in Freehand, then later Photoshop and finally Illustrator. Ditching those familiar tools caused me huge problems, which I’ll document below.

First though, I suspect some of you might have read the above and gone, “No Fireworks? Illustrator?!?!? What the…?!?!?”. No, no Fireworks. And yes, Illustrator.

A word about Illustrator and why I’ve used it extensively for web design

Both as a perminant employee and as a contractor I’ve had the privilege of working on some of the largest content websites in Europe. Why is this relevant, besides bigging myself up/point scoring? Because these sites are usually designed in teams of two or more designers, as a system, on a modular level. Again, you’re probably asking why this is relevant – the answer lies in the ability to place Illustrator files within other Illustrator files.

The set up is simple – it essentially replicates server side includes. Each module is an Illustrator file in it’s own right. Each web page is also an Illustrator file, based on an Illustrator template containing the sitewide grid. ‘Web page’ files are then populated by placing linked ‘module’ files and moving them into position – everything within the ‘web page’ file is a linked ‘module’ file.

The crucial word here is ’linked’. To get the benefits of this system the ’module’ files must be placed as linked files and not editable directly within the ’web page’ files.

If you’ve ever worked on any large scale website, you’ll know the pain of copying layers across multiple Photoshop files when something, no matter how small, changes. With this system should a ‘module’ file change, say the footer, the next time a ‘web page’ file containing this is opened the correct, newer, version of the ‘module’ file is automatically imported. No copy and paste across tens of files, it just happens.¹²

At the end of the project, when it comes to marking up and annotating the modules and pages, these ‘module’ and ‘web page’ files can be used in InDesign documents. Again, if the ‘module’ (or for that matter a ‘web page’ file) is updated, the InDesign document will automatically link to the newer version.

I’ve never really invested much time in Fireworks, so this feature may now be replicatable, but in 2001, when I first started implementing this system, it wasn’t possible in any other program bar Illustrator. All the designers I worked with at the time knew how to use Illustrator and the typographic controls offered within it were streets ahead of Photoshop.³⁴ It was a no brainer.

For non-responsive websites, this is always the preferable way for me to work.

Back to the design

It’s fair to say I am proficient in Illustrator.⁵ I’m not drawing any hyper real illustrations anytime soon, but, when the chips are down, I can bash stuff out and fairly quickly. To go from that to designing within the browser was, as I’ve stated, extremely difficult – what we’d have called in the playground at school ‘rock hard’.

The original plan, discussed with Online Solutions, was to just do flat visuals, and chuck them over the metaphotical fence. That changed because I was keen to have a go at designing in the browser and the process of sketching then diving into code had been successful for the wireframes.

I assumed, with the addition of an Illustrator ‘sketching’ phase, I could do similar for the design. I was wrong, on a grand, setting you back a couple of weeks worth of time, scale. Without trying to brag, I’m fairly competent in HTML and CSS, enough to have done front end dev on a few smaller projects, but that didn’t prepare me for this.

I found myself needlessly adding drop shadows and gradients in the CSS. And like lense flare and page curl, this was clearly wrong

The reasons were two fold. Firstly, I felt like I did the very first time I used Photoshop: I just wanted to go bonkers crazy with filters/effects. I found myself needlessly adding drop shadows and gradients in the CSS. And like lense flare and page curl, this was clearly wrong on so many levels.

Secondly, the process of writing some code, then refreshing in Safari/Chrome was jarring to me when I was used to simply seeing changes reflected ‘live’ in an Illustrator file. I’m used to broadly sketching out things at first, then working in the detail and that’s a lot of ground work to do in CSS (or at least it is for me). The whole process just felt slower.

The end result? Frankly a horrible mess. Time and again I found myself neither designing properly in Illustrator nor in the browser, just falling somewhere in between. I’d spend time in Illustrator, get halfway through a design then think, ‘this would be better to do in code’. Halfway through coding it, I’d realise I didn’t sketch it out enough and end up back in Illustrator, replicating the look of what I’d coded and trying to design on top of that. This vicious circle was usually completed by me binning the entire design and starting the cycle again.

The end result? Frankly a horrible mess. Time and again I found myself neither designing properly in Illustrator nor in the browser

After two weeks of trying this, I had to admit defeat. It was unsustainable for me to keep trying and failing and, having already extended a deadline to accomodate how much this wasn’t working, I had to bite the bullet and go back to designing in Illustrator and testing on devices using LiveView. It would mean designing three versions of pages⁶, but it felt much more comfortable.

This is not to say that things didn’t change in the browser, because some things did – once you actually see something in context, bound by the actual device screen, it can look a lot different. An example of this would be the mobile landscape breakpoint, which was inserted entirely in the design phase.

I did manage to take advantage of LESS’s colour functions (with some help from Adobe’s Kuler) and produce a solid colour palatte using them. This was converted to an Illustrator palette when I made the decision to switch back to designing in Illustrator.

It’s also important to note that all 18 templates were not fully designed in Illustrator as, once a certain point had been reached, there was enough CSS to render later HTML templates with just a few additions to the stylesheet.

The benefits of designing in the browser are not really hard to see, in fact it’s stupid to overlook them. But I’m not even sure I know what I would do differently next time to make designing in the browser work. For the time being at least, I don’t think designing in the browser is a viable way of working for me.

A baseline grid

Ah, vertical rhythm.

I’d tried once before to do a (fixed width) site with a proper baseline grid. Because I’d also done the front end dev on the project, this had been both a good test and a relatively easy process to control as I didn’t have to constantly check a third parties work. The results, to my mind, were quite good. It’s doubtful whether most people would even notice, but there was a pleasing satisfaction from knowing I’d done it ‘properly’ – my inner Muller-Brockmann was sated.⁷

The main thing that got in the way then was images – because I’d chosen to use standard picture sizes, it meant almost all images didn’t line up correctly to the baseline grid, so extra margin was required. Obviously with a responsive design, as the height of an image is constantly changing in relation to it’s width, the amount of margin required changes.

One of the things I’ve learnt is that a responsive design requires you as a designer to relinquish a certain amount of control

One of the things I’ve learnt during this process is that a responsive design requries you as a designer to relinquish a certain amount of control. There are going to be times when the design looks a bit off, but not enough to require a full on break point of it’s own. Controlling the precise spacing after images would have to be one of those things. I am sure that I could have done some fancy jQuery solution to adjust the bottom margin on the fly, but that would be massive overkill as well as massively anal.

So the upshot was that at the three resolutions I produced my designs to, plus the extra break point, everything will line up perfectly on the baseline grid. Between these points there will be instances where things line up perfectly, but mostly it will just be the typographic rhythm that will be preserved.

CSS

Once I’d reached a point in the design I was happy with, I’d begin coding them up. Most of the HTML5 markup had been defined in the wireframe stage (prior to converting to Textpattern), so it was usually a case of swapping out the CSS with the odd markup tweak.

I didn’t layer the style on top of the Textpattern wireframes because of the issues I’d encountered with the markup it was outputting. Instead, I went back to creating flat templates with an index file, containing detailed notes, linking to each one. Where necessary there were also page flow diagrams and Hype mock-ups detailing interactions.

The CSS file, created using LESS, was structured to have a general section, the mobile style, then finally the three other breakpoints. Within each breakpoint were a number of sections for typography, grid structure, shared modules and section specific styles. But as I worked my way through the eighteen templates my stylesheet became unweildy. Styles I’d previously thought to be generic were getting overwritten constantly and inheritance became a problem, though a lot of the inheritance problems I encountered were due to use of the CSS :not selector. A dark and powerful selector this is.

So once again I reached for a bullet and bit it. A hectic Saturday and Sunday were spent re-writing the stylesheet and putting my house in order.

A lot of the inheritance problems I encountered were due to use of the CSS :not selector. A dark and powerful selector this is

As with the wireframes, and for pressing time reasons (that had now become more pressing after my brief sojourn in to designing within the browser), I’d chosen to code the designs so that they worked in Chrome and Safari. Online Solutions would pick up the slack here and make things work across all browsers, adding classes as they saw fit.

From the offset, I was keen to make sure that the design was to feature progressive enhancement, but I was fairly confident the design was simple enough to work across other browsers – Opera, Firefox and IE9 rendered most things pretty well. Any CSS 3 effects that couldn’t be rendered would be stripped from the IE7/8 stylesheets and this included adding proprietary Microsoft filters. These could have been added easily, adding the declarations to my LESS mixins, but I’m a purist and I, like many others, have been abused by IE6 and am therefore bitter about it.

You can view the final designs, with notes, at the separate sub-domain I set up for this purpose.

Testing the designs

There are a lot of good articles on testing responsive design now. When I first started the project there weren’t so many, but it was obvious that a range of devices would be required. One of the articles I did come across was Brad Frost’s which provided some insight into how to build a decent testing suite without spending a fortune. Since I finished on the project, an excellent article has appeared written by someone involved in the recent BBC News responsive project. There’s a lot of good detail in there about how they test and why they have chosen the devices they have.

As I suspect most of us in the design profession are, I’m something of a gadget nerd. So when Google released a pure Android device, the Nexus One, I’d gone out and bought it straight away to see what the fuss was all about with Android. I’d also bought an iPod Touch when they first came out as I was unconvinced of the need for an iPhone (yeah, I know how daft that sounds reading it back). With an original iPhone, plus an iPhone 3Gs and my current iPhone 4s, I had the basis of a decent test suite. I just needed some diversity, so I added a Nokia Lumia 800 and a Galaxy Nexus, though the Nexus arrived late in this project.

I’d also bought an iPod Touch when they first came out as I was unconvinced of the need for an iPhone

For tablet, iPads abound in our house, so I have an original plus an iPad 2. What I didn’t have was a decent Android device, so again I went for a Google reference device, the orginal Motorola Xoom. I also have a Kindle, so did some minor testing on this. The key gap was a device in the 6/7 inch range. At the time of the project I couldnt justify the extra cost, but since then I’ve plugged that gap with a Samsung Galaxy Tab 7.0 plus and a Nexus 7.⁸

For cross browser testing on the desktop, Parallels is my tool of choice, running four versions of Windows (XP, Vista, Windows 7 and 8) at a resolution of 1280 × 1024. In addition I have a really, really old PC laptop.

The main areas of testing for desktop (as I wasn’t testing properly across browsers) was to ensure there were no differences between Chrome on the PC and Mac, to look at how fonts were behaving and finally to check for colour fidelity – the difference in quality between newer PCs and Mac panels versus older monitors and laptops is staggering and those lighter, supplemental, colours (anything past #ddd really) can be hit and miss,

With fonts I always find it interesting to see how the different operating systems render them and how they wrap. There are minor differences in the way that aliased text wraps compared to non-aliased text, as well as the differences between Mac OS rendering and Windows rendering.

Actual testing was a simple but laborious process. The workflow meant that I was creating the mobile CSS first, then tablet, then desktop, so each range of devices were laid out in front of me as I worked. I’d code a little, then go ‘round the grounds’ (to borrow a term from Radio 5 Live), refreshing and looking at each device in turn. Rinse and repeat for tablet and desktop.

There were a few things that I picked up whilst testing on actual devices. Firstly, that after a certain point, LESS seems to crap out on iOS 3.x devices. I assume this is a memory issue, but I never worked out the precise point that this would happen. Secondly, Windows Phone had a number of issues. This is probably not a surprise to anyone.

My biggest issue with Windows phone was caching – it would take several refreshes to get CSS changes to be reflected. And when I say several, I mean more than five. Sometimes I’d even have to turn the thing off and on again. If that were not irritating enough, the Lumia would take about a minute to re-connect to my WIFI network once taken out of standby mode. A few times I’d even have to do this manually. Both of these problems outweighed what is a more relevant issue – that Windows Phone 7.5 doesn’t render remote web fonts.

My biggest issue with Windows phone was caching – it would take several refreshes to get CSS changes to be reflected

Aside from the Windows Phone and iOS/LESS issues, the only real concern was Android 2.3.x not rendering SVG files, which I was using for all graphics that weren’t pictures. Thankfully this was an issue that Online Solutions could address with a simple script (or Modernizr) and PNG combination.

Towards the end of the project I came across, via Andy Clarke, a responsive design test page which I adapted for our needs. Matt Kersley has made it into a tool and prior to that Benjamin Keen made a bookmarklet of it. Small monitor users beware – I found that it was only really useful to me on a 27” monitor where you could see a fair amount of the actual comparisons together. Although this is useful, it’s not really a substitute for testing on actual devices.

Later still, Opera decided that they’d be supporting the -webkit prefixes in CSS and as a by product of this released the Opera mobile emulator, allowing you to test Opera mobile from your desktop. Whilst it will carry the usual caveat of testing on real phones and tablets, for those with limited access to a range of devices this is a useful tool.

One last thing – charging the devices. It’s a pain in the backside, but an obvious necessity. I got round it by having a micro USB cable (from my Kindle) and an iOS USB lead plugged in to my Mac at all times, supplemented by two iPad chargers (as they are higher voltage than the older iPhone chargers that look the same), one with an iOS cable, one with a micro USB cable.

When not using a set of devices, they’d be charging on rotation. Or at least that was the general plan, which often descended into rapidly swapping devices on and off the chargers – the overnight charge is your friend.

Wrap up

Hopefully the above will add a bit more insight to go alongside the scene setting and wireframing articles.

The design part was by far and away the toughest from my perspective, and its fair to say that I learned a lot whilst doing it. Obviously it wont stop me from trying responsive again – I’m actually working on another responsive project right now, with some very clever people, and there’s still so much more to learn.

I’ve got one last post in mind – summing up the lessons learned. It’s a very rough draft right now, and might not see the light of day, but I’ll try to get it to a stage I am happy with it so it can complete this little series.