Notes on a responsive design project, part one: setting the scene

Its been a while since I even attempted to write a blog post, but a recent project has kicked me out of my slumber. The project, which recently went live (though bugs both visual and technical are still being fixed), was my first real attempt at a responsive design project.

Responsive design is the current hot topic amongst web professionals, some very clever people and the self-styled ‘design internetwitterati’.¹ For those that don’t know, at it’s simplest it’s adaptive design – design that flows and looks good on any device it’s viewed on (or that’s the ideal).²

My intent is to honestly tell my experiences of how the project worked, what went wrong, what I felt was right, what I learnt and to share those experiences as a real world example of what it was like.

My intent is to honestly tell my experiences of how the project worked, what went wrong, what I felt was right, what I learnt

I’m going to split this up into a few posts, not sure quite how many yet as it depends on how much I write. There’s an outline of topics I want to cover, which I’ve started on my iPad (remember, though, kids – the iPad is only for consumption).

There’s a bit of cross over in some of the topics, which to some extent was unavoidable – I’ve tried to structure it as logically as possible. This is the first batch I’ve written up and it pretty much just sets the scene, but there will be more to follow covering the actual wireframe and design stages.

To set the scene

When you are a contractor, it becomes more important – and it’s important enough when you work for a company, with a career path in front of you – to keep pushing boundaries and to keep learning where you can, as much for your own sanity as anything else. With this project it was the suggestion that the client should be forward thinking and adopt a solution that worked across a range of devices which would, in turn, enable me to work on a responsive design.³

Let me be clear that this wasn’t a selfish recommendation – it came from the current site analysis I’d conducted earlier. One of the core purposes of the website lends itself to users accessing it on mobile devices as much, and potentially more, than desktops. Because of this, a responsive site seemed to be the right approach.

In addition the CMS and underlying back-end tech were to undergo some changes. As this was happening it was an appropriate juncture to rework the HTML (as the current site left a lot to be desired) into semantic HTML 5. It’s very rare that you get the chance to help re-architect the HTML of large site so it had to be taken with both hands.

The project team

Thankfully for this project, the team remained relatively small. There was Nic Newman, as project/product manager and main client liaison, myself as sole IA and designer and then a two man technical team at Online Solutions, Colin and Paul. On the client side, there were three or four main contacts, with two or three additional stakeholders who weren’t directly involved in the process.

The client

The client is a UK based charitable organisation. Their site gets around 40k unique users per month which they were looking to grow along with taking advantage of the boom in smart phone usage and social media.

Working with the client was a pleasure. They were extremely open, frank and usually realistic in their demands. Crucially they were also willing to actually listen to the experts that they had employed to solve their problems – after all that’s what they were paying us for, right?

That’s not to say that there have been no discussions around issues, as clearly any client relationship has compromise. However, many of us will have had meetings where clients have refused to accept an opinion or, worse, have foisted upon us some random, non-negotiable demand (e.g. “it can’t be green – my wife hates green”).⁴

Thankfully all discussions were free of any such demands. There were some push backs, some differences of opinions, but the only non-negotiable demands were usually mine…

Communication and ‘process’

Obviously it’s usually better to be present for client meetings than not, but there were occasions where this wasn’t possible – there were a few meetings that I couldn’t attend simply because I was too busy doing the actual work. In these cases it’s important to have someone you are comfortable with presenting and getting feedback for you.

For this project that fell to Nic who, as I’ve worked with him several times before, I do know and trust. The fact he understands fully what I do helps a great deal – it still staggers me how many people you come across in this industry who have no comprehension as to what actually happens, and who does what, on large web projects.

It still staggers me how many people you come across in this industry who have no comprehension as to what actually happens on large web projects

Aside from client meetings, the communication with the technical team was also crucial as we were both attempting something for the first time. Thankfully, the two Online Solutions guys, Colin and Paul, were pretty easy going and a constructive dialogue was formed from the start.

I don’t think I had a meeting with Colin or Paul where “we can’t do…” was mentioned, because discussions were ongoing and so they had usually had time to figure out how to build a feature. Engaging tech in discussions up front clearly has a massive benefit later on in the project and it’s always a surprise when teams don’t work this way.⁵

Just a small word on the ‘process’, for what it was. Online Solutions had plenty of work to do whilst I was busy doing site structures, wireframing and designing, so the way it ended up was with a hand over after I had finished – waterfall method pretty much. I’m not fully sure that that was the original plan, but that’s the way it panned out.

Browser support

I can hear you thinking, “he’s doing a responsive website and he’s talking about browser support, isn’t that at odds with the all inclusiveness of responsive?”.⁶

True, it’s strange to be talking about this, but resources and time/budget are always limited. As I said earlier, it’s physically impossible to support every browser on every platform, on every device going.⁷ So there needs to be compromise. Thankfully the client had good monthly browser statistics, so we started there.

It’s physically impossible to support every browser on every platform, on every device going. So there needs to be compromise

The first and most obvious one we wanted to look at was IE 6. It accounted for about 1.7%, so it was a fairly easy decision to strike it off the support list, given Microsoft no longer supports it, actively encourages people to upgrade from it and then announced an aggressive upgrade plan. Online Solutions and I decided that we’d serve Andy Clarke’s universal style sheet for IE 6 to IE 6 users, so they’d see all content at least.⁸

As ever that’s just one small part of the IE story. IE in total accounted for 49% of usage, but aware of the lack media query support, min/max-width and box-sizing issues with IE 8 and below⁹, we decided on fixed width for these browsers.

Next up was support for Blackberry devices, Windows mobile and Opera. Less than .08% of mobile users were accessing the site on non-Android/iOS devices. Again, this made it an easy decision to strike Blackberry support, or at least non-webkit Blackberry devices from our list.

Windows was slightly complicated because we had no stats to support its inclusion, yet Microsoft was/is making a large play in the smartphone area with Windows Phone 7, and in particular the new Lumia range. In the end we decided that it could become a factor, so IE9 on Windows Phone 7.5 would be a minimum.¹⁰

Opera was more of a grey area. We’d chosen support one of the three browsers (Windows Phone 7.5) that took up 0.8% of all mobile traffic, but not another (older Blackberry devices). In the end, we trusted that Opera’s engine would render things pretty much okay, and would investigate further in testing.

That still left us with a pretty wide target. The usual desktop suspects would be covered, whilst on mobile the minumum would be Android 2.1 stock browser, iOS 4/5 mobile Safari and Windows Phone 7.5 IE 9.¹¹

The natural progression of this topic is to discuss what devices were used to test against. This is on my list of topics and I’ll cover it in a later post.

Wrap up

A lot of the above will be granny sucking eggs territory for some, but I wanted to set the scene for the following articles, where I’ll write in more detail my actual experiences of wireframing and design on a responsive project.