Mobile adaptation strategy and approaches

You already have some conception of who your trying to reach – on which devices – and what your mobile content strategy looks like. You also know you need some kind of device adaptation to offer something compelling and desirable to  customers regardless of what device they’ve used to get to you. Now, what’s the best way to make this happen? Handling and managing visits from many device types isn’t new and there’re some proven approaches and techniques. ‘The year of the mobile’ has been on replay a few years running, and finally we’re now seeing significant volume of traffic – 25% and upward – coming from mobile devices for mainstream services. Along with this comes increased attention to the subject and some great new thinking and ideas on the how to best handle device adaptation.

Let’s take a look at the major strategies and get you started with the right information to make some informed decisions about what might work best for you.

It all started with server-side (vs. client-side)

Back in the good ol’ WAP days (Wireless Access Protocol) server-side really was the only choice.

Most commonly, this meant matching a device identifer (user-agent string) against an open source database of device meta-data (usually WURFL) to help make decisions based on defined device categories at the web-server layer, and then re-directing the request to the most appropriate site optimised for that device type. That’s a full server-side approach.

As browser technology improved, and JavaScript support became more ubiquitous, it became possible to adapt the rendered page with basic interface tweaks based on detected attributes/features or alternatively perform simplistic device detection and re-direction (using a simple matching algorithm, or perhaps a more complex one – both provided by based on James Pearce’s work) without tricky and expensive server-side kit.

Along came CSS3 & Responsive Web Design (RWD)

Fast forward a little and – some – browser technology improves with CSS3 becoming better supported. With this comes a new ‘Responsive web design’ approach heralded by many to be mobile web development’s messiah. In essence, this takes the client-side JavaScript approach described above and augments it with all the possibilities that CSS3 offers. This idea was popularised by Ethan Marcotte in his ALA article.

It’s a good technique, and often well liked among visual designers and front-end developers because it relies on a familar toolkit and doesn’t require server-side jiggery pokery. There are plenty of well executed examples – here’s a list curated by Ethan for .net magazine. It’s impressive, suitable and appropriate under certain circumstances, but a saviour for all it ain’t.

That is the basics covered

Nokia have done us a wonderful service by publishing an execellent wiki article that discusses in-detail pros and cons of server-side vs. client-side approaches. It’s a reasonably old article, but still absolutely relevant and covers the approaches above nicely. This is a great place to start if you need a baseline understanding of how each approach works. In fact, the full article is extremely useful as a go-to if you need to give someone the mobile tech. 101.

Each of those approaches has merit, but alone, they may not offer a broad enough solution. A big problem with RWD is that it’s still not supported on a lot of devices (notably older devices or anything running Windows Phone OS) and there can be significant performance issues caused by often heavy page-weight and additional web resource requests (usually CSS) required for this approach.

Full server-side won’t get you out of the wood either. There’s usually significant cost and ongoing maintenence required if this is deployed for large-scale sites and it’s not necessarily foolproof or 100% accurate. For it to work well, you’ll need a robust device categorisation strategy and stand-alone optimised versions of you website to point devices at. This often implies yet more operational cost in publishing and maintaining seperate sites.

That’s to say nothing of how quickly the landscape is changing as mobile devices are becoming increasingly more ubiquitous and divergent. Just as we were all breathing a communal sigh of relief at recent improvements to browser technology (from WAP/WML to HTML5) the popularity of new form factors like tablets, tethered mobile clients, IPTV etc. begin to emerge into the mainstream. We are now challenged with defining appropriate content strategy for new contexts of use and figuring out how to serve up meaningful content to end-users in this brave new world. Along with this, the margin for error is ever decreasing as customer expectation increases in-line with mobile usage trends.

Some newer thinking

Mobile First

Progressive enhancement isn’t a new idea and at it’s core it says:

‘make a baseline product or experience as compelling as possible, then improve upon this conditionally or selectively as appropriate’.

This idea is at the heart of ‘Mobile First’, a design ethos that suggests we should design first for mobile then adapt for other devices like desktop PC and so on. Mobile first is great. It’s also a fairly radical approach, especially for large organisations with mature and established web properties.

Hybrid approaches offer the best of both worlds

We’ve established earlier that putting all your eggs in a single basket may not cut it, as there are various benefits and limitations for each approach. Exploring a hybrid solution – taking the best bits of several approaches – may serve you better now and into the future. One such approach is to use server-side detection to make the first decision – separating feature phones (pointing to a basic XHTML MP website) from  smart-phones and anything else that is not a desktop PC (pointing to a HTML5 mobile site).

From here, progressive enhancement techniques can be employed to the HTML5 version only, making it possible to support standard smart-phones while also conditionally adapting – progressively enhancing – to something more meaningful for those more devices that are more powerful or have a different form factor.  Now you’ve got the best of both worlds – fast server-side detection and redirection;  a safe and reliable code-base for any device; and adaptive interface rendering to support high-end devices and new form factors.

Pushing the envelope

There are some incredibly smart folk who are working on some very slick advanced hybrid solutions. I won’t explain all the ins and outs – that’s best left to the pros (see presentations below). What’s great about these approaches is that user needs and behavioural trends (i.e. we all use mobile a lot more, and want more from it) informed the technology jiggery, and not the other way around. It’s always good to see genuine work toward making things better for humans first.

Rethinking the mobile web (Yiibu)

 Pragmatic responsive design (Yiibu)

Many, many other techniques and configurations

Jason Grigsby over at Cloud Four is currently writing a series of articles on this topic. One such article looks closely at a vast number of hybrid techniques along with his assessment of the pros and cons of each. It’s articles like this one (and people like Jason) that make the internet a nicer place – Thanks Jason. I wish I’d discovered it before writing this – such a rich source of information.

Helpful people (that I know of) on this topic

If you’re grappling with an implementation, or have some specific questions, it’s well worth dropping by the mobile-web group on Yahoo. Lot’s of mobile heavy-weights and stalwarts hang there, and I’ve found them to be an extraordinarily useful and pleasant bunch of folk.

 

3 thoughts on “Mobile adaptation strategy and approaches”

    • Knew about Mobilewood – mostly from the helmets that appeared in my twitter feed after BD2011 – but hadn’t seen futurefriendly. Nice idea, reminds me a lot of http://agilemanifesto.org/ but more hip.
      I’m chuffed to boast at least some familiarity with most of the resources listed. Looking forward to checking out the rest. Hope my head doesn’t explode though.

      Reply

Leave a comment