Responsive Design: Beyond the Blog

Making a simple site like a blog responsive is relatively straightforward. But, how easy is it on a more complex site?

For a lot of smaller websites, responsive design can be a relatively simple case of dealing with different screen widths using media queries. For the average blog site, this may only involve adjusting a logo, shrinking the navigation, ensuring that images scale and any columns are stacked. These are usually the examples given in responsive tutorials, and talks about responsive design.

Now lets imagine a large, complex University website, such as Essex University (This site has yet to launch its fully responsive version). Not everything here is so simple.

The University of Essex Homepage

I did the user interaction design on this site before this responsive revolution really started to kick off and it features some trickier elements to deal with.

Firstly, it has a header with large ‘mega’ menus. These full width menus pull users deeper to the most important areas of the site and are seen on hover on each of the main navigation items.

University of Essex Mega Menus

Below these, there are four different slide-down panels with complex switchable forms inside, each of which uses custom jQuery to hide and show different panel elements.

University of Essex slide down panels

In addition to these main elements, the content pages often have really lengthy navigation lists to deal with. It’s a University after all, they always have a lot of information and deep Information architecture.

So how do we deal with all this in a responsive site? Gulp. We’d better start at the top.

Time for decisions

On narrow screen and tablet devices in late 2011, touch screens now prevail. Touch screens, of course, don’t really have a hover state in their user interaction repertoire. Safari on iOS may simulate hover with a double touch, but it’s often not the most usable experience.

Whilst a large hover menu can aid navigation and task orientation on a large complex website when using a desktop machine, on a narrow-screen touch screen device where there is no real hover state these aren’t such a great solution however much we may tweak them.

More pragmatically, the mega menus and slide down panels are going to be a bitch to make responsive. You have to ask yourself if they are ever going to be suitable for a narrow screen device. How much time might we spend just trying? Very quickly, {display: none;} is looking like the intelligent option for these elements.

Turn off

So, lets turn off the mega menus, and the slide down panels by hiding them. The narrow screen user can still get to everything without the mega menus of course as they were simply short cuts to enhance the usability. We can give links to the slide down panels content by creating a different custom header linking to separate pages of forms (we need these separate pages for the non-javascript user anyway). But this leads us into a bit of a dilemma.

Is it right to just hide stuff?

In a nutshell it doesn’t seem fair, or justifiable to force narrow screen users to pull down large elements which are then immediately hidden. This slows down the experience, and just doesn’t feel right.

For a site with a relatively simple header, such as Boagworld – this is not such a big issue. Two headers are used, and hidden accordingly using media queries. But they are both very small blocks of code, and share much of the same CSS. Therefore we can afford to be practical, and simply hide one or the other depending on width.

But with the Essex University example, the set of headers, their html, CSS, images and javascript add up to a lot of completely redundant data being downloaded (possibly not on the best connection in the world) and are then completely ignored.

Best practice

Maybe that’s fine, we could live with it, and no-one would ever know, (beyond complaining about the speed of the site maybe). But it doesn’t seem like good practice.

A better solutions would involve creating different headers for different width devices in separate blocks of code, and pulling them into our page as required. This means that mobile users are never forced into pulling down a lot of pointless data.

Detecting screen widths with JQuery

Whilst our media queries give us the ability to style differently depending on the screen width using CSS, JQuery allows us to pull in different blocks of html to our templates depending on screen width. This can be achieved by querying $(window).width() and using an include file function to pull in the respective html.

Designing new headers for narrow screen devices.

University of Essex mobile device header

My first efforts at making the navigation fit neatly in the narrowest devices seemed like a success to begin with. Everything was there, and it was all neat and tidy. Then someone pointed out the blindingly obvious issue. Can you see the problem? Yes, basically the entire screen is full of navigation. As a result every page looks pretty much the same, and it’s hard to know where on the site you are. Bugger.

University of Essex mobile device header using drop-downs

For the second version, I used a jQuery plugin developed by Matt Kersley which converts any <ol> or <ul> into a <select> creating a drop down navigation list to be created from a long lists of links. This provided a simple and painless way to deal with the main navigation, freeing up lots of extra space. Yay.

The same plugin was also used to deal with lengthy sub-navigation, the placement of which required users to scroll a long way down the page before they hit the actual content.

Where do we stop

We could improve things further. Even with this second solution, a lot of space is wasted with navigation. We could, for example, intelligently redesign the whole navigation area into a single Menu button which could pop up all the key navigation options. Unfortunately, in the real world there is a limit to how much effort and time can we afford to give to techniques which are still in their infancy and we have to stop somewhere.

Conclusions

Not all sites are going to be simple to make responsive. The best solutions probably won’t be those that force visitors to your site to download lots of unnecessary content which is then hidden to them. Where possible we should only deliver navigation and content that is appropriate to the device of the user whilst keeping in mind the time and cost that this could add to our projects.

Even more conclusions

As an industry we are still deciding on the best approaches, solutions, and techniques for enabling websites to scale gracefully to different screen widths. This brings new challenges as well as time and cost implications. We have to make decisions early on in the design process about the best solutions for desktop users, but also how these translate – if at all, to narrow screen device users. We can simply turn things off, but this needs to be a decision which is as well considered as whether the main navigation is horizontal or vertical. As part of our design process we should, for example, now be wireframing for narrow screen widths, and design testing the results to get an understanding of how our solutions are being received.

  • http://twitter.com/emilsundberg Emil Sundberg

    Great article. There was a lot of responsive talk on FOWD last week, but not much talk about designing complex responsive sites. The web is not just blogs.. or is it? Maybe it’s time to rethink the web and find other ways than nested pages.

    On another responsive note, where can I find the author of this article? It seems like it’s missing from the smaller screen size I’m currently using.

    • Anonymous

      Yeah we decided to drop the author details from smaller devices. Apologises for that. The guy that wrote this is @leigh on twitter. Highly recommend following him.

      • http://twitter.com/emilsundberg Emil Sundberg

        Why did you drop it? Isn’t the article author one of the more important parts of a blog post? A small “by Leigh ” after the date should fit perfectly. Otherwise I assume you wrote it since the blog contains your name. 

        • Anonymous

          We wanted to get the responsive site out quickly. That is why we dropped it. However, your suggestion would certainly work.

  • http://twitter.com/bbodien Ben Bodien

    Very poignant, Leigh! This is a topic I’ve been wrestling with on several projects. So far I’ve been having to build in responsiveness quite late in the game such as on http://authenticjobs.com, where I resorted to hiding complex jQuery menus depending on browser width. I ended up with one menu for each adaptive width range, so quite a lot of redundant markup with every serving. The use of includes is quite interesting. I’d maybe look to implement that same idea using jQuery Templates. Anyway thanks for the post – great to see it’s not just my problem.

  • Anonymous

    I’m struggling to understand the “Detecting screen widths with JQuery” section – it sounds like you’ve stripped out some HTML from the full-screen version as well and then load a different header using jQuery? This sounds like an approach with huge SEO implications.

    Is that how you’re doing it, or are you changing things around server-side?

    • Anonymous

      No you are right we are using jQuery. Why do you feel this has SEO drawbacks?

      • Anonymous

        If you have the main navigation in a Javascript-include, your internal link graph misses a number of pointers to the important sections of your site. From the above it’s not clear whether your main navigation is in the include, or just the mega-menus, but even these look to have useful links in them.

        • Anonymous

          There is an HTML version of the menu that is replaced with an alternative version with jquery. The site is still entirely accessible to google.

  • http://twitter.com/simonbingham Simon Bingham

    An interesting article. Is Matt Kersley’s jQuery plugin available for download somewhere?

    • Anonymous

      I’d also be interested in this! Having encountered the same navigation issue Leigh mentioned above.

      • http://twitter.com/simonbingham Simon Bingham

        Hi Jamie. I had a go at writing a jQuery script myself to do the job…
        http://bit.ly/sGeza7 :-)

        • Anonymous

          Cool, thanks for sharing!

  • http://www.facebook.com/people/Hesham-Mohamed-Eladawy/628227451 Hesham Mohamed Eladawy

    useful article, wish you all the success

  • Anonymous

    Thanks for talking about complex responsive design. I’m completely bought in on RD but it’s frustrating no one is discussing it outside a basic blog design.

    I’ve recently been tackling this exact problem on a site we are looking to redesign, check it out here http://crmobile.brianzmiller.com.  I’ve decided, just as you have, to hide the mega menu for small screens and force the mobile users to navigate down to their desired page (mega menu was all short links).

    I’m also experimenting with placing the nav at the bottom of the page instead of the top for mobile. If you look at app design, most have nav at the bottom. This allows your responsive mobile version to more closely resemble a native app design (which lets face it, native UI patterns are far better than responsive UI designs).

  • http://www.facebook.com/profile.php?id=1568442394 Tammy White Cornett

    We just made our IT (it.eku.edu) site responsive this week after a complete redesign and new content creation in August. Our goal with the redesign was to make it clear, concise, consistent and keep our content correct. The goal with the RWD was to make it easy on our users (students, faculty, staff) to find the IT support they need. 

  • http://twitter.com/benhayes Ben Hayes

    Yep, I think RD for big complex sites is hard, and retro-fitting it like this is even harder.  Ideally we should probably be using the mobile experience as the starting point, but like you say, sometimes it doesn’t work out that way. Looks like you are making a good effort! 

  • Anonymous

    We’ve been through the exact same things as you describe here when looking at responsive design. 

    We found that there is always a UI solution but the problems come when you start hiding large chunks of redundant code as you point out.  If you then are forced into sniffing devices and serving different content based on them – perhaps you should be looking at a mobile solution rather than a responsive solution. 

    I wrote a post recently called ‘Solving a Responsive Design Navigation Problem’ – which you might find interesting. http://blog.bleepsystems.com/2012/solving-a-responsive-design-navigation-problem/

    I present 3 simple ways to solve a navigation problem we were having. 

  • Eldee Cat

    http://www.essex.ac.uk ceased to use a responsive web design yesterday. It is now fixed width.

    • Anonymous

      Yes I noticed that. Most disappointing.

  • http://twitter.com/benhayes Ben Hayes

    I was interested to see the new Sony website: http://www.sony.com/index.php – this features an approach to converting a large drop-down navigation system for narrow (mobile) screen widths which I think works fairly well.

  • bgrggfe

    The City Council is examining a request to open a Louis Vuitton Handbags and retail shop at 11502 Middlebelt in the Livonia Crossroads shopping center on the southeast corner of Plymouth and Middlebelt roads.The council heard at a study session on Monday from Taylor Bond, president of Children’s Orchard, who wants to open a 7,500-square-foot Louis Vuitton Handbags Sale store at the site of the former Family Buggy restaurant, which was closed several years ago.

  • mike

    We’ve also been through a similar process – I like the way our designer ended up handling the options. http://www.deakin.edu.au/. Due to the large amount of content we’ve also got pages coming from a legacy CMS/dreamweaver publishing system.

  • http://iz3.nl/ Dagomar Paulides

    Just now working on a couple of responsive sites and I must say that planning is your friend. Also, make sure you have a good user experience designer at hand, it’s very easy to keep changing and tweaking.

Headscape

Boagworld