Notes on a responsive design project, part two: research & wireframing

Following on from the previous article on the experiences of my first responsive design project, I’m moving on to cover the research and wireframing stage with this post.

To give a little context, prior to the research, I’d already done some current site analysis/mapping with the client, proposing changes and improvements. All of the research part was done in my own time, usually in and around other aspects of the project.

Research and inspiration

There is a wealth of writing on responsive design across the web – too numerous to mention all of it – so I’ve referenced the ones that stood out below. Some of the articles appeared later in the project timeline, but as this was one huge learning curve for me, that wasn’t really an issue.

I didn’t really have a clear strategy here, it was more a sort of Pac Man approach, gobbling up anything and everything that I came across. I’d been doing some reading on the subject via my RSS feeds (remember them?) anyway, so I was aware of some of the issues and techniques, but not to any great depth.

I didn’t really have a clear strategy here, it was more a sort of Pac Man approach, gobbling up anything and everything that I came across

Through my feeds I came across Luke Wroblewski’s blog, and in particular an extract from his book, ‘Mobile First’, on organising mobile. Likewise I also discovered the ‘Responsive Web Design’ book by Ethan Marcotte – again an extract provided by A List Apart, on fluid images, proved useful.¹

Other sources of information were A List Apart itself (including this article on responsive images), and the blogs of people like Andy Clarke, Mark Boulton and Brad Frost .²

Clarke’s article and example of proportional leading was extremely helpful, as was Marcotte’s article on responsive design and his example of responsive type.

There were a few articles on 24ways that appeared around the time the wireframing started, notably the two about adaptive images: the first by Matt Wilcox (who has some newer material on this subject on his blog), and the second by Jake Archibald.

Later on in the project, a comprehensive article about address bar hiding by Scott Jehl appeared, the script from which I managed to incorporate into both wireframes and design.

Randomly – I really can’t remember how – I discovered an article by Zoe Mickley Gillenwater looking at the pros and cons of different ways of using media queries. It’s a fantastic article and helped me a lot in deciding how best to proceed on this front – embedded, overlapping, media queries was my final choice.

It should also go without saying that the work of the Boston Globe UX, design and tech teams, with their recent (when we started the project) responsive redesign, provided some serious inspiration, giving us the first large scale content site in responsive clothing.

Breakpoints

This kind of straddles the research and wireframe sections and was one of the main areas I was worried about. I couldn’t find a definative guide to breakpoints, or even how to go about identifying what breakpoints to chose before diving in.

Like many things with web projects, it could be said that this comes down to individual projects and that there is no one stop, fit all, approach to this. The conventional wisdom seemed/seems to be to design the site, then find where the pain points of the design are using something like responsivepx and then insert a breakpoint. Or at least this is what I understand it to be.

My approach was slightly different – I wanted to nail down where we were going to split the design up front, so I could keep this in mind from the start. Even now I don’t know if this was the right or wrong approach. Writing it down I feel I’ve made it sound like it was the wrong approach, however it felt right at the time. Maybe it was just my designers obsession with precision and restrictions that meant finding this out up front made me feel more comfortable.

I wanted to nail down where we were going to split the design up front, so I could keep this in mind from the start

Another reason to do it was because it was important for us to limit the breakpoints – we’d nominally decided three, based on device type: mobile, tablet/eReader, desktop/laptop – to ensure we could produce a decent solution in the time we had. But that still didn’t give me hard numbers to use.

What to do? Well, more research obviously.

What I found was that tablets seemed to start at 600px and stop around 800px wide (in portrait) and that desktops were usually 1024px plus (actually mostly 1280px plus from our clients stats). Armed with this knowledge, I initially chose 600px and 940px because I wanted tablet devices in landscape to take advantage of the extra screen width and, also, experience suggested 800px would be too cramped for a desktop style layout (although of course I still remember when 800px wide was a brave new world…).

These would later change in the design phase with the introduction of a ‘minor’ breakpoint for landscape mobile devices. At 480px I found that images started to become too large – at 16:9 ratio most images would push all other content off screen when a mobile device was in landscape orientation. Inserting this breakpoint gave me the opportunity to have lead images side by side with copy, instead of above it.

This also had a knock on effect as it meant I could adjust the 600px breakpoint to 640px, as 600px was proving too narrow for the design I wanted for tablet devices. Some devices, notably the Kindle and Samsung Galaxy Tab 7”, would get the mobile landscape style, but this actually looked better than the tablet layout squashed into 600px.

For a similar reason, the 940px breakpoint was adjusted to 960px. Honestly, I cannot fathom why I went for 940px in the first place, when 960px, being the standard width for so long, seemed the obvious choice. In addition, although not in itself a breakpoint, I decided to cap the width of the page at 1200px wide – anything more than this threw the line length and typography out too much.

Experts reading this will probably notice, and potential scoff (do people still ‘scoff’?), that I’m interchanging devices and breakpoints instead of being device agnostic, which is one of the points of responsive design. I know this is wrong, but for simplicity it’s how the project team ended up looking at this and meant it was easier to communicate to the client.

Responsive images

It’s fair to say that the thorn in the side of any responsive design solution is images. You can see in the research section of this article (above) that there are good articles on the subject, by some very clever people, and I’ve only listed a few of them.

The idea discussed with Online Solutions was to serve appropriate images to each breakpoint. Effectively that would mean serving four different sized images, with the server sizing the images on the fly. Once a cropped image was present, it would be served instead of re-cropping the same image twice.³

This was the initial idea, but would obviously need some serious testing as to the load it would place on the server. It also meant that we’d need to have large enough base files, so we wouldn’t get images scaling up. Thankfully the client owns rights to a large number of images on the site (as opposed to having to be at the mercy of content providers) so this was possible.⁴

For logos and icons, I made the decision early to use SVG. This presents a problem for some browsers, notably on Andriod 2.3.x and lower, but a surmountable one with something like modernizr.

Wireframing

The question of how to wireframe was never an issue – I wanted to use wireframes both as a prototype to test site structure/interactions and as a means to test the viability of our responsive approach. This would mean building them in HTML and, as I’ve been doing wireframes in HTML for a while (I think my first were the ones for Signpost UK back in 2008), I knew I’d be comfortable with this.⁵

My process here is very simple: a few rough sketches then straight into code. Once you’ve done a few, the need to even sketch lessens. For ease/speed I limit my browser support for wireframes to Chrome, Safari and Firefox and I use jQuery to simulate basic interactions (show/hide, changing content, users being logged in/out). Even with the addition of the responsive aspect, the process still held up and I held high hopes for being able to carry this through to the design phase.

My process here is very simple: a few rough sketches then straight into code

It might seem a bit of an odd decision to limit browser support in the wireframes, as it would be easy to create layouts that wouldn’t translate to IE, but truth be told I knew, broadly, that what I was doing was simple enough to work.

Producing responsive wireframes gave me a massive insight into what was possible with the layouts for each breakpoint. In using one HTML file for all three layouts, I was relying a lot on floats and display:inline/inline-block to move things around. Some layouts I had to ditch entirely, some I had to add a div or two and others required moving content around in the HTML. Without actually building the wireframes, I’d have never known this. That in itself made this process invaluable.

I also tend to use wireframes as a testing ground for some basic aspects of the design – because of my background as a designer, whenever I have produced wireframes I’ve always had one eye on the visual layer. At a minimum this is usually the grid, but in this case it was also image ratios and font sizes (sized in rems, a new thing for me with this project).

A fair portion of the wireframes were completed (about 75%) as flat files, with includes for repeated elements like footers and navigation. As I was going along I looked at ways to structure the HTML, with the intention being that I would then layer the design on top of the HTML by switching out the CSS.

We’d scheduled some user testing of the wireframes, but the flat HTML meant incorporating more than a few content pages would be a bit of a ballache. So I spent a very long, hard, weekend putting the completed wireframes into Textpattern.

I find Textpattern to be a simple CMS to use, both in terms of content entry and template building. It’s actually my CMS of choice and this site is built using it, however one of its key strengths, extensibility via plug-ins, can also be a weakness – it’s such a blank canvas that often you need three or four plugins just to get some things to work.⁶

As I got further down the rabbit hole, the transition to Textpattern became more and more complicated – I ended up with 19 plugins and 19 custom fields (Gerhard Lazu’s glz_custom_fields plug was invaluable). Also, whilst I find Textile brilliant (I am writing this post in Textile) it has it’s limitations, meaning the output HTML I was getting in the wireframes wasn’t always the HTML I desired.

Going through this again, I’d probably think harder about whether Textpattern was the correct CMS. It wouldn’t stop me from using a CMS to create and maintain the wireframes though – we ended up with a prototype that functioned pretty close to our intention, with 205 pieces of real content within it. Clearly this would have been impossible with just flat files.

We ended up with a prototype that functioned pretty close to our intention, with 205 pieces of real content

So much content in a prototype probably sounds like overkill, but having that amount meant I could test various scenarios and gain an understanding of how we could use the site and what might break if certain content were placed in certain places.

You can see the results of the wireframing process at at the test site I set up. Some of the functionality is broken (simulated login) and some of the more complex aspects don’t work (galleries and carousels most notably), but for the most part it still functions.

Navigation

When we signed the site structure off, we had a site that spanned three levels. In the back of my mind I knew that this might be problematic when it came to designing a navigation to work in a responsive way.

As a starting point, I used a very simple breadcrumbed list, with the current section’s/subsection’s siblings available as a dropdown list, when you hovered over it. The advantage of this was that it would work consistently across all breakpoints.

The logic beind this initial decision was that, because we had three levels, I wanted to avoid showing all three tiers as it adds a lot of visual clutter.⁷ The Telegraph’s website has to use it and it doesn’t look so great, despite the best efforts of @scottgoboom and myself. It would also clearly be a disaster on small screens.

As the links were part of a crumbtrail, they had to link to their proper destinations as well as trigger the hover. Unfortunately iOS and Android devices interpret CSS hover reveals differently. In iOS if you tap on the link that triggers the reveal, the hover item will be revealed. On Android, the link you have tapped is followed and the hover is never revealed.⁸

Additionally, in what was one of the few occasions this happened, there was some client resistence to this method as they suspected users would want to jump around the level above as well as the current level. My take, and experience elsewhere, was that the only people who do this with any regularity are internal staff, so I resisted the change for a while, finally relenting and adding a dropdown on hover to preceeding sections in the crumbtrail.

But I was still acutely aware that this wasn’t the correct solution.

In the back of my mind I had a nagging feeling I’d not be able to kill this particluar bird with one stone

As the wireframes evolved, and the prototype became larger, I tested out one or two other solutions, but in the back of my mind I had a nagging feeling I’d not be able to kill this particluar bird with one stone.

I’d always thought we’d need to display, in some form, the fact you were three levels deep. When I approached it differently, I realised that a lot of the third level would be promoted heavily on second level pages. It then became obvious this third level was not needed within the navigation and, crucially, this was the element that was blocking a decent solution.

After reading the organising mobile article I’d been leaning towards a solution for mobile that had the navigation at the bottom, anchor linked from the top. However, forcing this mobile solution onto the other breakpoints didn’t feel right.

For the largest breakpoint a traditional navigation (still only two levels deep) worked, so that just left the middle one. Here, because we were conflating the middle breakpoint with tablets, I wanted a navigation large enough to touch, but that didn’t take up too much vertical space.

The Boston Globe had an interesting approach to it’s navigation where, at very small sizes, sections and subsections are collapesed into two dropdowns (though not system dropdowns). I liked this approach and thought it would fit well for the middle breakpoint. Using three columns, I could fit in two dropdowns and a search box.

Due to the problem with CSS revealed hovers, mentioned earlier, I went with a jQuery show/hide solution. It caused me some minor issues visually with hover/selected states on tablets (iOS will show any hover state, even if you’ve closed the dropdown), but it meant it functioned correctly across all devices.

So from initially struggling to find a solution to displaying three tiers of navigation in a consistent way, across all devices, I’d gone to a tailored solution for each breakpoint. But this presented it’s own issue, because I’d need to move the navigation between the top and bottom of the HTML.

So from initially struggling to find a solution, I’d gone to a tailored solution for each breakpoint

Using jQyery to move the navigation, I’d still need a default position for it within the HTML. Here I made an assumption and that was that most of our mobile users would be operating with javascript turned on.⁹ With that in mind, and the potential (no matter how small) for desktop users to turn javascript off, I chose to keep the navigation towards the top of the HTML, moving it toward the bottom for the mobile breakpoint and then back up again for tablets and desktops.

The solution would degrade gracefully, as even if mobile users did turn javascript off, or access the site on a device without javascript capabilities, they’d still see the navigation, it would just be in it’s default position. All other visual differences would be controlled by stylesheets.

All that remained was to chose an icon for the anchor link to the navigation on mobiles. I’d looked at a few sites, and the icon that seemed to make the most sense was the list icon (because we were anchor linking to a list of navigation items), so I went with that and I’ll discuss that in a bit more detail in the next post.¹⁰

LESS

As I mentioned in my first post, it’s important to keep forcing yourself to learn when you are a contractor. One of the avenues I am always looking at is discovering new tools to work with.

I’d come across Sass when I worked with Berg on the backend for Mag+ back in 2010, but as deadlines were tight I didn’t bother to pay it much attention. I was already learning how to edit Ruby files on that project, so the strange CSS syntax seemed a bridge too far.

It’s important to keep forcing yourself to learn when you are a contractor – one of the avenues is discovering new tools to work with

Whilst completing the site structure work for this project, I’d read of Andy Clarke’s conversion to LESS and how it helped with designing in browser (and there’ll be much, much, more on that in the next post). This made me look again and using the wireframes as a testing ground I dived in. I am so glad that I did.

The benefits of using LESS are numerous, but some key ones for me were it’s math and colour functions. The math ones, particularly, were invaluable for calculating widths. The mixins were also a lifesaver for dealing with sizing in rems and vendor prefixes.

If you haven’t tried LESS yet, I’d recommend you go grab it, plus the LESS app, and take a look. Though I am far from an expert with it, I can’t envisage not using LESS from now on.

Wrap up

There’ll no doubt be some contentious parts of the above post, not least the assumption I’ve made around our mobile users. For this project, with our stated browser support list and team size, I felt that this was justified, as did Online Solutions.

In the next post I’ll try to cover the design and testing, as well as some words on the testing suite I used.