A Website Owner’s Mobile Strategy Guide – Understanding Responsive Web Design and Mobile First Approach
Once upon a time in the kingdom of Interwebs, a website only had to worry about one thing: how to look good on a high-resolution screen. Certainly, content was king even in those days. But it fell to the queen to entertain the guests, and all visitors entered the castle through the great gateway of a desktop or laptop monitor. Except for those poor buggers on mobile WAP, but they had to use the back door anyway.
Fairy tales aside, it is the restless nature of technology to be ever changing. This evolution is driven by social change, incited, in turn, by technical progress. From Ogham stones to telegraph to smartphones. Perhaps in the future we’ll all be browsing the internet with our neural implants.
In the meantime, back in the present, the messages are blitzed into our eyes from a bewildering variety of media with different viewports and resolutions. Web browsers now occupy Smart TVs that barely fit in your living room as well as mobile devices that fit in the palm your hand. If your website cannot adapt, mobile visitors may get tired of pinching the screen with their fingers and surf away.
Consider bandwidth as well. All those beautiful background images take kilobytes and time to download. That’s fine for broadband, but what about those on 3G or Edge, roaming or a limited data plan?
One way to keep them on your website is to create two different versions: one for the larger screens and another for mobile. A piece of code detects the type of device and redirects the visitor to either the full or the mobile version of your site. This is a viable route, taken by the likes of Wikipedia and Facebook.
The other option is Responsive Design. It also relies on code, called Media Queries, but doesn’t use device detection, but looks at the size of your viewport instead. And it doesn’t redirect you to an alternative version of the site, but simply rearranges the layout to fit your screen. And if you resize the width of your browser, the layout changes with it even on a laptop or desktop monitor. If you’re reading this blog post on the Neo-Archaic website, the go ahead, play with it now. Unless you’re a visitor from the future, in which case – can I borrow your implant?
So is Responsive Design the same as Mobile First? Well, yes and no. The Mobile First approach uses media queries to create a website with Responsive Design. But you can also use media queries to make the website just responsive enough. The difference is in the approach.
For Mobile First, you (or your web designer) start the design process with the smallest device in mind. From there, use media queries to display the bells-and-whistles on larger devices, where they can be better appreciated. And not just two – between the smallest phone and the largest monitor screens there is an ever-growing variety of sizes. You may not be able to cater for them all, but with a series of breakpoints, you can target a few ranges of screen sizes and add another bell or extra whistle for each range. This is what they call Progressive Enhancement.
Which option should you chose? It depends. For example, Mobile First won’t work with an existing website without a complete redesign. By definition, mobile is no longer first. Adding media queries to mould it into mobile shape might work, but again – it depends. Sometimes it’s better to separate it into two sites than trying to beat it into a shape that won’t fit.
Planning is the key. Analyse your content, your goals, target audience, your best-case-scenario layout design – the one you wish to see on that big screen – and decide which approach suits you best.
And now over to you. What are the pros and cons of either approach? If you have any experience, opinions, or questions, please leave a comment.
Hi Karina,
You’re absolutely right that the less data that is served, the better, to a mobile device, and that serving sites up to clients that need to be pinched-and-zoomed is not acceptable.
However, I don’t think “Responsive Design” (or “Mobile First”) excludes server-side Device Detection. Device Detection has a role in providing vital context information to an otherwise responsive site.
There is no all-in-one-responsive shortcut to a great web site that works equally well for 2.5″ featurephones to 1920×1080 browser screens. Those things are so different that you end up designing a separate website anyway: just doing it via media query and often complex CSS codepaths.
For different experiences, you might as well actually design a new “first”: that way you can have a “Mobile First” site, a “Tablet first” site, a “Desktop first” site, and switch between them. It’s harder work because it forces you to think about your client’s needs harder, but that’s not an argument against it.
There’s a physical screensize point (around 5 inches, possibly 6) where a layout progressively enhancing from a minimum-size website upwards will simply look wrong. And the problem is that there is not much relationship between the viewport size, the nature of the device, and the physical size of the screen. And Responsive Design does not have access to the physical diagonal screensize of the device.
That means that you might see a 480×800 (or 600×1024) tablet @ 10 inches diagonal (needs a tablet layout), or you might see a 768×1280 device with a 4 inch screen (needs the mobile view). Most frameworks when trying to detect tablets look for widths over a certain size, and would serve a mobile view to one of the thousands of low-res, high screensize tablets out there.
Being responsive does not mean excluding other technologies from the development process: it merely means adapting the layout of the screen to the viewport size or orientation. For a mobile view, this still makes sense. But it makes even more sense to have a pre-filter (e.g. server-side device detection) which is doing the choosing between Desktop First (anything goes), Tablet First (don’t use hover!), and Mobile First.
The (apparently) new buzzword for this is “Adaptive Web Design”: which to me, implies a process of “Adapt, Publish, Respond”.
Adapt = Device Type, physical screen diagonal, extra media capabilities not detectable in Javascript (such as Dolby support). Pass data to “Publish” stage.
Publish = Send markup and resources (note: images need to be adapted as well). Includes data from adapt stage for RWD to use.
Respond = Media queries as usual to deal with the variety of screensizes for that device type.
Not forgetting that some devices still on sale in phone shops are still pretty bad at Javascript: Some Alcatel and ZTE devices (or their rebranded versions, such as the Orange Rio) still carry the Obigo Q03 browser: and also not forgetting that some bots will see the “noscript” version of the site in this scenario: another thing that Device Detection can help with is bot detection.
Hi Chris,
Thank you for the insightful comment. It raises some very good points about the power of gestalt between different techniques. Instead of using either front end (CSS3 media queries) or back end (server-side device detection), your approach combines the two for a more robust adaptation, and adds the ability to modify the HTML markup as well as the CSS display.
The idea of switching between three very different layout points does make sense, but can run against budgetary and time constraints, especially for smaller businesses and organisations, which often have to juggle grander aspirations with a shoestring budget.
I believe that mobile responsiveness should feature at the top of the list of priorities, but the amount of development time spent on perfecting it might have to be limited by these restrictions.
To be clear, I don’t advocate designing with just the smallest device in mind. The end-point – a fully featured desktop display – is just as important. When plotting a story, a writer considers both the beginning and the end, and not always in that order. A Mobile First design can use a similar idea, progressively enhancing from the mobile baseline to the most feature-rich goal.
The methodology you describe can be an excellent tool to achieve that result, especially the “Adapt, Publish, Respond” process.
Karina
Hi Karina,
Of course, what you say about time and budgetary constraints is true, but for many companies those figures are artificial penny pinching driven misconceptions and delusions about the development process and best practice. Also, for many companies, going mobile is a problem to be grudgingly solved with as few resources as possible rather than an opportunity for extra customer engagement.
Couple that with some web designers who themselves are unconvinced about flaws in RWD, (it’s understandable, they’re not obvious) and who would rather code breakpoints (a predictable process) than liaise with clients about user experiences (a painful process when the clients themselves probably have no idea what they want), and you’ve got a recipe for a mobile site that’s not quite a waste of money, but not far off. *sigh*
I don’t think we’ll ever solve that problem though 😉
I got that you’ve got a progressive experience between the mobile and the desktop sites: that’s definitely a better approach than throwing full sites around.
Keep up the good work, and thanks for writing the article.
Chris