Skip to main content

Reject Responsive Design and mess with RESS

It's been a while since I wrote a really nerdy post, in fact I'm doing a talk on Engagement at a SocITM event next week so it's about time I got back to my locked-in-a-cupboard, haven't-seen-daylight-for-days, coding roots. Some of the SocITM event is around based around mobile strategy so this seems a good topic to choose.

You've probably heard everyone talking about how mobile devices are going to take over the world and traditional "static" websites will be obsolete by next week. Of course I'm exaggerating but it's true to say that some time in the next year or so, mobile and tablet use will overtake desktop and laptop use for viewing websites.

You need to optimise your site for these devices, and there are two routes you can take.

Create lots of versions of your site using Adaptive Design (AWD)

So you create a two different versions of your site, one for laptops and fixed machines, the other for smartphones. There's two advantages to this approach, you can cut a lot of the code and images out to make it load a lot quicker and you can tailor the content for mobile devices.

Job done, right?

Well no, the drawback to this is, what do you show tablet users, the mobile or the main site? Sure you can offer them a link to the other site, but they're either getting too much or too little content and functionality for their device. So you need to create another version of your site for tablets, but tablets vary in size so you might need to create another two versions for big and small tablets. Then there's internet TVs too, the list goes on.

With device types are set to diversify over the next few years it can only become a bigger problem, so if you really want to annoy your designers and coders choose this approach.

Create one site using Responsive Design (RWD)

Responsive Design works out what size your screen is and displays the content and design to suit your device. You'll probably see something different on a small or large smartphone, small or large tablet, laptop, internet TV and so on.

So great, let's all use Responsive Design, right?

This is actually the approach many are taking now but the problem with Responsive Design is that whilst the content looks a lot better on your device, you're still loading pretty much all the content needed for the largest device. All Responsive Design does, generally, is hide the stuff you don't need and make what's left look good, so you could end up loading huge pages of stuff you don't need on a small device, which isn't good.

One Responsive Design site will keep your designers and coders happy, but if it's taking tens of seconds to view a few lines of text because you're forcing them to download a load of unnecessary content, your users won't be happy, and these are the people that really matter.

There's a third way

Yes, I know I said there were two routes, but every good story needs a twist and so do bad blog posts like this. RESS or Responsive and Server Side takes the best from AWD and RWD and combines the two.

RESS works out which content needs to be displayed for the particular device "server side" (i.e. before it's sent) like AWD and creates a page to roughly suit the device. What's downloaded to the device then uses RWD to make it look nice and keep the same look and feel across all devices.

There's not much else to say apart from if done correctly, it's the best of both worlds and should keep everyone happy.

This is the approach we're using for our new websites and next time you're planning a new site ask your designers and coders to use RESS. They'll look at you strangely to start with but thank you in the long run, and so will your users.

Comments

  1. I look forward to hear how using RESS will work out for you.

    As a general rule, I think that everything you can do at server level, gives the user a more robust experience and provides you with more meaningful data (in terms of analysing usage).

    However, it also comes at an increased (development) cost :/

    ReplyDelete

Post a Comment

Popular posts from this blog

Digital best practice checklist

This week I finished the draft of a digital best practice check-list. It's not digital strategy, in fact I'm increasingly thinking organisations don't need a digital strategy, they need a delivery strategy. My draft has check-list of seven questions and recommendations, with one overall recommendation regarding best practice for delivering digital. Ideally it would be incorporated into a wider service and information delivery strategy. Below I've omitted the bulk of the content, the reasoning behind arriving at the recommendation from the question because it's still in draft, but here are the seven questions and eight recommendations: 1. Is the council properly promoting its digital services and content, to reduce avoidable contact? Recommendation: Establish a “digital first” ethos to the promotion of services and better targeting what, when and where they're promoted. 2. Are the digital services the council offers, especially where the design and

Carl's Conundrum of Internal Influence

I'm writing this partly as a reply to an excellent piece that Carl Haggerty published about the disconnect between internal and external influence and partly due to various conversations over the past month about how to make using tools like collaboration platform  Pipeline common practice. This isn't really about Carl though, or Devon County Council, or any other council specifically, it's more a comment on the influence of digital teams in local governments, or lack of, and how to resolve this. So here's the question that prompted this piece. How can someone who's been recognised nationally for their work, first by winning the Guardian's Leadership Excellent Award and who has more recently been placed in the top 100 of the Local Government Chronicle's most influential people in local government , "sometimes feel rather isolated and disconnected to the power and influence internally". First, let's consider whether is this a problem to

Pipeline Alpha

In September 2014, officers from 25 councils met in Guildford to discuss a platform to enable collaboration across Local Government. A "Kickstarter for local government" is the missing part to Makers Project Teams , a concept to enable collaborative working across different organisations put forward by LGMakers the design and development strand of LocalGov Digital . Based on the user needs captured at the event, LGMakers created collaboration platform Pipeline and by October people from over 50 councils had signed up . Pipeline is an Alpha, a prototype set up to evaluate how a Kickstarter for councils might work. It is a working site though, and is being used as the platform it is eventually intended to be, at present without some of finer features a live offer might have. So what have I've learnt in the eight months since we launched Pipeline? There's a strong desire to collaborate  LocalGov Digital isn't a funded programme. I wrote about how much it

Superfast highways

You may have seen this slide I put together to help explain digital transformation This week we launched a new beta service to report speeding traffic. It looks fairly simple but to give you an idea of what's happening in the background I thought it might be useful to show you the before and after. So here's the before and as you can see it's completely a manual process. Stuff might be recorded electronically but it takes someone to do something seven time to make the process work and send it to the parish or the district. Here's the after What this doesn't tell you is that it's basing whether the request is for the parish or district on three questions. It's also doing a spatial look up to find the parish and returning the parish clerk details using the Modern.Gov API. Because these are already part of our platform this is data that we currently maintain, so there's no additional work to keep this up to date and we've reduced the h

Defining transformation to a wider audience

For the past month I've been putting together a paper on the next steps of digital transformation, for the organisation I work for. I'm proposing we look at two capabilities and two business areas, and if approved I'll be writing more about it. It's been a great exercise in gathering my thoughts and helping me to define digital transformation to a wider audience and how it fits into the bigger picture of service improvement. Here's some of the stuff I've learnt or had affirmed: Transformation, digital or not, starts with understanding the needs of the user through research. This should be obvious, but in local government too often I've seen "build it and they will come" approach applied. It's unlikely a commercial operation would launch a new product without first researching the market, so why would a digital service be any difference? A couple of years ago I wrote how the phrase "digital transformation" was hindering digit