Market Data / Supplier Selection /

Event Presentations / User Experience

Benchmarking / Best Practice /
Template Files / Trends and Innovation


Mobile Web Design and
Development

Best Practice Guide

Mobile Web
Design and
Development
Best Practice Guide

Published May 2014 Econsultancy London Econsultancy New York

4th Floor, Wells Point 350 7th Avenue, Suite 307
79 Wells Street New York, NY 10001
London W1T 3QN United States
All rights reserved. No part of this publication may be United Kingdom
reproduced or transmitted in any form or by any means, Telephone:
electronic or mechanical, including photocopy, recording Telephone: +1 212 971 0630
or any information storage and retrieval system, without +44 207 269 1450
prior permission in writing from the publisher.
http://econsultancy.com
Copyright © Econsultancy.com Ltd 2015 [email protected]
Contents

1. Introduction to Our Guides ............................................. 8

1.1. About Econsultancy .................................................................... 9

2. Introduction ................................................................... 10
2.1. Goals of the report ...................................................................... 12
2.2. Report structure, content and target audience ......................... 12
2.3. Mobile commerce market data .................................................. 15
2.3.1. Mobile moves centre stage for strategic planning................. 15
2.3.2. Christmas is mobile ............................................................... 16
2.3.3. Mobile browsing and purchasing growth .............................. 16
2.3.4. Key factors driving mobile usage ........................................... 18
2.3.5. Popularity of different development approaches ..................20
2.4. Glossary of key terms ................................................................. 21
2.5. Marketing challenges and opportunities ................................... 21

3. Planning Your Mobile Site ............................................. 24

3.1. Defining goals and objectives ................................................... 24
3.1.1. Example goals ........................................................................ 27
3.2. Understanding audience needs................................................. 28
3.2.1. Using research and insight .................................................... 29
3.3. Common mistakes to avoid ........................................................ 31
3.4. Device-specific patterns and behaviours .................................. 32
3.4.1. Mobile usage .......................................................................... 32
3.4.2. Access on the go ..................................................................... 32
3.4.3. Implications of touchscreen browsing .................................. 34
3.4.4. Device-specific browsing variations ...................................... 34
3.4.5. Key drivers for device differences .......................................... 35
3.5. Measurement and optimisation ................................................ 36
3.5.1. Web analytics ......................................................................... 37
3.5.2. Metrics to measure a mobile website .................................... 39
3.5.3. Mobile testing ........................................................................ 42
3.6. Marketing challenges and opportunities .................................. 43
3.7. Key technical considerations .................................................... 45
3.7.1. Technology brings businesses closer to customers ............... 45
3.7.2. Cheat sheet ............................................................................. 47
3.8. Key takeaways ........................................................................... 48

Mobile Web Design and Development Best Practice Guide Page 3

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
4. Responsive Web Design ................................................. 49
4.1. What does ‘responsive’ mean? .................................................. 50
4.2. Commercial implications and challenges ................................. 52
4.2.1. People ..................................................................................... 53
4.2.2. Research and development .................................................... 53
4.3. Technical challenges ................................................................. 54
4.3.1. Technical impact of building a responsive website ............... 55
4.3.2. Creating a responsive code base ............................................ 57
4.3.3. Common mistakes and pitfalls .............................................. 61
4.4. Implementation challenges....................................................... 62
4.4.1. Creating a responsive code base ............................................ 62
4.4.2. What do developers need to do to create a responsive
code base? .............................................................................. 69
4.4.3. Code validation ..................................................................... 80
4.4.4. Optimising responsive sites for optimal page speed .............84
4.5. Pros and cons............................................................................. 86
4.5.1. Criteria to consider ................................................................86
4.6. Example sites ............................................................................. 88
4.7. Case studies ................................................................................91
4.7.1. Schuh ...................................................................................... 91
4.7.2. Ted Baker ............................................................................... 97

5. Adaptive Web Design ..................................................... 99

5.1. What does ‘adaptive’ mean? ................................................... 100
5.2. How does an adaptive website work? ...................................... 101
5.3. Technical and commercial challenges .................................... 102
5.3.1. Decision criteria ................................................................... 102
5.3.2. Critical success factors ......................................................... 104
5.3.3. Impact on the business of going adaptive ........................... 105
5.3.4. Mitigating the risks of adaptive design ............................... 105
5.4. Implementation considerations .............................................. 106
5.4.1. Adaptive layers of progressive enhancement ...................... 106
5.4.2. Design trends ....................................................................... 106
5.4.3. Context is king ..................................................................... 107
5.4.4. Technical challenges with going adaptive ........................... 107
5.4.5. Overcoming caching challenges .......................................... 108
5.5. Key dos for adaptive design .................................................... 109
5.6. Common mistakes and pitfalls ................................................ 110
5.7. Creating an adaptive code base ................................................ 110
5.7.1. Coding for adaptive layers ................................................... 110
5.7.2. Maintaining an adaptive code base ...................................... 111

Mobile Web Design and Development Best Practice Guide Page 4

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 5.7.3. Good house-keeping ............................................................. 111
5.7.4. Code validation and quality assurance .................................112
5.7.5. Optimising for performance and page speed .......................112
5.8. Pros and cons............................................................................ 113
5.8.1. Key pros................................................................................. 113
5.8.2. Key cons ................................................................................ 113
5.9. Adaptive checklist .................................................................... 114
5.10. Example sites ............................................................................ 114
5.10.1. American Airlines .................................................................114
5.10.2. Lufthansa ..............................................................................116
5.10.3. USA Today ............................................................................ 117
5.10.4. eBags.com ............................................................................ 118
5.10.5. Epicurious .............................................................................119

6. Mobile-Specific Website Development ....................... 120

6.1. What does ‘mobile-specific’ mean? ........................................ 120
6.2. Commercial implications and challenges ................................124
6.2.1. Evaluating the commercial implication .............................. 128
6.2.2. Platform considerations ...................................................... 130
6.2.3. Design considerations .......................................................... 130
6.2.4. Creating page templates ...................................................... 132
6.3. Technical challenges ................................................................133
6.3.1. Planning the development ................................................... 133
6.3.2. Mobile site development...................................................... 134
6.4. Implementation challenges......................................................134
6.4.1. Responsive vs. mobile-specific code base ........................... 134
6.4.2. Development frameworks.................................................... 135
6.4.3. Development challenges ...................................................... 136
6.4.4. Code maintenance ............................................................... 137
6.5. Summary – key pros and cons ................................................ 138
6.5.1. Key pros................................................................................ 138
6.5.2. Key cons ............................................................................... 139
6.6. Mobile-specific site development checklist .............................139
6.7. Example sites ........................................................................... 140
6.7.1. New York Times ................................................................... 140
6.7.2. Marks & Spencer ...................................................................141
6.7.3. Harrods ................................................................................ 142
6.7.4. Ralph Lauren ....................................................................... 143

7. UX/UI Design .............................................................. 144

7.1. Importance of UX/UI skills for mobile ...................................144
7.2. Touch screen considerations ................................................... 147

Mobile Web Design and Development Best Practice Guide Page 5

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 7.2.1. How does screen size influence design? .............................. 148
7.2.2. Screwfix – an example of understanding user context ....... 152
7.3. Device-specific considerations ................................................. 154
7.3.1. Screen size ............................................................................ 154
7.3.2. Operating system (OS)......................................................... 157
7.4. Key design techniques for mobile sites....................................158
7.4.1. Define your site .................................................................... 158
7.4.2. Wireframing ......................................................................... 159
7.4.3. Advanced techniques ........................................................... 159
7.4.4. Responsive or adaptive .........................................................161
7.5. Key dos and don’ts ...................................................................163
7.5.1. UX/UI .................................................................................. 163
7.5.2. Mobile-specific HTML ......................................................... 163
7.6. Mobile designer’s toolkit .......................................................... 165
7.6.1. Software ............................................................................... 165
7.6.2. Tools ..................................................................................... 165
7.6.3. Browser plugins ................................................................... 166
7.6.4. Resources ............................................................................. 166
7.6.5. Developer resources ............................................................. 167
7.7. Examples of good and bad practice ......................................... 167
7.7.1. NHS Direct ........................................................................... 167
7.7.2. LateRooms.com ................................................................... 170
7.8. Case study ................................................................................. 172
7.8.1. An overview of the brief ....................................................... 172
7.8.2. Defining the site ................................................................... 172
7.8.3. Target audience .................................................................... 173
7.8.4. Refine the original list of features ....................................... 173
7.8.5. Wireframing and site concepts ............................................ 174
7.8.6. Evaluating and planning ...................................................... 175
7.8.7. Site visuals............................................................................ 175
7.8.8. Build ......................................................................................177
7.8.9. Finished site ..........................................................................177

8. Technical SEO for Mobile Development ..................... 178

8.1. Development implications .......................................................178
8.1.1. Responsive web design ........................................................ 178
8.1.2. Adaptive web design ............................................................ 179
8.1.3. Mobile-specific site development ........................................ 180
8.2. Indexation................................................................................. 181
8.2.1. Verifying your mobile website ............................................. 181
8.2.2. Mobile sitemap .................................................................... 181
8.2.3. User agent management ...................................................... 181

Mobile Web Design and Development Best Practice Guide Page 6

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 8.3. Ranking and clickthrough considerations .............................. 182
8.3.1. Page speed ............................................................................ 182
8.3.2. Redirects .............................................................................. 184
8.3.3. Google+ listing ..................................................................... 184
8.3.4. Mobile markup..................................................................... 185
8.3.5. Title and meta description ................................................... 185
8.4. Useful tools and resources .......................................................185
8.5. Examples of good and bad mobile SEO ...................................187
8.5.1. Good mobile SEO – Vouchercodes.co.uk ............................ 187
8.5.2. Room for improvement – Wired.co.uk ............................... 188

9. Summary and Recommendations ............................... 189

9.1. Is there a ‘right’ approach? ..................................................... 189
9.2. Key takeaways ..........................................................................193

10. Useful Resources.......................................................... 194

11. Acknowledgements ...................................................... 196
11.1. Lead author ..............................................................................196
11.2. Expert contributors ..................................................................196

Mobile Web Design and Development Best Practice Guide Page 7

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
1. Introduction to Our Guides
Econsultancy’s Best Practice Guides help organisations improve their results from digital
marketing through improved planning and execution.

They have been developed to be the definitive source for best practice on a range of online
marketing topics and aim to explain best practice for successfully implementing established
digital marketing techniques across organisations of all sizes – from micro-businesses to
enterprises.

When writing these guides, we work with respected industry thought leaders and seasoned
practitioners to contribute cutting edge content and the latest learning. These are the people who
live and breathe the subject and are genuinely passionate about sharing their experience and
knowledge. You will find a list of the authors in the appendices as well as in the intro to each
chapter.

In particular, the reports are developed to aid the following people:

 Digital marketing professionals. Individuals in digital marketing teams who are actively
involved in improving results from online marketing activities.
 Specialists. Those involved with specific digital channels such as mobile who need to
understand more about integration with other digital marketing activities.
 Managers of digital marketing. Those in a team responsible for planning and controlling
digital marketing.
 Marketing managers and team members. Anyone responsible for traditional marketing
who wants to understand the issues involved with successful planning, implementation and
integration of digital marketing activities.

Key features of our guides:

 Comprehensive. They cover all aspects needed for success in one place as well as
referencing other in-depth sources across different portals, forums, blogs, whitepapers and
books.
 Accessible. Content is segmented to help readers navigate and assimilate relevant content.
 In-depth. Topics are covered in sufficient depth to successfully implement suggestions.
 Practical. They explain how to implement techniques and provide key success factors that
can be applied straightaway.
 Improvement-focused. Our guides explain current strategies, tell you how to refine them
and will then help you implement an improved approach.
 Cutting edge. The latest best practice advice is incorporated and potential areas of focus for
the future are highlighted.

Econsultancy’s Best Practice Guides are updated on a regular basis, so the information contained
within is recent and valid at the time of publication. Send any questions or comments to
[email protected].

Mobile Web Design and Development Best Practice Guide Page 8

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
1.1. About Econsultancy
Econsultancy’s mission is to help its customers achieve excellence in digital business, marketing
and ecommerce through research, training and events.

Founded in 1999, Econsultancy has offices in New York, London and Singapore.

Econsultancy is used by over 600,000 professionals every month. Subscribers get access to
research, market data, best practice guides, case studies and elearning – all focused on helping
individuals and enterprises get better at digital.

The subscription is supported by digital transformation services including digital capability

programmes, training courses, skills assessments and audits. We train and develop thousands of
professionals each year as well as running events and networking that bring the Econsultancy
community together around the world.

Subscribe to Econsultancy today to accelerate your journey to digital excellence.

Call us to find out more:

 New York: +1 212 971 0630

 London: +44 207 269 1450
 Singapore: +65 6809 2088

Further reading
Mobile Marketing and Commerce Report
https://econsultancy.com/reports/mobile-marketing-and-commerce-report

Mobile Sophistication and Strategy Report

https://econsultancy.com/reports/mobile-sophistication-and-strategy

Mobile Commerce Compendium

https://econsultancy.com/reports/mobile-commerce-compendium

SEO Best Practice – Mobile, Local and International SEO

https://econsultancy.com/reports/seo-best-practice-mobile-local-and-international-seo

Mobile Statistics
https://econsultancy.com/reports/mobile-statistics

Mobile Web Design and Development Best Practice Guide Page 9

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
2. Introduction
Contributor
This section was written by James Gurd, Owner at Digital Juggler and Head of Digital at CrowdShed
(@jamesgurd).

It’s the year of mobile. Again. And again. You get the picture!

But now it’s different. It feels like we’ve reached the tipping point where ecommerce teams are
starting to think mobile first, with evidence from major retailers of UX teams adapting their
processes to design for touchscreen first. Websites are launching where the desktop site is a
responsive version of the mobile site, rather than the other way around. For example, Quartz –
positioning itself as a “digitally native news outlet for the new global economy” – has adopted
responsive design.

Figure 1: Qz.com responsive site

Source: Browser view by device size using http://mattkersley.com/responsive/

There’s an obvious reason for this; we’re using our mobile devices more often and for more
activities. As you’ll see in the next section on mobile market data, mobile growth is explosive.
Multi-device browsing/shopping has rapidly moved into the mainstream, forcing the hand of
businesses with regards to investment in mobile commerce. The question now for business
leaders is not “Should we invest more in mobile commerce?” but “What is the best way to invest
more in mobile commerce?”

Responsive web design has rapidly gained popularity as digital teams try to reduce the complexity
of managing multiple channels while delivering a high quality user experience. However, many
leading ecommerce brands still provide a separate mobile site on a unique domain with its own
code base. For example, both Target and John Lewis have m. domains for their mobile sites
rather than using a responsive design. Why do they do this? Is it a legacy issue of a decision made
before the tools were in place to properly enable responsive design? Or is there a fundamental

Mobile Web Design and Development Best Practice Guide Page 10

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 commercial imperative for maintaining a separate mobile site? Such questions will be explored in
this report.

Much has been written on mobile strategy; a search on Google alone returns 431m results. Niche
experts have added their voice with specialist insight around their topic of expertise; search
marketing sites like Moz have blogged on the SEO implications of responsive design1, technology
companies like RedAnt have blogged on some of the technical considerations 2.

So, why do we need a new report?

The majority of information available focuses on why you need a strategy and the benefits of
having one. Less is written about the practicalities of defining and structuring that strategy and
less still on the commercial implications of technology and information architecture (IA)
decisions.

At a recent Econsultancy roundtable on mobile optimisation, the elephant in the room was
technical competence. There was a general agreement that, in principle, responsive design
satisfied the core business requirements for mobile commerce but at the same time there was an
acceptance that not enough was known about the technical implications of going responsive, such
as the ability to quickly change content/user journeys at device level and the true cost of site
maintenance.

Quite simply, there is uncertainty about what the right mobile strategy is and whether or not
everyone should be committing to responsive web design. For example, if you opt for a responsive
design solution, is having a responsive code base enough to satisfy mobile and tablet visitors? Or
do you need to go further and customise the user journey at device level while using a responsive
code base to underpin all channels? Does your responsive design allow you to easily customise
these journeys?

While modern digital teams appear to have made great leaps in their UX knowledge,
understanding of the technical implications (both short and long term) of mobile development
choices lags behind. This report discusses these technical implications to provide an objective
evaluation of the pros and cons for the principle mobile development techniques: responsive web
design (RWD), adaptive web design (AWD) and mobile-specific development platforms (MDP).
In this report we hear from leading practitioners: ecommerce agencies, client-side ecommerce
leaders and independent consultants. We hope you find it illuminating and insightful.

Matching the technical solution to user needs is critical

“I find a general misconception among ecommerce teams that responsive and adaptive are separate approaches.
For me RWD is the development approach of using a single code base that supports fluid design across devices –
so you don’t have to build each site from scratch. You can then use client-side wizardry like JavaScript, CSS etc.
to tailor the presentation of the assets to suit each device e.g. my product page template automatically reflows for
a mobile device.
“Adaptive is fuelled by UX techniques, identifying device-specific needs and then ensuring assets are customised
to the device. So a site can be responsive and also use adaptive techniques to increase relevance of content and
improve the UX (e.g. hidden assets). Or it can be responsive and not do anything adaptive (e.g. reflow all content
to fit a mobile browser).
“The key challenge, as with anything, is to understand user needs and then map the tech solution to those needs.
So don’t commit to responsive or a separate mobile site until you understand what you need and how best to
deliver it.”
James Gurd, Owner, Digital Juggler

1http://moz.com/blog/seo-of-responsive-web-design
2https://www.redant.com/articles/design-and-build/the-anywhere-web-the-pros-and-cons-of-
responsive-web-design/

Mobile Web Design and Development Best Practice Guide Page 11

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
2.1. Goals of the report
Primary goals

 To provide an objective appraisal of the technical and commercial implications of mobile web
development approaches, to help digital teams effectively evaluate which development
approach is most relevant to their specific business needs.
 To help digital teams understand the risks involved with mobile web development so that
these risks are visible and defined to enable effective decision-making.

Secondary goals

 To provide insight and learning from leading ecommerce practitioners who have had direct
experience of planning and implementing mobile strategies using either RWD, AWD, MDP or
a combination of these.
 To provide case study references from ecommerce websites that have gone through the
process of adopting one or more of the development approaches.

Designing the universal webpage

The excerpt below is from an article that is more than 10 years old, yet we still see websites that
don’t adhere to the design principle of adapting to suit the needs of the mobile user.
“Make pages which are accessible, regardless of the browser, platform or screen that your reader chooses or must
use to access your pages. This means pages which are legible regardless of screen resolution or size, or number of
colours (and remember too that pages may be printed, or read aloud by reading software, or read using braille
browsers). This means pages which adapt to the needs of a reader, whose eyesight is less than perfect, and who
wishes to read pages with a very large font size.
“Designing adaptable pages is designing accessible pages. And perhaps the great promise of the web, far from
fulfilled as yet, is accessibility, regardless of difficulties, to information. It’s an important belief of the World
Wide Web Consortium, and is becoming an imperative of web design, as webpages will be required by law to
provide universal access, just as building codes around the world require access to buildings.”
John Allsopp, “A Dao of Web Design” 3

2.2. Report structure, content and target audience

This report uses qualitative data from industry experts to help you understand how to approach
decision-making for mobile optimisation. The content is primarily based on their knowledge and
experience as practitioners. Wherever relevant, this is backed up with quantitative data from
market research.

Please note that in this report we don’t define RWD and AWD as being completely divorced and
separate development approaches. A website can be both responsive and adaptive and we will
discuss this in more detail in Section 4: Responsive Web Design and Section 5: Adaptive Web
Design.

3 http://alistapart.com/article/dao

Mobile Web Design and Development Best Practice Guide Page 12

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
There are eight sections included in this report:

1. Introduction
Positioning the report and setting the context for mobile optimisation through market data.
Written by:
– James Gurd, Owner of Digital Juggler and Head of Digital at CrowdShed

2. Planning your mobile site

A high-level strategic view outlining the importance of planning and structure for a mobile
strategy and looking at some of the key drivers for decision-making.
Written by:
– Stuart McMillan, Deputy Head of Ecommerce at Schuh
– Will Garbutt, Senior UX Manager at Summit
– Maria Morais, Digital Commerce Consultant at Neoworks

3. Responsive web design

Providing a clear explanation of what RWD is and the business implications that you need to be
aware of.
Written by:
– Mark Slocock, MD at GPMD
– Stuart McMillan, Deputy Head of Ecommerce at Schuh
– Maria Morais, Digital Commerce Consultant at Neoworks

4. Adaptive web design

Providing a clear explanation of what AWD is and the business implications that you need to be
aware of, evaluating the relationship between RWD and AWD.
Written by:
– Markus Karlsson, CEO & Founder at Affino
– David Skerrett, Managing Partner at Nimbletank
– Matt Curry, Head of Ecommerce at LH Group

5. Mobile-specific website development

Providing a clear explanation of what mobile-specific website development is and the business
implications that you need to be aware of.
Written by:
– Tomas Honz, Director of Technology Strategy at Summit
– David Skerrett, Managing Partner at Nimbletank

6. UX/UI design
Looking at the key design requirements and implications for the three mobile development
approaches.
Written by:
– Justin Taylor, Founder & MD at Graphitas
– Paul Moore, Service Design Lead, Fjord

Mobile Web Design and Development Best Practice Guide Page 13

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
7. Technical SEO for mobile development
Looking at the key technical SEO requirements and implications for the three mobile
development approaches, with implementation examples to provide context.
Written by:
– Sohaib Siddique, Technical SEO Lead at Verve Search

8. Summary and recommendations

Distilling the key learning from the report into concise takeaways that can help your business with
its mobile strategy planning.
Written by:
– James Gurd, Owner of Digital Juggler and Head of Digital at CrowdShed
– David Skerrett, Managing Partner at Nimbletank
– Matt Curry, Head of Ecommerce at LH Group

As you can see, there is a section dedicated to each of the three development approaches. Within
each section we explore the technical and commercial implications for developing a mobile site,
covering:
 What exactly does the development method mean?
 How it works – getting under the hood to look at the technical nuts and bolts
 Technical challenges and considerations for ecommerce teams
 Commercial pros and cons
 Example websites that have adopted this approach

Included is expert commentary from ecommerce practitioners who are at the sharp end of mobile
commerce, both in client-side teams implementing and managing a mobile strategy or agencies
and consultants working closely with client teams.

The report is intended to help businesses rationalise the investment opportunity for mobile
commerce and understand the potential implications of development decisions. It is relevant to
the following audiences:

 C-suite executives
 Heads of ecommerce
 Heads of IT
 Agency directors and account managers
 Independent consultants

Please note that the focus of this report is on dissecting the technical challenges and commercial
implications of the key mobile site development options. It does not focus on the process and
structure for creating a mobile strategy, or indeed what your mobile strategy should include,
although this is discussed at a high level in Section 3: Planning Your Mobile Site.

Mobile Web Design and Development Best Practice Guide Page 14

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
2.3. Mobile commerce market data
To provide context to this report, we look at some of the key data available that emphasises the
importance of mobile optimisation and the factors influencing commercial decision-making.

2.3.1. Mobile moves centre stage for strategic planning

Mobile is becoming a core part of digital strategy planning. In an Econsultancy and BuyDesire
survey, 67% companies agreed that mobile will become fundamental to their marketing and
commerce strategy in the next 12 months. However, budget allocation lags behind with only 7%
saying there is a dedicated mobile budget and 40% saying there is no specific budget allocated to
mobile marketing.

Figure 2: Mobile strategy sentiment (company respondents)

Source: Econsultancy / BuyDesire Mobile Marketing and Commerce Report

https://econsultancy.com/reports/mobile-marketing-and-commerce-report

Mobile Web Design and Development Best Practice Guide Page 15

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
2.3.2. Christmas is mobile
2013 was a bumper year for mobile, with trading updates showing many retail success stories:

 Dominos
Mobile sales were up 91% in Q4 and accounted for 30.9% of total online sales (vs. 19.7% in
2012)4.
 John Lewis
On Christmas Day traffic from mobile phones and tablets made up 75% of overall traffic 5.
 Schuh
Christmas Day traffic split was: 33% desktop, 39% mobile, 28% tablet 6.

The IBM Digital Analytics Benchmark also reported that the majority of traffic to UK retail sites
on Boxing Day was from mobile devices and mobile traffic grew to 58% of all traffic (smartphones
30%, tablet 28%), an increase of 42% over 2012. For mobile sales, iOS was five times higher as a
percentage of total sales, with iOS users spending nearly twice that of Android users.

However, tablets dominate for sales – tablet users drove 29.4% of online sales vs. 15.8% for
smartphone users. This is not surprising as there is a general acknowledgement that smartphones
are used primarily for research and completing specific tasks (browsing), less so for making a
purchase.

2.3.3. Mobile browsing and purchasing growth

Mobile internet usage is growing across all age ranges. In the UK, volume is concentrated in the
younger age ranges but rate of growth is fastest in the 55-64 age group (mainly because it’s from a
small base). For all age groups, mobile is being used to get information and answer questions
when away from the desktop.

Figure 3: UK mobile internet usage

Source: Ofcom7

http://www.dominos.uk.com/media_centre/pdf/Q4%20Trading%20update%20FINAL%2007012014.pdf
5 http://www.johnlewispartnership.co.uk/media/press/y2014/press-release-2-january-2014-john-lewis-

christmas-trading-statement-five-weeks-to-28-december-2013.html
6 http://econsultancy.com/blog/64057-christmas-2013-ecommerce-stats-round-up-john-lewis-amazon-

and-m-commerce
7 http://stakeholders.ofcom.org.uk/market-data-research/market-data/communications-market-

reports/cmr12/uk/UK5.84

Mobile Web Design and Development Best Practice Guide Page 16

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
The volume of mobile devices shipped has grown rapidly since 2009 with Apple and Samsung
dominating globally. More than 250m smartphones shipped during Q3 2013 alone.

Figure 4: Global smartphone shipments by manufacturer

Source: Business Insider, 2013

We know that shopping activity on mobile devices is much lower than on tablet and desktop but
mobile is a key communication channel for companies; email is a good example.

Figure 5: Typical use of smartphones (UK)

Source: Velti, 2013

Mobile Web Design and Development Best Practice Guide Page 17

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 Content browsing is also on the rise. Around a fifth (21%) of smartphone owners use video
sharing daily on smartphones. Retailers are responding to better bandwidth and device
capabilities by adding more video content to mobile sites and apps.

Figure 6: Mobile video growth

Source: comScore, 2013

What the experts say

“Mobile is where all of the action is taking place – and interesting things are happening.
“People are moving across multiple devices as a standard way of interacting with information. From research to
shopping or simply surfing the web – these online activities are now extending beyond laptops to include mobile
devices like smartphones and tablets. If mobile is not a part of your business focus then you are not only missing
out on the trend, but are also most likely losing business.
“Once you make the move to mobile it’s important to realise that customers expect the same brand quality and
refined user experience that they’ve become accustomed to on the web. Companies need to work hard to measure
and analyse user data, then design a powerful mobile experience that helps their users achieve their online
goals.”
Jeremy Woska, Senior Product Manager, Ensighten Mobile

2.3.4. Key factors driving mobile usage

Improved access to public Wi-Fi

According to ONS, even at the start of 2012 there were 5m people in the UK using wireless
hotspots, more than double the previous year. Accessing websites and content on the move is the
norm for many people.

Public Wi-Fi is penetrating transport systems. In London, Virgin Media provides free Wi-Fi to
existing customers of Virgin Media, EE, Vodafone and O2, or passes can be bought for £2 per day
or £15 per month. This has helped reduce the downtime when people can’t access websites and
made mobile browsing on public transport far better.

Mobile browsing during commuting hours

We’re accustomed to an always-on digital world, connected to people, things and brands via
mobile devices. Scan the train or tube in the morning/evening and count how many people have a
tablet or mobile in their hands. This opens the door for companies to connect with customers
outside their core hours, providing mobile experiences that can be enjoyed during the commute.

Mobile Web Design and Development Best Practice Guide Page 18

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Figure 7: Browsing patterns by device

Source: comScore Device Essentials, 2013

Technological innovation

Advances in mobile technology have made it easier for consumers to connect with and buy from
online businesses. Mobile payment is a good example because it’s an industry that is undergoing
rapid evolution, although still highly fragmented.

Near field communication (NFC) has dominated retail thinking for a while, as retailers battle with
the cost and complexity of upgrading point of sale (POS) to support NFC payments and
manufacturers battle with handset space to embed NFC capability. Contactless payment for small
ticket items is now common, with retailers like Marks & Spencer and Starbucks providing positive
case studies.

Bluetooth low energy (BLE) was given centre stage at the end of 2013 when Apple announced the
iPhone5 wouldn’t be NFC-enabled; instead it would tap into BLE capability through the new
iBeacon. BLE gives retailers the opportunity to create hyper-local marketing campaigns, delivered
over mobile to shoppers in specific locations, primarily of benefit to multichannel retailers with
store presence. Coca-Cola recently announced it is looking at how iBeacons can be used to enable
local marketing during the World Cup in Brazil 8.

There are payment-specific solutions helping improve the UX of mobile checkouts. Card.io helps
reduce data entry by using smartphone scanning capabilities to scan card details. m:Cypher helps
tackle the frustration of poor usability around 3D Secure on mobile checkouts. These are just two
examples of innovators helping to make life easier for mobile shoppers.

The key point is this: consumers are well versed in using mobile devices to contact, engage with
and buy from websites and they have touchscreen devices that let them do this 24x7, therefore it’s
imperative that mobile websites deliver a high quality user experience.

8http://www.thedrum.com/news/2014/01/13/coca-cola-explores-ibeacons-marketing-tool-world-cup-
sponsorship

Mobile Web Design and Development Best Practice Guide Page 19

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 4G connections – faster mobile web

4G is very much in its early dawn. GSMA Intelligence estimates 4G to account for 7% of global
connections by 2016, surpassing 500m at an annual growth rate of 69%. In comparison, 3G
connections will grow 18% to around 3.2bn, 38% of total global connections.

According to Ofcom, there are only 0.5m 4G mobile subscribers in the UK vs. 82.2m 2G/3G
subscribers. However, 4G offers mobile ultra-broadband, which means much faster data
download, reducing the barriers to rich mobile experiences. This is likely to help mobile
marketers add more content and features to mobile sites without compromising the core UX, or
falling foul of the stringent page load guidelines Google is setting out. It’s also likely to be a boon
for mobile gaming.

3G connections still dominate and unreliability is a major inhibitor for mobile web – mobile
browsing becomes slow and forgettable when a 3G connection is poor or lost. This is where
technical optimisation is critical, squeezing every last ounce of efficiency out of mobile sites to
minimise page load time. This is touched on in more detail in this report and is a key
consideration when making development decisions.

2.3.5. Popularity of different development approaches

Our Reducing Customer Struggle report, produced in association with IBM Tealeaf, found that
72% of companies surveyed planned to ramp up their investment in mobile, with around three-
quarters saying that mobile is ‘critical’ (32%) or ‘important’ (42%) to their business objectives.

Interestingly, although responsive design is the most popular option for mobile optimisation, 41%
of businesses surveyed said that they use a mobile-specific development platform. Major UK retail
brands like John Lewis, House of Fraser, Debenhams and Marks & Spencer adopt this approach.

Figure 8: How do you optimise the mobile experience?

Source: Econsultancy / IBM Tealeaf Reducing Customer Struggle Report

https://econsultancy.com/reports/reducing-customer-struggle

Mobile Web Design and Development Best Practice Guide Page 20

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
2.4. Glossary of key terms
Responsive web design

RWD is a web design methodology whereby websites are developed to provide an optimal user
experience across desktop, tablet and mobile devices using a single code base.

RWD sites use fluid design to dynamically change the visual display based on the device that is
accessing the website, using proportion-based grids, flexible images and media queries. Webpages
can use different CSS styles depending on the device that is accessing them.

For responsive design to work, breakpoints need to be defined – that is the browser width/screen
size at which the visual display must change to accommodate specific devices. It’s common for
ecommerce teams to have breakpoints for tablet and mobile devices.

An easy way to tell if a site is responsive is to gradually reduce the visible pane of a web browser
on a desktop screen and see if the content reflows at certain breakpoints to accommodate the
smaller screen.

Adaptive web design

AWD is a web design methodology that adapts to different screen sizes using responsive
techniques but also customises the user experience based on device-specific capabilities and the
unique requirements of users at device-level. For example, adaptive may hide some content assets
for smartphone users to tailor the content to the needs of people on the go and reduce page size to
enable faster mobile load time.

Adaptive and responsive actually share similar goals. The key difference is that with adaptive,
changes to page layout and content are made server-side rather than client-side using CSS and
media queries.

Adaptive focuses on the user, not the browser. It’s an important distinction.

Mobile-specific development platform

MDP is a design methodology that creates a separate code base for the mobile site to enable the
mobile user experience to be fully customised. This is clearly adaptation but for this guide we’re
distinguishing this approach from adaptive web design based on its construction around a
separate m-dot domain.

Using mobile optimisation, developers create a separate mobile site rather than using responsive
techniques to scale the main desktop site to fit within mobile browsers. John Lewis is a good
example – the mobile site is on the m.johnlewis.com domain.

2.5. Marketing challenges and opportunities

There are many challenges for marketers and here we pick out three of the most common:

1. Usability
Companies need to monetise their investment in mobile; an ROI is required. An important way to
deliver ROI is to provide an excellent user experience, reducing the barriers to purchase. On
mobile devices the smaller screens make it harder to provide the same depth of content as on a
desktop screen, so web teams need to think carefully about what mobile users want and need,
tailoring the mobile experience to these requirements.

Mobile Web Design and Development Best Practice Guide Page 21

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Patience levels when browsing on-the-go are notoriously low, so it’s imperative that mobile sites
are intuitive and easy to use. Usability should be a driving force for mobile development
decisions.

For example, page speed is a critical component of usability for mobile web. Google has
announced a threshold for mobile page load of 1s and while we don’t advocate blindly following
what Google says, it’s an important line in the sand indicating that slow page loads are going to be
looked at for mobile search indexation.

2. SEO – indexation and visibility

Mobile search is a core component of digital marketing. Analysis from BIA/Kelsey predicts that
mobile search queries will overtake desktop queries by 2015 in the US. In the UK, 52% of
smartphone users search daily and only 3% never use mobile search.

Figure 9: US search market: mobile vs. desktop

Source: BIA/Kelsey9, 2012

Mobile SEO is critical for local search, therefore highly relevant to local businesses and
multichannel retailers with a store base. It’s estimated that four in five people use their
smartphone to look up local information and according to Google’s Mobile Search Moments10
study, 40% of mobile searches have local intent.

Ensuring mobile pages are accessible to search engines with an information architecture that
enables indexation is a commercial necessity. This requires an understanding of the technical
optimisation for mobile SEO, which will vary depending on the development approach that is
taken.

SEO implications for each of the development approaches are discussed in Section 8: Technical
SEO for Mobile Development.

9 http://blog.biakelsey.com/index.php/2012/04/20/when-will-mobile-local-searches-eclipse-
desktop/#.Utj2CmTV-pw
10 http://www.google.com/think/research-studies/creating-moments-that-matter.html

Mobile Web Design and Development Best Practice Guide Page 22

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
3. Landing pages
Mobile campaigns are reliant on mobile-optimised landing pages. A poorly designed page that
doesn’t provide a high quality user experience for mobile visitors is likely to adversely impact
conversion and ROI.

Marketing teams need to map the user journey for mobile visitors to identify potential issues. For
example, is the checkout mobile-optimised as well as the landing page? It’s important that the
end-to-end process is considered.

The development approach you adopt has a direct impact on these marketing challenges. For
example, with a responsive site that doesn’t use adaptive techniques, are all forms user-friendly
on a mobile device? It’s important that the impact on the marketing team is considered as part of
the strategy planning and due diligence process.

Mobile Web Design and Development Best Practice Guide Page 23

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
3. Planning Your Mobile Site
Contributors
This section was written by Stuart McMillan, Deputy Head of Ecommerce at Schuh (@mcmillanstu), Will
Garbutt, Senior UX Manager at Summit and Maria Morais, Digital Commerce Consultant at Neoworks
(@ceumorais).

How do you build a mobile website? At the 2014 Search Marketing Expo, Google’s Webmaster
Trends Analyst, Pierre Farr, declared that Google prefers responsive web design to mobile
templates. This indeed has its advantages, as we’ll see in Section 4: Responsive Web Design, but
it’s not the only way to deliver a mobile site.

This section looks at some of the planning stages you should consider before committing to a
development approach for your business. We wouldn’t advise you base your mobile development
strategy purely on Google’s recommendations. Listen to what they have to say and why but
ultimately you need to build a solution that delivers the best possible UX for your customers and
supports your business goals.

The devil is in the detail

“This is where your mobile site will succeed or fail. If you haven’t used all the data, industry benchmarks and
customer insight at your fingertips to understand what your mobile customers want you will, at best, limit your
conversion rate and at worst, over spec (i.e. waste budget), annoy customers and damage your brand.”
Will Garbutt, Senior UX Manager, Summit

3.1. Defining goals and objectives

Why set goals and objectives?

Before embarking on any project it is vital that the goals and objectives of the project are clearly
understood. Poorly defined goals and objectives can cause a range of project management
problems such as scope creep. Fundamentally, you are dramatically increasing the likelihood that
you will end up with a product which is not fit for purpose.

Going even further back in the process, clearly set goals and objectives can help you determine
whether you should do the project at all.

Having clear goals and objectives provides an unambiguous framework for everyone working on
the project. Most projects involve multiple people, with different skillsets, different biases and
different ways of looking at the world. This is not their fault and it is the responsibility of the
project owner to articulate their vision. Do not assume that everyone involved will understand
what you want to achieve; don’t blame developers just because they don’t share your “common
sense view of the world”.

It is important to consider the cost of any remediation – that is, any work carried out to ‘fix’ a
product. Even given widespread adoption of agile processes which are designed to shorten the
project lifecycle compared to traditional waterfall models, it is still cheaper to ensure that the
project is correctly specified pre-build.

Mobile Web Design and Development Best Practice Guide Page 24

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Figure 10: Project impact of fixes over time

Goals for mobile websites

It is all too easy to have implicit goals such as “we need a new mobile website”; however, this fails
to address the real business objectives. In this simple case, you would be off to a much better start
if you had an explicit objective of “maximising the profit generated from customers on mobile
phones”.

Setting SMART objectives will help you deliver a project that meets your overall business
objectives.

SMART = specific, measurable, attainable, relevant and time-bound.

Assuming that the new mobile site is an extension of an existing website offering, these could be:

 Specific
Clearly list ALL the functionality of your existing website. Prioritise those features. Perhaps by
using a scheme such as MoSCoW11, or at the very least identify which features are necessary to
have a minimum viable product. Remember, this product is designed to meet your overall
business objectives, it may not be necessary to have complete feature parity between sites.
Clearly list any new mobile-specific features that are required.

 Measurable
Can you clearly measure people’s interaction with those functions?
If you can’t, consider improving your analytics on your existing site to allow you to properly
plan the new site.
Do you have a clear understanding of your existing mobile:
– Traffic levels
– Conversion rate
– AOV
– New vs. returning customers?
Have you plotted these metrics against time and can see a clear trend emerging? Can you
anticipate where they will be in a year’s time?

11For more information on the MoSCow prioritisation method, see

http://en.wikipedia.org/wiki/MoSCoW_method.

Mobile Web Design and Development Best Practice Guide Page 25

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Carry out usability testing on your existing site and understand the existing friction points. You’ll
want to make sure these are all covered by the new site. Performance can be a problem while
using websites on mobile phones. Set clear site speed performance goals.

 Attainable
Attainability will be heavily influenced by your choice of platform. You must consider your
prioritised list of features versus the platform(s) on offer. Do you have the right skill set
available to achieve the project goals?
This rule of thumb will serve you well:

Unrealistic goal setting will not get you the product you are looking for.

 Relevant
What is the opportunity cost of doing nothing? If you did nothing and mobile trends continue,
how much revenue would you lose? Is that loss enough to justify the cost of the project?
Given finite resources, would there be other projects that could give you a greater return on
investment? You should remember to take “time to market” into account; could smaller
projects, which could be delivered quicker, actually return greater profit?

Figure 11: Understanding the impact of time to market

 Time-bound
Deadlines usually have to take peak trade times into account, so work back from there. If your
peak trade is Christmas that gives you a timeline of roughly:
– Standard code freeze mid/late November.
– Go live end of October to allow for any emergency remediation and “bedding in”.
– Release to beta testing mid-September to allow for pre-live remediation and re-testing.
– Internal alpha testing from early August.

Mobile Web Design and Development Best Practice Guide Page 26

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 Plan on it being at least a month late in coming out of testing, so add that to the build time.

3.1.1. Example goals

 Provide a transactional mobile site, which is live in six months
Initial go-live may contain must-have features only, secondary pages may be deferred to
subsequent releases. It is more important to get a functioning mobile experience live sooner than
it is to get one that contains 100% of features.

 Site must have feature-parity with desktop site in nine months

Conversion must be higher than the existing site within one month of launch. Related to this:

– Site should load in under two seconds on a 3G connection.

– Site must have a usability review before it goes live; no usability defect classified as urgent
should go live.

Case study: Defining mobile goals for Schuh

“Schuh has existing desktop, tablet and mobile websites; we have seen and are still seeing massive movement of
traffic from desktop to mobile and tablet. The existing mobile site performs well but we require a single digital
experience which meets the following objectives:

 Provides a seamless and consistent digital experience over all devices.

 All features must be available on all devices, from launch.
 Provide a more ‘usable’ experience over all devices.
 Carry out moderated user testing on the core journey on all three existing sites, ensure that all high-friction
issues are addressed.
 The site should make best use of the available real estate no matter which screen size it is viewed on.
 Provide a single URL for a single resource with a consistent document structure, no matter which screen size.
 Has all SEO best practices baked in, as defined in our SEO roadmap.
 Improve the site speed (on the connection type applicable to the screen size):
– Page should have started to load by one second.
– Above-the-fold content should be loaded in under two seconds.
– Complete page loaded in three seconds.
 Reduces development complexity.
 We should only have to carry out a piece of work once on one site.
 Improve our analytics implementation by design.”
Stuart McMillan, Deputy Head of Ecommerce, Schuh

Mobile Web Design and Development Best Practice Guide Page 27

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
3.2. Understanding audience needs
Why do we need to understand user needs for mobile journeys?

Quite simply, mobile users differ from desktop users. People often use mobile devices in different
situations and aim to achieve different goals than if they were on a desktop, so blindly bucketing
them in with desktop users is at best naive and at worst financially damaging.

The natural limitations of the device, such as the slower download speed (although 4G is currently
being rolled out), the smaller screen size including the buttons for inputting information and the
true mobile nature of the device, mean that it plays a very different role in the user’s shopping
experience.

Research shows that different devices are popular at different times of day and for different
purposes. Mobile grows throughout the day but has clear peaks during commuter times (i.e.
morning, lunch and early evening) whereas the desktop peak tends to be limited to late evenings
(i.e. post-commute). There are also significant differences in conversion rate and average order
value across devices. According to Lisa Little, Search Marketing Manager at RadioShack:

“User behaviour is much different on smartphone devices compared to the desktop

experience. It became obvious that to be successful, we had to measure mobile
performance by focusing on different criteria.”

But it appears that most businesses are failing to meet the different needs of a mobile customer.
Customer satisfaction for mobile currently lags behind desktop (73% vs. 77% based on a Foresee
benchmark12), indicating that mobile websites aren’t meeting user expectations. One of the key
reasons for this is that businesses don’t fully understand the expectations of mobile users, or even
realise that mobile users may have different expectations to desktop users.

This is not to say that any learning you have about your desktop users should be disregarded. This
information is still valuable, but cannot just be blindly followed. Recognising the differences in
mobile users and adjusting your strategies and KPIs to take account of the fact that mobile users
will navigate through the site in a different way to desktop users puts you in a stronger position.

In context – learning from the industry

Radioshack
Electronics store RadioShack launched a mobile-optimised site with mobile-specific features such as GPS and
click-to-call and found that mobile AOV was 30% higher than on desktop. They found that 40-60% of mobile
store locator clicks were being converted into store visits, and this was seen as more of a key metric on mobile
than on the desktop site13.

Carpetright
Flooring retailer Carpetright recognised that their customers were using mobile during the research phase of the
shopping journey. With this in mind they built a dedicated mobile site that focused on key conversion actions
such as finding a local store, making an appointment and ordering samples.

These actions all require a customer to enter a postcode, therefore making them trackable should they follow up
their online action with an in-store purchase. This allows Carpetright to accurately attribute sales to online
journeys and store performance based on ability to convert online customers to in-store purchasers.

12 http://www.foreseeresults.com/news-events/press-releases/foresee-releases-2013-uk-retail-mobile-fxi-
report.shtml
13 http://www.thinkwithgoogle.com/case-studies/radioshack-converts-mobile-clicks.html

Mobile Web Design and Development Best Practice Guide Page 28

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
In context – learning from the industry (cont.)
Affiliate Window data
Data compiled by Affiliate Window, looking at the impact of mobile optimisation across different industry
sectors, shows the impact that a properly optimised mobile experience can have and the size of the pie you could
potentially be missing out on if you fail to optimise.

In both the Gifts and Footwear sectors, conversion differences of up to 300% can be seen between mobile-
optimised and non-optimised sites14.

3.2.1. Using research and insight

In order to successfully plan your mobile site, it’s key that you research and identify the
motivations, needs and actions of your mobile visitors. There are a number of different tactics you
can employ in order to achieve this. These are outlined below and describe some of the most
effective ways of ensuring that your mobile site is focused on the needs of users, giving it the best
chance of success.

Web analytics metrics

Various metrics can be used to identify what the specific differences are between your desktop
and mobile users. This will help you identify the common user journeys and needs of your mobile
visitors.

The following are some of the key metrics you should compare across devices:

 Popular times of day and days of week

 Number of pages per visit, time spent on site
 Exit pages / exit rate per page
 Bounce rate
 Percentage of visitors who add to basket
 Conversion rate
 Store finder usage
 Device split
 Average order value
 Visits to purchase

For example, you can look at bounce rate and page exit data to understand how exit points differ
across devices. You may have a higher bounce rate for certain pages on mobile devices that is
actually quite healthy, such as on blogs where users are consuming bite-size content during their
commute but not looking for a deeper engagement with the website. If users are finding the
content they want easily, then even with a high bounce rate the mobile UX may actually be really
good.

Personas and user journeys

Creating mobile-specific personas and user journeys where appropriate will help bring to the
forefront a mobile-first way of thinking and enable you to focus on how the mobile user will be
interacting with your site.

14http://wiki.affiliatewindow.com/index.php/How_mobile-
optimised_sites_drive_conversion_rates_and_AOVs

Mobile Web Design and Development Best Practice Guide Page 29

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Mobile-first is a way of thinking that focuses you initially on what you should offer on mobile and
then scale up for desktop, rather than the traditional way of thinking: “what do we remove from
the desktop site to make it work on mobile?” It forces you to focus and prioritise right from the
start – due to the lack of screen real estate on mobiles you cannot afford to have a lot of
distractions and unneeded elements cluttering up the screen.

However, there is a danger that it could cause the desktop users’ (which, let’s not forget, is STILL
going to be the majority of your traffic for the immediate future) experience to be ‘dumbed down’.
This reinforces the argument that your choice of how to approach mobile should very much be
based on your users and what they are aiming to achieve on your site in different contexts and on
different devices.

In short, if the key tasks that your users are performing (and therefore the main focus of your site)
are the same across devices, then a mobile-first approach can help to create a streamlined and
focused experience across those devices. If the user intent differs then serious consideration has
to be given to a separate mobile site, or a more adaptive web design approach.

Ranking user tasks

Listing all the tasks users want to carry out on your site and then comparing mobile to desktop
will show you if the hierarchy of these tasks changes to such an extent that the focus of the site
needs to change. Also, if specific (and important) tasks appear purely on one device (mobile or
desktop) then this is a good indicator that a dedicated site for that device may well be required to
ensure that the task in question can be easily completed.

Mobile importance Desktop importance

st rd
Task #1 1 3
rd nd
Task #2 3 2
nd st
Task #3 2 1
….. ….. …..

st rd
Goal #1 1 3
rd nd
Goal #2 3 2
nd st
Goal #3 2 1
….. ….. …..

Desk research

Learn from the successes and failures of your peers. Consult Econsultancy, IMRG and other
publications and expert blogs in order to find tips and tricks, identify trends and understand best
practice.

There are a number of best practices available for different sections of mobile sites, ranging from
product pages15 to mobile search and everything in between. The Nielsen Norman Group has long
published findings from their extensive testing covering strategies and guidelines for mobile
design16.

Insights into recent trends, such as how users are interacting with their mobiles and using
mobile-specific functionality (e.g. using geo-location for nearest store), can help you gain valuable
knowledge to inform whether or not you should be introducing these into your mobile offering.

15 http://econsultancy.com/blog/63161-31-things-i-need-to-see-on-your-ecommerce-product-page
16 http://www.nngroup.com/reports/mobile-website-and-application-usability/

Mobile Web Design and Development Best Practice Guide Page 30

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 The ForeSee Mobile Satisfaction Index17 gives some great insight into what users find valuable in
their mobile journey and ranks top retailers to give you some idea of what good looks like.

Primary research

Surveys and focus groups can help you identify what your users expect from a mobile site. Look at
current site usage by device and create and run your own testing, and ensure you consider the
impact mobile has on offline sales.

During focus groups gather together a number of users of your site and discuss how mobile
impacts on their purchasing journey. Are they using mobiles to browse and compare products
while in-store? Or just using them on the go to find their nearest store and check stock levels?

Ask them to describe a typical shopping experience and see at what touch points mobile appears.
This will allow you to see what tasks users require and therefore what functionality your mobile
offering requires, which helps you make a more informed decision as to the best development
route.

User testing

Nothing beats recording actual users using your site on mobile devices; watching how they
interact with the site, what their frustrations are and where the key roadblocks appear. This will
give you a definitive picture of how to create an environment that works for your mobile users.

Online services such as whatusersdo.com offer a low-cost solution for mobile testing, making it a
viable option for almost all businesses looking for insights.

Competitor testing/review

Looking at how competitors are dealing with the mobile opportunity can help to inspire you or
help generate ideas about what to avoid and how to solve potential issues. For example, are your
key competitors creating bespoke mobile solutions for users or are they simply flexing the desktop
site to fit within a mobile browser?

But don’t just focus on competitors. Look at mobile leaders to see what they’re doing and see how
you can learn from their approach. For example, brands like Amazon are often put on a pedestal
for their mobile capabilities, so get under the hood of their mobile strategy and identify what
makes it so successful.

3.3. Common mistakes to avoid

The planning of your mobile site must begin with clear objectives, defined by observed behaviour
from your users together with overall business objectives. As previously mentioned, mobile users
are not desktop users. They will carry out similar tasks if information is presented to them in an
acceptable way but their goals and use cases need to be properly catered for.

If your business objectives are not aligned with your customers’ needs, you’re in danger of
creating a site that does not appropriately answer the user needs. It’s essential to measure the
right goals and avoid the common pitfall of trying to build a mobile site using desktop goal
metrics.

Retailers who feel the main goal of their mobile site is to drive mobile site sales (a common
thought in previous years) are simply missing the point of mobile and therefore unrealistically
measuring its success or failure. The point of mobile is not simply a website revenue driver; it can

17http://www.foreseeresults.com/news-events/press-releases/foresee-releases-2013-uk-retail-mobile-fxi-
report.shtml

Mobile Web Design and Development Best Practice Guide Page 31

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 be a huge driver of in-store sales, therefore acting as a highly useful tactic in increasing brick-and-
mortar sales. It impacts on the user journey throughout and is often not the final point where
users complete the purchase. It seems as though this way of thinking is becoming more
commonplace with 87% of retailers now seeing value in smartphones’ ability to drive customers to
their store.18

From a technical and design perspective there are a number of common issues that are important
to avoid:

 Mobile context-specific inputs – for example, asking users for a phone number then
presenting them with a standard A-Z keyboard input. Give your users the best tools for the
current task and they will appreciate the ease with which they can complete it. Just under a
third (29%) of users in a recent Econsultancy survey hadn’t bought online using their mobile
due to the feeling it was too difficult to fill in forms on smartphones.
 Form design – on mobiles this needs special consideration due to constraints and context of
use that comes with the smaller screen. Tips such as breaking the form into smaller steps, top
aligning labels and the overall optimisation of forms (removing unnecessary fields, combining
fields) can help make the forms seem less of a hassle for users to complete and ultimately help
increase completion rates.
 Failing to recognise practical limitations of mobile shopping – call-to-action
buttons being too small for ‘fat thumbs’, for example, will deter users from returning to your
site. Similarly, small text links work fine on desktop sites and may look beautiful within your
design, but can be very difficult to click on mobile.
 Slow loading times – speed is a significant issue on desktop and mobile sites across the
industry. Just under three-quarters (71%) of global mobile users expect sites to load at least
almost as quickly as on their home computer19 and 46% would not return to a poor
performing site20. The design, build and hosting of a mobile site all impact its download
speed. Make sure site speed is marked as an objective as part of the build process and set your
standard at the industry benchmark.
 Redirecting users to the ‘full site’ to go through the checkout process – if your
users manage to travel through your site as far as the basket and then are confronted with a
checkout that is difficult to navigate on mobile you may fall at the final hurdle and miss out on
extra conversions.

3.4. Device-specific patterns and behaviours

3.4.1. Mobile usage
Mobiles are primarily communications tools, differing in purpose from tablets and desktops.
Research suggests that a large proportion of time spent on browsing on mobiles is related to
socialising, using social media sites to check in, write reviews and for sharing. In addition, up to
46% of mobile browsing is spent on ‘me time’ – watching videos, reading gossip websites and
playing games21. Only 12% of browsing time is spent seeking a product or service.

3.4.2. Access on the go

Mobile users usually access websites while on the go – sitting on the bus, walking down the street,
or lying in bed – leading to a number of goals and use cases that simply didn’t exist previously.
Over half (57%) of smartphone users search for information on their devices while shopping22,

18 http://rsrresearch.com/wp-content/uploads/2013/05/2013_Store_RSR.pdf
19 Compuware via http://www.mobify.com/go/50-mobile-commerce-stats/
20 Gomez via http://www.mobify.com/go/50-mobile-commerce-stats/
21 http://hbr.org/2013/01/how-people-really-use-mobile
22 Econsultancy/Toluna, 2013

Mobile Web Design and Development Best Practice Guide Page 32

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
and as such their queries are more likely to be linked to their current location or activity than on
desktop, which traditional user journeys tend to be based on. For example, using mobiles in-store
to check prices (aka showrooming) may have the same outcome as the price checking use case of
someone sitting at home at their desktop, but the journey the user takes to get to the answer
needs to be much quicker.

The focus of a mobile user is usually on a single task or action, whereas on desktop there may be
more than one action to be completed in the same journey. The vast majority (81%) of
smartphone purchases are spontaneous 23, rather than planned. Mobile devices are handy as a
quick point of reference, for browsing and carrying out product research or for looking up store
locations. In short, users want to get to the information they need as quickly as possible and the
punishment for websites not allowing this is much greater on mobile than on desktop.

Users are also expecting to use built-in phone functionality when browsing sites on their
smartphones and mobile devices (something which is obviously less relevant on desktop). Click to
call, finding directions and using GPS to see closest locations all represent functionality that a full
desktop site would not utilise but the mobile browser would want at their fingertips to allow them
to complete their tasks more efficiently. Functionality such as Amazon’s cross-platform shopping
basket can create a more streamlined and user-friendly experience for mobile browsers and
encourage them to buy products on desktop that they have been researching on mobile.

Currys allows visitors to use their phone’s GPS to locate the store closest to them – this turns
what could be a fiddly form input task into a one-button process.

Figure 12: Currys mobile store finder

One of the things to avoid is adopting technology for technology’s sake; it is important to ensure
that it actually aids the user and enhances the experience. Recent ‘next big things in mobile’
haven’t set the world alight, such as QR codes and augmented reality. QR codes have become
infamous for their numerous bad executions, featured on posters on the underground (before Wi-
Fi was available) or sending users to desktop sites with no mobile adaptation. That’s not to say
that these types of functionality won’t become more widely adopted in the future – and there may
well be specific use cases that they are perfect for – but simply jumping on the bandwagon could
prove to be a costly mistake.

23 http://www.acromobile.com/blog/bid/319860/81-of-all-smartphone-purchases-are-spontaneous

Mobile Web Design and Development Best Practice Guide Page 33

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
3.4.3. Implications of touchscreen browsing
The portable nature of mobiles offers convenience but also creates practical limitations. Small
screen size and lack of a full keyboard both affect usability. Two in five (41%) people cite screen
size as a reason they haven’t bought anything using their smartphone 24.

Users hold mobiles in their hand and interact mainly using their thumb. The comfortable area of
‘touching’ and the area hidden behind the thumb need to be taken into account when deciding on
the positioning of different elements. In addition, people’s fingers are much bigger than the area
of a mouse pointer, so it is more difficult to be precise. Elements need to be better spaced and
sized to allow users to easily ensure they are clicking on the desired button/area.

Users on touchscreen phones will use gestures such as pinching to zoom and swiping across to
view next/previous content or banners. These gestures are now commonplace on touchscreens
but for non-touchscreen browsing the user has different methods to carry out the same tasks – for
example clicking to zoom and clicking ‘next’/’previous’ buttons to see content and banners.
Mobile users have the ability to rotate their screen from portrait to landscape (something which is
very rare with non-mobile browsing), so sites need to be optimised to work well on both
orientations.

Touchscreen devices obviously have no ‘hover states’ as there is no mouse pointer to hover over
content to indicate a potential future action. Features such as ‘Quick Buy’ buttons that appear on
hover on desktop versions of ecommerce sites either have to be present from the start or appear
on touch. It is important to conform to entrenched behaviour learnt from touchscreen operating
systems, such as the functionalities described above, to make mobile sites instinctive to use.

3.4.4. Device-specific browsing variations

It’s tempting to make generalisations about mobile users as a group. However, there are
variations in usage between iPhone, Android, Windows and Blackberry users which all need to be
taken into account.

According to research conducted by Tradedoubler, 80% of iPhone users browse the internet on
their mobile daily, compared with 65% of Android users and only 9% of Blackberry users.25
However, 13% of the latter purchase weekly or more often, compared with 10% of Android users,
and a larger percentage of Blackberry users than Android users conduct weekly research on their
phones.

Android and Windows phones have the best conversion rates, at 0.83% and 0.82% respectively at
the time this report was written. iPhone conversion rate for the same time period was 0.76%,
while for other devices it was 0.48%. It is also important to be conscious that 60% of people
prefer to purchase on a tablet but only 35% say they prefer to research on tablets, suggesting that
mobile plays an active part in the pre-purchase research process.

When deciding which devices to concentrate on, it is essential to make the optimum experience
on the device(s) that the majority of your users are using to visit the site. For example, if 80% of
your mobile visits come from the latest iPhone, then optimising specifically for this device will
give you the best results. Responsive design is one strategy to deal with devices of different sizes,
ensuring the experience is at least partly optimised to the screen size being used. We discuss this
in more detail in Section 4: Responsive Web Design.

The chart overleaf shows the difference in conversion rates between different devices and
different models of devices. Conversion rates have more than doubled for tablet devices and

http://econsultancy.com/blog/62917-screen-size-and-security-concerns-among-main-barriers-to-
24

mobile-commerce-report
25

http://www.tradedoubler.com/pagefiles/28363/tradedoubler_mobile%20consumer%20behavior_uk.pdf

Mobile Web Design and Development Best Practice Guide Page 34

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 increased by about 70% for smartphones. This can largely be attributed to the industry investing
more in mobile-optimised sites and the evolution of design for these devices.

Figure 13: Conversion rates by device

3.4.5. Key drivers for device differences

Functionality

Mobile users often purchase due to the ease of being able to buy wherever they are at the time.
However, 30% of mobile shoppers will abandon a transaction if the experience isn’t optimised for
mobile26. If mobile users come across functional difficulties when browsing this is likely to take
away the enjoyment of impulse buying and make them less likely to complete the purchase.

A large proportion of functionality that desktop and tablet users enjoy cannot be successfully
implemented on mobile. One example of this is product comparison. The majority of ecommerce
websites offer this on the site when accessed by desktop and tablet, but a suitable mobile solution
doesn’t seem to have become widely available yet.

Mobiles also offer much less screen real estate to inform and ‘sell’ to the customer than tablets.
The level of content shown on product pages is usually either cut down or poorly presented in an
attempt to mirror the content on the main site. According to data available from Google’s Think
Insights, 29% of users cite inability to see detailed product information as a barrier to purchase
on smartphones27.

The difference in screen size between tablet and mobile devices also contributes to the huge
conversion rate difference. Product imagery is regarded by many as highly important in helping
websites to convert; when dealing with a small screen, the impact of the imagery is much less than
seeing it on a 10-inch iPad. As previously mentioned, the ‘simple’ act of being able to fill in your
details and checkout (the key step in converting) on a website is seen as much more difficult on a
smaller screen as opposed to a tablet, with long forms being more intimidating to users of smaller
handheld devices.

26http://www.mopowered.co.uk/Home/Resources, 2013
27http://www.thinkwithgoogle.com/mobileplanet/en-
gb/graph/?country=uk&category=MOBSHOP&topic=Q46&stat=Q46_01&stat=Q46_02&stat=Q46_03&st
at=Q46_04&stat=Q46_05&stat=Q46_06&stat=Q46_07&stat=Q46_08&stat=Q46_10&wave=2013&age=
all&gender=all&chart_type=bar&active=stat

Mobile Web Design and Development Best Practice Guide Page 35

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 User needs/goals

Mobile users are likely to have different objectives to tablet and desktop users, with the former’s
goals often being based on circumstantial factors such as where they are and what they are doing.
Mobiles, by design, are used on the move, and although many mobile browsers do so from the
comfort of their own home, the purpose of the mobile shopper is not necessarily for purchase but
often for research or content consumption (e.g. reading your latest blogs).

Mobile users’ objectives could be limited to non-transactional activities such as store locating or
looking for opening times. According to research from Deloitte, smartphone shoppers are 14%
more likely than non-smartphone shoppers to convert in-store28, so it’s important not to discount
the value of mobile sites that help to drive users in-store.

Security concerns

A number of users cite security concerns as a deterrent to mobile shopping, and do not trust
mobile devices when it comes to large payments. According to Google, 46% cannot trust credit
card security on a mobile device29.

This means people are less likely to buy large ticket items on mobile than on a tablet, where the
overall experience is more like that of a desktop. One way to overcome this is offering alternative
payment methods such as PayPal – a mobile payment method users are familiar with and
therefore, trust, and they are likely to already have an account with. This will make the checkout
process and filling in of forms much easier.

3.5. Measurement and optimisation

The prime rule is to continually measure and improve. Small incremental steps are preferable to a
radical breakthrough change.

Measurement in mobile tends to relate more to measuring engagement, independently of type e.g.
mobile version, full website adapted to mobile or app. Asking the right questions about what you
want to learn about your users during the planning phase will help you to determine which
metrics to look at later on.

Customer-centricity – how much is your customer at the centre of your operations?

Perfection is the goal – how much do you need to improve? Improvements come from
monitoring the performance of the operation processes.

When measuring and optimising your mobile website some challenges may occur and they tend
to be at least part of one of the categories below:

1. Deciding what data is relevant and what is just noise.

2. Defining when a company should be doing primary data collection and how that data should
be related with the customer’s shopping behaviour.
3. Deploying an analytics package that gives a single customer view and relevant key
performance indicators (KPIs) across different roles in the organisation.

28 https://www.deloitte.com/assets/Dcom-
UnitedStates/Local%20Assets/Documents/RetailDistribution/us_retail_Mobile-Influence-
Factor_062712.pdf
29 http://www.thinkwithgoogle.com/mobileplanet/en-

gb/graph/?country=uk&category=MOBSHOP&topic=Q46&stat=Q46_01&stat=Q46_02&stat=Q46_03&st
at=Q46_04&stat=Q46_05&stat=Q46_06&stat=Q46_07&stat=Q46_08&stat=Q46_10&wave=2013&age=
all&gender=all&chart_type=bar&active=stat

Mobile Web Design and Development Best Practice Guide Page 36

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 4. Using insights to transform operations. This means that you may have to re-think your team
structures, launch new services and/ or change your products.
When planning measurement and continuous improvement, a recommended framework during
the planning phase is the mission-critical data. Applying this framework could generate a table
like the example below.

 Primary data is shown by a 1.

 Subsidiary types used to create derived data are shown by a 2.

Hard data (data that Soft data (normally

can be quantified) qualitative data)
Customer contact details/profile 1
Customer satisfaction 1
Sales/ transactions (all channels/ products) 1
Payment methods used by customers 1
Customer loyalty 2 2
Customer acquisition source/cost 1
Customer current value/profitability 2
Customer future value/profitability 2

3.5.1. Web analytics

Web analytics has emerged as one of the top priorities on the digital agenda. Beyond the hype
around big data, executives are increasingly looking for better ways to achieve competitive
advantage that can be derived from unlimited, real-time insight into operational data.

The transformational impact of big data is challenging the traditional data architecture used by
many companies. The barrier between transactional and analytical worlds has changed in recent
years as the customer journey has become more complex.

When planning web analytics tools, it’s important to learn more about the changing behaviours
and understand the role that the smartphone has in the customer journey.

These are some of the questions that all web teams should consider when planning a mobile
website:

 When and where are smartphones used for shopping? According to Think Insights from
Google, 61% of shoppers in the UK use their smartphones to research or purchase products in
the retail category.
 When did they start researching for a product/service? The same study from Google indicates
that 32% of smartphones users start researching a retail product a moment before the
purchase, while 27% of non-smartphone users started one week before the purchase.
 Do they use an app or go directly via the mobile browser? 47% use a mobile app and 59% a
mobile browser when researching for a retail product in the UK.
 Do smartphone users use multiple screens when doing research? According to Google, only
9% researched on several devices (smartphone, desktop, tablet), but 16% researched on a
smartphone/desktop/tablet in parallel to TV.

From a marketing point of view, the challenge for analytics professionals is to rethink the
mechanics of when and where ads are seen as well as what action the potential customer will
adopt after viewing an ad.

Mobile Web Design and Development Best Practice Guide Page 37

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
A typical mobile campaign may include: text coupons, mobile-specific ads or mobile apps. To
discover ways to make mobile measurement valuable in your operational marketing plan you
should consider that today’s analytical requirements are driven by the need for speed. Attribution,
optimisation and allocation all rely on technology automation. The complexity of cross-media
interactions is too challenging to be analysed and managed manually. Technology automation
helps brands view different media channels in aggregate so they can allocate budgets to the
components that are actually driving conversions.

Attribution

Every time the user changes device during their path to conversion it gets more difficult to say
which channel has effectively contributed to the sale.

All the customer journey data generated through mobile devices can be measured across online
and offline channels. When integrating these devices with your multichannel offering you are
facilitating any attribution model you have in place. But attribution is just the first step.

Other aspects that are seldom considered are exogenous variables such as competitive offerings,
seasonality and geography. A certain complexity is required in the era of big data and once a
company has quantified the relative contribution of each channel and the influence of exogenous
factors, the next step is optimisation.

Optimisation

Process mapping is a vital step for all organisations looking to improve a cross-channel strategy.
But how do you combine data coming from different sources? Is it possible to develop a data
governance strategy in all organisations?

A starting point for all the previous questions may be an audit on the different ways basic data on
customers is collected.

Optimisation uses predictive analytics tools to run scenarios for business planning. Using the
actual elasticity of your business drivers enables you to run thousands of possible scenarios within
seconds/minutes. Predictive scenarios allow companies to have a much clearer understanding of
the strategic landscape and adjust all tactical plans quickly to gain a competitive advantage over
competitors.

You need to show that the data has been used with a purpose and that you are taking your
audience on a journey. Mobile is part of that journey so don’t optimise for mobile only, optimise
for a multichannel journey.

Allocation

Allocation is related with the real-time redistribution of resources or budget across the
organisation. When businesses start having multiple sales channels, multiple products, multiple
brands or multiple geographies, analytics get considerably more complex and consequently more
than most internal teams can handle.

Any company, regardless of its size, can start building the right foundations of an effective
analytics infrastructure coupled with an in-house adaptive marketing culture. The challenge is to
adopt this not only quickly but, more importantly, before competitors do.

The reality of most retailers is that data is spread all over the place without a concept of master
data, data definitions or data quality measurement. If that is your case the ideal is to create all of
those before anything else. The recognition of the importance of doing the right thing from a data
governance perspective can save your company from unnecessary risks when there is bad news to

Mobile Web Design and Development Best Practice Guide Page 38

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 be reported. The solution in most cases seems to be a transformation through the use of data and
analytics by an independent group within the business.

Following the Pareto principle is a good starting point: 80% of your profit will come from 20% of
your customers and 20% of your products. Instead of tracking the universe of data and trying to
make sense of everything, define where the sweet spot is in your business, where selling your best
products to your best customers generates more profit. A simple tool like Google Analytics can
help you to define your sweet spot across channels.

3.5.2. Metrics to measure a mobile website

Using Google Analytics (GA) as an example, with recent improvements to filters and segments
you can now track where visitors are coming from and what devices they are using. For example,
you can filter mobile devices or go one step further and see who is using a tablet because GA now
takes screen size into consideration.

In the example below a fashion retailer is tracking three moments: acquisition, behaviour and
conversions using GA data. This simple framework can give useful insights if used consistently
over time.

Data from a three-month sample All devices All devices Mobile Mobile
(fashion retailer) (Country A) (Country B) (Country A) (Country B)
Acquisition (visitors) 6,300m 5,500m 29% 29%
3.19 3.17
Behaviour (average visit duration) 4.1 minutes 3.58 minutes
(average) (average)
Conversions (number of transactions) 75,000 69,000 13% 12%

The main findings from the table above are:

 Acquisition coming from mobile represents 29% in both countries where this commerce
operation is taking place.
 Mobile tends to have a lower average visit duration when compared with the results given for
all devices.
 Conversions represent 13% and 12% (country A and B respectively) of all transactions.

Within the C-suite of any business, the fundamental question being asked is why the things that
are happening are occurring in that way. The answer is that you can see what you have done in the
past and use data to tell you what is happening and predict what is going to happen.

The creation of a superior customer experience is the bottom line to all retailers that are not
competing only based on price. Two trends are becoming clear:

 Many companies are creating a single customer view of their customers complemented by a
multichannel strategy. Revenues can increase from 10% to 40%.
 Companies are increasing the value of their customer interactions (for example, using social
media) to connect, engage, increase share of wallet and average customer spend. Increase in
revenues is more difficult to measure. This trend is highly dependent on a good voice of
customer strategy.

Mobile Web Design and Development Best Practice Guide Page 39

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Voice of customer using mobile

Voice of customer is the term used to define the stated and unstated needs or requirements of the
customer. It can be captured in a variety of ways:

 Direct discussion or interviews

 Surveys
 Focus groups
 Customer specifications
 Observation, warranty data, field reports, complaint logs, etc.

This data is then used to identify the quality attributes needed for a supplied component or
material to incorporate in the process or product.

In the search for a consistent personality across channels, multichannel brands are putting their
values at the centre of everything. Questions like “how should the brand ‘behave’ in terms of
range of products, price, supply chain and services?” are common areas for voice of
customer analysis.

From a business perspective, the focus on understanding the customers by listening to them and
then using the information to market differently, sell differently and support differently as well as
redesign processes is becoming a key aspect for all retailers. Because this is still an immature
market a lot of money can be wasted on the wrong tools for your business.

Many organisations believe that if they just plug in an analytics package, the software will
immediately deliver insights about their business. Unfortunately where companies often fail is
that they do not have enough resources and assume they can just plug it in.

Outsourcing analytical skills to consultants may be a good solution but you should guarantee that
the expertise can be handed over to your internal resources once you are prepared to have it in-
house.

Primary data collection

Overleaf is an example of voice of customer applied to a framework in order to define gaps in the
service offerings. These results are based on a survey applied to a group of 50 customers who were
using mobile in-store. The survey was applied using a panel sample with rich profiling
capabilities. The sample was triggered via GPS technology to target specific locations, in this case
London.

Mobile Web Design and Development Best Practice Guide Page 40

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Three brands are compared in terms of product range, price and supply chain, by considering the
number of services as a metric to define the multichannel level each brand belongs to.

Brand number 1 represents the brand we want to analyse, brands 2 and 3 are competitors that
were chosen because of their similar brand values (assumption based on a previous study
designed to analyse brand perception).

After a quick gap analysis the key points for BRAND 1 are the following:

 Superior than BRAND 2 in range and BRAND 3 in supply chain

 Similar to BRAND 2 and 3 in price
 Similar to BRAND 3 in range
 Worse than BRAND 2 in supply chain
 More multichannel than BRAND 2 and less multichannel than BRAND 3

A common source for data collection comes from your transactional website. It is worth knowing
that leading ecommerce sites are using tools like Qualaroo, Qualtrics, Foresee surveys, UserZoom
etc.

If you know why users are visiting your website, you know if the site is able to meet their
particular needs. Voice-of-customer studies based on the tools mentioned above are generally
able to cover the following aspects:

 What are users doing on your website.

 What percentage of users are successful (depending on the goals set up for your current
website).
 What causes unsuccessful visits (bounce rate).
 What aspects are preventing online conversions.
 Are the conversions taking place through another channel?

Mobile Web Design and Development Best Practice Guide Page 41

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
  What is the customer satisfaction level after visiting the website?

3.5.3. Mobile testing

The role of testing is to ensure that as many problems as possible are caught before the
functionality goes out to the customers, which in ecommerce means potentially anybody who goes
online. In today’s business climate where the end user is more empowered than ever before, the
importance of getting it right the first time cannot be understated. This is becoming ever more the
case with mobile technology where the advent of smartphones, mobile websites and apps is on the
increase.

The more devices you can test your website on the better

One important takeaway is that you must monitor your own site usage and, based on the results,
define your priorities for mobile testing. A dangerous assumption to make is that everyone’s
traffic is dominated by iOS – yes, iOS is a dominant player but there can be variations.

There are four basic steps to follow for all webpages and to effectively test mobile and desktop
browsers:

1. Use HTML validators – the HTML doesn’t have to be 100% valid but knowing what errors
exist is the first step to make decisions and avoid problems before going live. There are easy to
use validators for HTML, CSS, XHTML, RSS, P3P. Once you have a valid code, use an
accessibility validator to make sure your page is accessible to search engines and people with
disabilities.
2. The next step is to test your website in all browsers. Download and install Firefox,
Chrome, Safari, Internet explorer and Opera. A website may look good in Safari and
completely broken in Firefox.
3. Use plugins like web developer tools to resize your browser window to different pre-set
sizes and confirm how your website looks on smaller mobile screens.
4. Test the website on physical devices (ideal), although you can use an emulator instead.
Emulators are not ideal for testing on mobile but if they are the only option, they are better
than not testing at all. There are computer desktop emulators for Android and iPhone/iPad.
– Android – the emulator is available in the developer’s kit.
– iPad and iPhone – included in the iOS developer kit (only works for Macintosh).
– BlackBerry – there are several options and they only work on Windows.
– Windows 7 phone – this is part of the Visual Studio IDE.

Mobile-specific behaviour
“Testing on a desktop client these days is no longer enough. Just as websites can exhibit different behaviour,
depending on the browser, behaviour can (and must) widely differ between desktop and mobile. It is therefore
imperative that mobile testing does not just duplicate that of desktop, but covers mobile-specific behaviour such
as touchscreen-based operations, turning through 90 degrees, layout consistency checks, readability and error
trapping.”
Ian Crawshaw, QA Test Engineer, Neoworks

Mobile Web Design and Development Best Practice Guide Page 42

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
3.6. Marketing challenges and opportunities
Consumer confidence

Only 4% of people say mobile is their main device for purchasing. The reason why the other 96%
of people don’t use their mobile as their main device to purchase is perhaps due to site
functionality, the fact that the website doesn’t suit use on mobile and that purchasing on a mobile
is often deemed less secure than other methods. Look to make mobile payments easier and more
secure to instil consumer confidence30.

Personalising and merchandising

The choice between responsive, adaptive and mobile-specific websites can impact your ability to
effectively personalise and merchandise your site. The objective of the user on each device may
differ and with it the content which you want to serve your visitors.

Responsive works well if your personalisation and merchandising needs are the same across
devices, but if there is a distinct difference in the intent, then serving dedicated mobile content
with a bespoke experience may suit your needs better and allow you to better meet your device-
specific goals. This is also where adaptive design may also become a viable option, as for certain
areas of the site where bespoke, device-specific content/functionality is required, alternative
templates can be served to the user.

Adaptive and mobile-specific approaches are also recommended when dealing with certain
promotion-specific landing pages. This is only the case when you have pages that are purely
focused on your mobile users and not relevant to those on desktop. Using a responsive approach
here could lead to some compromises having to be made in order to create a responsive landing
page that isn’t actually required on desktop. Focusing efforts on a mobile-specific page, based
around the intent of the mobile user, is the approach that will have the best chance of conversion.

Off-site marketing

There is no ‘one size fits all’ that works for every direct channel. From an off-site marketing
perspective, the key focus should be on search as opposed to display or shopping, as search
generally contributes between 60% and 70% of a retailer’s digital revenues.

Paid search

When looking at paid search, campaigns are significantly easier to manage under responsive
conditions because there is one single URL to publish for each campaign. The challenge however
is that responsive sites typically drive a lower conversion rate than desktop, limiting your reach in
the PPC landscape. This is a major challenge for mobile paid search, when you can be limited to
three ad spaces.

Natural search

When we look at the opportunity within the natural search space, retailers who have a mobile-
specific site do not tend to rank as well as retailers who have a responsive site.

This is due to the following three reasons:

1. Google prefers sites that only use one URL, which works across all kinds of devices (desktops,
smartphones and tablets).

30 Hitwise (January 2014)

Mobile Web Design and Development Best Practice Guide Page 43

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
2. Having a single URL for your desktop and mobile content makes it easier for your users to
interact with, share and link to it.
3. SEO value and authority goes to the same page, increasing the link authority of the site rather
than diluting this across many pages.

So the challenge here is the balancing act of doing right by Google but still ensuring a mobile
customer gets the best possible experience once they land on the site.

A key challenge within natural search is how to serve engaging content that has been developed
primarily for social sharing. This includes content such as infographics which, if served in a
responsive manner, will not be easy for a user to consume. The net impact of this will be that the
content is less likely to be shared, potentially affecting the site’s link equity and natural search
rankings. One way to approach this issue would be to build mobile-specific pages for the research
and brand areas of your site and leave the ecommerce section of your site responsive.

When looking at paid and natural search together, rather than in isolation, the biggest challenge
faced is that a responsive site does not support the nuances of how people search by device. It’s
widely known that a mobile user is more likely to use shorter query strings, search by location and
price vs. a desktop user. This has the potential to limit your search reach for an ever-growing
market and impact on the quality score of your paid search campaigns.

Based on the above there are advantages to leading with a responsive site, while tailoring certain
areas of the site specifically to support mobile search campaigns.

Landing page flexibility

Customised landing pages for different marketing channels can help to improve performance.
This is exactly the same message for mobile. The only restriction is the cost benefit of this and to
what level of customisation you implement.

From an off-site marketing perspective, customised landing pages would best support the
following channels:

 PPC – to support product areas which should work well for mobile customers, however are
failing to meet the required conversion rate to allow you to bid in the landscape.
 Display – pages developed specifically for PPC should be tested in display to understand
whether this can be make the channel more viable. ROI is currently significant lower than its
desktop equivalent.
 Affiliates – potential to offer mobile-specific affiliates optimised pages with exclusive offers to
support online and in-store sales.

Building a mobile site with off-site marketing in mind

Below are some considerations for effective off-site marketing:

1. Don’t limit yourself to a responsive site for paid search.

Make sure that there is the ability to develop custom pages. These could also support natural
search ranking improvements for keywords, which would not necessarily be optimised for in
the responsive site.
2. Site load time is critical for search and users.
As mobile market share continues to grow, the average speed of your site will need to be
increased, potentially compromising content which you would serve to a desktop user.

Mobile Web Design and Development Best Practice Guide Page 44

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 3. Ensure cross-device tracking is implemented before you go live.
There are providers in the marketplace including DC Storm and Google Analytics who are
able to measure the full value across all devices, to ensure you are investing your marketing
budgets in the right places.

3.7. Key technical considerations

Most companies are launching, building or buying mobile apps and websites but for those pieces
to fit into the greater whole, planning is required. Companies must take into account how
mobility fits into the overall business strategy.

Analysts are telling us that within the next year or two mobile devices will replace the PC as the
primary device for accessing the web and that m-commerce revenues will represent around 10%
of total global ecommerce revenue by 2015. These predictions have persuaded ecommerce
merchants to invest heavily in mobile, with 28% of top UK retailers already using or in the
process of developing m-commerce offerings.

The most important decisions you need to make in the early stages are related with devices and
apps.

Devices

Prioritise rollout of features on devices that will deliver the most benefit to the greatest number of
customers. Consumer tolerance for errors in mobile applications and websites appears to be even
lower than for standard websites. Losing the confidence of customers by delivering low quality
mobile functionality is a significant risk of over-stretching.

Good usability is essential and that means that everything targeted to a tablet or smartphone
should be accessible via finger tap, especially when there is a form or any type of interaction with
the user.

Many smartphone and tablet devices have a built-in GPS facility. Companies are making use of
location information to provide directions to their physical stores, present territory-specific
product catalogues and restrict content based on local legislation.

Apps

M-commerce means an app, doesn’t it? The answer is probably not and unless there is a good
reason to build an app, it’s an expensive endeavour best avoided. The alternative is to build a
mobile website and the latest mobile-friendly features in HTML5 have made pretty much
everything that is likely to be required for an m-commerce site available directly through the
browser. This includes access to location information and the camera on devices that have these
available.

3.7.1. Technology brings businesses closer to customers

A balance between commercial success against objectives and how the customer experience has
been improved are the key aspects of a mobile project.

While mobile retail is taking centre stage, brick-and-click retailers still have a long way to go.
Consumers expect mobile to supplement their in-store shopping experience but many companies
aren’t delivering features like browsing inventory or ‘My Account’ across devices. The lack of
fundamental features contributes to negative reviews for many brands.

Mobile Web Design and Development Best Practice Guide Page 45

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
A good example is with basket and wishlist synchronisation. Surprisingly, not all retailers ensure
the last state is maintained across devices, or automatic rules are used to overwrite content
without giving the user choice.

For example, a logged-in user has created a shopping basket on the desktop site. Later in the day
they are browsing the site as a guest on their iPad on the commute home, having received a text
from their friend reminding them about this weekend’s birthday party. They decide to buy a gift
for their friend by adding to the shopping bag on the tablet, then go to checkout. At checkout they
log in and the site automatically updates their basket, removing what was in it from their previous
desktop visit. Is this good service? Logically, you would expect the platform to recognise both
baskets and offer the option to merge or keep only the items still required.

Given the difficulties in this area, it’s no surprise that some companies are turning to integrators
and implementers to help them customise and integrate their ecommerce platforms. The
Econsultancy Technology for Ecommerce Survey Report shows that a quarter (27%) of
organisations have used a systems implementer or integrator and that a further 9% are planning
to.31

Mobile integrated into a multichannel strategy

A good understanding of the customer journey facilitates the role that mobile can play in
connecting the other channels or activating them. User behaviour can often vary significantly
across devices (e.g. mobile visits are often task-specific rather than general browsing), therefore
you shouldn’t assume that there is a uniform user experience solution to be implemented.

Integrations that would enhance the mobile experience are normally the integrations made for a
traditional desktop website with little tweaks.

Integrations include:
 Order management system
 Customer service module
 Enterprise resource planning (ERP)
 Customer relationship management (CRM)
 Product catalogue
 Payment systems
 Delivery companies
 Merchandising tools

…to name just a few.

The move to an increasingly mobile world is creating new players and new opportunities. At this
moment the question is whether to prioritise an m-commerce solution over a traditional PC-
targeted ecommerce website. Customers tend to carry their mobile phones with them at all times
and technologies like near field communication are promising to be very convenient, which will
probably be enough to make it successful.

The growing number of touch points is generating enormous quantities of information. IDC
suggests that by 2020, businesses will require 44 times more data storage than in 2009.
Organisations are looking to improve performance and mitigate risk with actionable insights
given by business intelligence methodologies. But in few years’ time even more challenges and
changes can be expected when the generation that has grown up with all these new social
technologies is old enough to shop.

31 http://econsultancy.com/reports/technology-for-ecommerce-report

Mobile Web Design and Development Best Practice Guide Page 46

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
3.7.2. Cheat sheet
When planning your requirements for mobile do not forget the technical side. The table below
gives an indication of the technical aspects that you need to consider when writing a request for
proposal (RFP).

Consistency Content should be accessible on multiple devices irrespective of differences in

presentation capabilities and access mechanism.
Work around deficient There are differences in interpretation between browsers and there are differences
implementations in implementation.
Keep the URLs of site Instead of requiring users to type http://www.example.com/index.html, allow
entry points short http://example.com.
Navigation Take into account the balance between having too many links on a page and
asking the user to follow so many to reach what they are looking for. Provide
consistent navigation mechanisms.
Streamline navigation for mobile to reduce clutter and focus on the most relevant
tasks/activities that mobile users are interested in.
Link target Identify where a link leads so users can make an assessment of whether following
identification it will be of interest to them and the size of the resource.
Link style and size Ensure links are touch-friendly and large enough to be usable e.g. don’t just copy
over the desktop text links.
Page content Ensure that content is suitable for use in a mobile context. Use clear and simple
language. Limit content to what the user has requested.
Page size Divide pages into usable but limited size portions. Ensure that the overall size of a
page is appropriate to the memory limitations of the device.
Scrolling Limit scrolling to one direction, unless secondary scrolling cannot be avoided.
Making use of native mobile transitions can help e.g. swipe for horizontal scrolling
through images.
Graphics Do not use graphics for spacing. Do not use images that cannot be rendered by the
device.
Colour Ensure that information conveyed with colour is also available without colour.
Ensure that foreground and background colour combinations provide sufficient
contrast.
Structural elements Use features of the markup language to indicate logical document structure. Do not
use tables unless the device is known to support them.
Measures Do not use pixel measures and do not use absolute units in markup language,
attribute values and style sheet property values.
Character encoding Ensure that content is encoded using a character encoding that is supported by the
device.
Error messages Provide informative error messages and a means of navigating away from an error
message back to useful information.

For more details about mobile technical requirements visit the World Wide Web Consortium
(W3C)32 site.

32 http://www.w3.org/

Mobile Web Design and Development Best Practice Guide Page 47

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Make a data-driven not fashion-driven decision
“Firstly, you’ll have some clear proof points from your analytics tool to show the cost of not making the shift to
mobile, and how that cost will grow in future.
“Secondly, ensure your senior stakeholders clearly understand what responsive web design (RWD) is. Take some
time to explain it: give them a demo, using multiple devices, of a website using RWD, and compare it against a
site using an adaptive approach. Then quantify the benefits of RWD (e.g. SEO, UX consistency, streamlined
content management) and set this set against the projected costs and effort to deploy it (e.g. the time and effort
required to re-code your front-end).
“Finally, review your entire development roadmap and see where your deployment will fit best – you should
consider how it aligns with other planned initiatives before defining your timing plan.”
Joe Ballard, Director of Business Consulting, Hybris

3.8. Key takeaways

The bottom line is that people use devices differently, so in order to give you the best chance of
commercial success you have to really understand how people are interacting with your site. If
you can create an experience that’s better tailored towards your visitors and provides them with
the best possible experience on whichever devices they are using, then they will be much more
likely to convert on your site and it gives you the best possible chance of maximising sales and
revenue, justifying the investment.

So, remember:

 Listen to your (mobile) customer.

 Tailor site objectives to customer objectives.
 Align to users’ behavioural patterns.
 Don’t just go responsive as it’s ‘what you should do’; ensure there’s a clear need and that it’s
best for the user (and therefore you).
 Have a clear business case.
 Make the most of device-specific functionality.
 Ensure mobile KPIs and objectives are established.
 Treat mobile as part of the multi-platform.

Mobile Web Design and Development Best Practice Guide Page 48

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
4. Responsive Web Design
Contributors
This section was written by Mark Slocock, MD at GPMD (@mslocock), Stuart McMillan, Deputy Head of
Ecommerce at Schuh (@mcmillanstu) and Maria Morais, Digital Commerce Consultant at Neoworks
(@ceumorais).

The idea behind responsive is simplicity and can be expressed simply: a single website can be
designed such that it works on all screen sizes. No mobile-specific site or templates, no more
applying changes to multiple sites. In many ways it’s not something new; when the very first
webpage was made live by Sir Tim Berners-Lee, it didn’t have a fixed width and flowed to fill the
available space. It would work pretty well on mobile, presenting the same information as if you
viewed it on a bigger screen.

In this section we discuss the commercial and technical implications for adopting a responsive
web design approach to site development and provide an interesting case study from Schuh.

How to tell if a site is responsive?

“I like using Matt Kersley’s quick and easy tool (http://mattkersley.com/responsive/) for viewing how a website
looks on different devices to see if it’s using responsive design. You can quickly see if the core elements like the
navigation and page layout change to suit the device size. It’s a more elegant way to look at multiple sites quickly
that ‘squishing’ the page in the browser. Take a look at the two example sites below for responsive vs. non-
responsive.”

Mobile Web Design and Development Best Practice Guide Page 49

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 James Gurd, Owner, Digital Juggler

4.1. What does ‘responsive’ mean?

Responsive design has become a catchall term for “a single website that resizes to fit the screen
size of the device it is viewed on”. It is commonly conflated with techniques such as adaptive
design (covered in Section 5: Adaptive Web Design) or RESS (Responsive Web Design + Server
Side Components), which is discussed in this section.

There is no one answer which is correct in all circumstances and undoubtedly the best solution
will include aspects of all three. These techniques should not be confused with the overall
business objective, they are merely tools to help you meet those objectives.

So what is responsive?

Google Webmaster Tools describes it as this:

“Responsive web design is a setup where the server always sends the same HTML code
to all devices and CSS is used to alter the rendering of the page on the device using
media queries”.

When Ethan Marcotte introduced the term “responsive design”, he also introduced another
important idea: give mobile users the same functionality as their desktop counterparts, their
priorities really aren’t that different.

So, if the first webpage fitted on many devices, why do we have a problem? The answer mostly lies
with the way websites have been designed for many years. Designers typically came from print
backgrounds; they were used to thinking about the physical size of the document. A physical page
has fixed dimensions, if you’re reading a magazine on the bus or at your desk, the page is always
the same size. Designs were made to fit to certain pixel widths, they were easier to imagine, they
were easy to print out and show to a client.

Clients have typically wanted certainty about a design; they want to know that what they see on
the screen in front of them (or printout) is exactly what the customer will see. That would be fine

Mobile Web Design and Development Best Practice Guide Page 50

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
if the client was signing off a working prototype that could be resized but that almost never
happens. Typically the sign-off process works on flat screenshots. So how do you design for a
world of infinite variations in screen size?

Start from the position that all screen sizes should have functional parity, ensuring that all
customers can carry out all functions, agnostic of device and screen size. Also start from the
position that HTML is only designed to transmit structured information. HTML has nothing to do
with the look and feel of the page. That is the role of CSS.

Given this overall position, it’s then a question of how you make the same information
presentable and usable on different screen sizes. We’re not talking about devices here, as we want
to deliver the same functionality to everyone, we just want to make sure they get the best
experience for their screen size. This is where media queries come in.

Media queries are part of CSS and run in the browser. They allow CSS to be conditionally applied
to your document based on criteria such as screen size. In plain English, an example might be “if
the screen is bigger than 900px wide, the image used for the background should be a larger
version”. Another example of this might be the display of a headline; generally you might want to
constrain a long headline to, say, 600px wide, and allow it to wrap, to prevent it from looking
overly wide.

However, you might add a media query override for smaller screens, allowing the text to take up
100% of screen width. This would make better use of the limited space. You should still follow all
the standard best practice CSS, where rules are made as general as possible; however you then
add a number of screen size specific overrides, provided by media queries. The UX/UI design
implications for mobile web development are discussed in more detail in Section 7: UX/UI
Design.

Media queries lie at the heart of responsive design. However, there is a more fundamental
technique that should be at the heart of any good web design, responsive or not: fluid layout.
Traditional design would typically have a thought process like this: “The page is 1024 pixels wide,
I want this area to take up a third of the width, so it needs to be 341 pixels wide”.

This is great if everyone has browsers that are 1024 pixels wide. It would be much better if the
design was more flexible; if the width was set to 33% then it wouldn’t matter if the browser width
was 1400 pixels wide, the design would still hold true.

Working with percentage widths allows your design to work across a wide variety of screens.
However, this may start to break down when sizes reach extremes, like the small size of mobile.
Simply add media queries to make your fluid layout work well for mobile. In our 33% example
above, you might decide that when the screen is narrower than 900 pixels, you might want the
area to actually take up 100% and the overall layout to switch to a single column. Media queries
run on all modern browsers but if a significant portion of your audience uses old browsers, you
may have issues.

The simpler your overall layout, the simpler it will be to use responsive web design because there
will be fewer elements. This is one of the key benefits of thinking mobile first: get it right for
mobile screen sizes and then allow the site to expand as screen sizes expand.

What are the key benefits of responsive?

If the essence of responsive is simplicity, this is also its key benefit.

You’re producing a single HTML template for your page, which will be written in such a way
(using CSS media queries) that it will work on all screen sizes. Therefore, you only have one
template to change. You want to roll out a new feature and for it to be available to everyone? No
problem, that happens by default. You just need to ensure you design it in such a way that it can

Mobile Web Design and Development Best Practice Guide Page 51

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 work with any screen size. No more leaving the mobile site behind because it takes less traffic and
you can’t justify the cost in changing it. You don’t have a mobile site anymore, you just have a
website. You need to provide a new website for the smart TV market? You don’t need a new
website, you just need some additional media queries that will adjust the layout.

There is plenty of evidence that shows that customers often use multiple devices during their
shopping journey. You can see how consistency can be easier to achieve through responsive than
having separate, device-specific sites. It may not be important to you that all your sites are
consistent. In fact, you may have good reasons for wanting to present different experiences to
different devices, but if consistency of experience is important, then responsive gives you a head
start.

Another key benefit is SEO. It’s no coincidence that Google’s Webmaster Guidelines show a clear
preference to responsive design. As well as the reasons above, it helps eliminate duplicate content
issues where multiple sites are serving identical (or similar) content. It concentrates all that
search presence under one site/page. With such a clear statement from Google, this should only
be ignored with caution.

Finally, a benefit that is not to be overlooked is the increased development efficiency. Having one
set of templates takes a lot less time to manage and develop than having three templates (desktop,
mobile and tablet, for example). It will definitely take longer than changing one site but should
not be close to doubling the effort.

While there may be a lot to consider about responsive, the technology is well understood and we
are past the stage of early adoption. There are a few responsive problems left to solve (things like
serving the right image size), but there are many good workarounds. The challenges you face will
primarily be project management based, not technical.

4.2. Commercial implications and challenges

For those with an existing site it will be hard, if not impossible, to retrofit responsive to your
existing site. If your site is minimalist to start with and already uses a fluid layout then you may
be able to make a desktop site work responsively with mobile. However, the vast majority of sites
are neither minimalist nor fluid. If a total rebuild is out of your budget and you have an existing
mobile site, it may be practical to start with that site and allow it to expand upward for desktop.

However, for many the best option will be a new build for responsive. You’ll carefully plan the
information architecture, you’ll understand user behaviour and you’ll plan a site that works well
on a range of devices.

Before you get started, you’ll want to have a look at your web analytics data. Look at how people
are behaving on different devices and screen sizes. How big a proportion is your mobile traffic?
One would expect it to convert at a lower rate (perhaps as low as 50%) but if they aren’t really
converting at all, you have a problem. If you assumed that mobile traffic converts at 50% of
desktop on responsive, do you get enough mobile visits to justify a rebuild? What will that traffic
split be in a year’s time?

Use your current site on your mobile phone (via 3G). How bad is it? Even if you decide to go
responsive, are there any quick wins which could be implemented to see you through until the
new site goes live? If it takes nine months for the site to go live, you could be making more money
in that time. You also get the added bonus of increasing your understanding of how users interact
with you on mobiles, which you then feed into your new build.

Mobile Web Design and Development Best Practice Guide Page 52

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
4.2.1. People
Going responsive usually represents a major change in mindset; it’s typically a people problem,
not a technical problem. None of the techniques used to get responsive right are particularly
bleeding edge. Recognise that the people involved will be critical to the success of the project and
get it right upfront.

This may well be a project which is a year in the making, from inception through delivery to
remediation. It’s important that you plan for remediation; just hope that there is nothing too
critical to fix.

You’ll need a team who can deliver this. If you are the website owner it is unlikely you will have
the time to plan a new site. Do you have someone who can coordinate the project? If not, find
someone. They need to be able to dedicate a significant portion of their working week to the
project and they’ll need to be available for the length of the project. This person will gather user
requirements, organise project plans, analyse web analytics data and conduct user testing. They
will live and breathe this project, ensuring that you get a coherent and complete site.

They’re probably not going to be a web designer, so do you have a designer who can think in fluid
layouts, who can think mobile first but still produce a great desktop experience? Can they work
cooperatively with different stakeholders and not throw a fit if someone disagrees with their
design decisions?

Do you have the technical resources to build a really good responsive site? If your existing site is
built by an external agency, can they really deliver the goods? They are going to say ‘yes’ because
they want the work but are you convinced?

If they have already built responsive sites, really look at them. Do a proper audit of them,
everything from quality of HTML5 and site speed to cross-browser testing and accessibility
testing. It would be worth paying to have an external audit done of those sites if you are in any
doubt as to your ability to properly assess their quality.

If your site is built internally, now is the time to have a frank discussion with your development
manager. If there are not enough development resources with the skills required, now is the time
to find out. Recruiting developers can take a long time.

4.2.2. Research and development

When you’re confident that you have people in place to deliver the project, there are a number of
tools you will need to put at their disposal, which might cost you money. They will need to develop
a much more granular understanding of current user behaviour, first of all through web analytics.
How good is your setup? You may need to have your site analytics audited to ensure you are
measuring everything correctly. As an aside, if your analytics setup is not ideal, then that’s a
mistake you’ll not want to repeat for the new build.

Another cost will be user testing. Test other responsive sites, test your own current experience.
User-centred design will reduce the risk of producing a site that simply fails to deliver on your
commercial objectives.

These upfront costs and complexities may sound onerous but they are vital. There are many
efficiency savings to be made from using responsive design. However, you are putting all your
eggs in one basket. These pages that you are going to build have to work on all devices, you have
no safety net of mobile-specific templates. The risks of messing up the user journey for every
device type and screen size should not be underestimated.

Unless you are sure you can deliver a design that is flexible enough to work on all screen sizes
without reducing your conversion rate at all on any device, consider another option.

Mobile Web Design and Development Best Practice Guide Page 53

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 With that cautionary note in mind, should you decide to go responsive it’s a good choice! The flip
side of the risk is that you’re always making sure that your site works for as many screen sizes as
possible at once.

It’s easy to look at many of the market leaders who don’t have responsive sites and use them as a
reason not to. However, these big players have significantly different commercial drivers to most
of us. They may get a 0.1% increase in conversion which, given their volumes, might pay for
additional development time in a matter of weeks or a few months. In reality, most of us do not
have such complicated or sizeable digital presences. Look at the very best mobile ecommerce sites
out there; they are usually celebrated for their ability to deliver a complete user journey in as
simple a way as possible. If they can produce a great user journey on mobile, you can produce a
great responsive journey that also can expand upwards for larger screens.

4.3. Technical challenges

Building responsive websites using one code base to target multiple screen sizes and devices over
various connection speeds presents a number of challenges and considerations.

It requires a new approach to building websites, in many ways harking back to the days of dial-up
modems and basic browsers. In those days every byte mattered and optimisation was king but
with the dawn of broadband internet the focus on bytes and optimisation faded and we embraced
the possibilities that fast internet connections, hardware and modern browsers gave us.

Then along came the iPhone, which changed people’s browsing habits, as shown in the
introduction to this report. This required companies to provide an optimised experience on
mobile and tablet devices. It wasn’t until Ethan Marcotte’s seminal article, titled ‘Responsive Web
Design’33, in 2010 that designers and developers started to take multi-device compatible websites
seriously.

Shift to responsive web design

“Day by day, the number of devices, platforms, and browsers that need to work with your site grows. Responsive
web design represents a fundamental shift in how we’ll build websites for the decade to come.”
Jeffrey Veen, CEO and Founder, Typekit

Putting mobile and tablet experience first requires changing not only the process of developing
these sites but also our approach to performance. In this section we cover the impact on process,
image and media handling, navigation, coding and quality assurance. These areas present the
biggest technical challenges for building responsive websites.

Design mobile web experiences

“It’s clear that mobile is an exciting new opportunity for many of us. But if you’re coming from a desktop web
design background, how do you make the transition to designing mobile web experiences? While a lot of your
existing tools, experiences and skills will still apply, you’ll probably want to start thinking a bit differently about
organisation, actions, inputs and layout.”
Luke Wroblewski, Author of Mobile First

33 http://alistapart.com/article/responsive-web-design

Mobile Web Design and Development Best Practice Guide Page 54

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
4.3.1. Technical impact of building a responsive website
The technical challenges for building responsive websites are centred around four main areas:

 Building the code base

 Performance on mobile devices and slow internet connections
 Delivering images and media optimised for the device
 Limitation of platforms and frameworks

Section 4.4: Implementation challenges goes into detail on how to build a responsive code base
but we’ll cover performance and media below.

Performance

Optimising for mobile first requires understanding the devices and internet connections being
used to access websites.

Don’t assume that a mobile device will have a slow internet connection and a desktop will have a
fast connection. Mobile devices are just as likely to be used at home over Wi-Fi as they are when
we’re out and about and, likewise, laptops could be using a 3G connection (although admittedly
this is a less frequent occurrence).

This means that as far as possible solutions to the performance issue should work across devices.
Research shows34 that there are certain constants for an application or webpage to feel
responsive:

Delay User reaction

0 – 100 ms Instant
100 – 300 ms Slight perceptible delay
300 – 1000 ms Task focus, perceptible delay
1 s+ Mental context switch
10 s+ I’ll come back later…

Ilya Grigorik from Google has done some interesting work in this area and his talk on optimising
the “Critical Rendering Path for Instant Mobile Websites” at the Velocity Conference in June 2013
is a must watch35. It’s over 40 minutes long but well worth the time investment.

To summarise his recommendations, the aim is for a less than one second load of the visible area
of the screen on mobile. In order to meet this target, you can have a maximum of one http request
and download 14kb of data. This is a big challenge, which for most websites is unachievable, but
that doesn’t mean you shouldn’t strive to attain this.

In order to reach this goal all the CSS and JavaScript required to render the viewable part of the
page should be inline in the head of the HTML file, with other files required loaded in the body of
the page.

In addition to optimising the loading of the visible page, you should also consider how you
structure your CSS. It has long been considered best practice to combine all your CSS code into
one file to save making multiple http requests to download files. However, this means that for

34 http://www.nngroup.com/articles/response-times-3-important-limits/
35 http://www.youtube.com/watch?v=YV1nKLWoARQ

Mobile Web Design and Development Best Practice Guide Page 55

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 each page a majority of the CSS is not required, so the new recommendation is to download all the
CSS required for the current page only and do this in one request.

Another recommended technique to make your pages appear to load faster is to flush the
document early. Flushing is when the web server sends the initial part of the HTML document to
the browser before the entire page is ready. For this to work you need to make sure that for each
flush block of HTML that can be rendered, for example, send the header then flush. Then you
send the next block and flush and so on.

This is very hard to achieve as problems arise when output is buffered and proxies or anti-virus
software interfere. However, get this right and perceived speed improvement could be significant.
Section 4.4: Implementation challenges goes into more detail on the coding required for some of
these techniques.

Images and media

Images and media are a key consideration in responsive design because mobile devices may well
be accessing a website over a 3G (or slower) connection, which offers speeds of up to 384kbps.
This means that images need to optimise for loading on devices using slower connections.

There are several techniques available to optimise images, outlined below.

Responsive images
The W3C set up a committee to work on a specification to solve the problem of images in responsive: the group is
called Responsive Images36. They are working with the major browser vendors to outline a specification for
responsive images.
Currently there are three possible solutions on the table:
 The <picture> element37 allows developers to declare multiple sources for an image using media queries.
 The srcset attribute38 extends the <img> tag and allows developers to specify different URLs to load at
different screen resolutions.
 Client-side hints use http headers to send information indicating the client’s screen resolution, allowing
the server to serve the appropriate image.
As of February 2014 the browser vendors have finally agreed to support the <picture> element 39 and you can use
picturefill JavaScript ployfill40 to start using the picture element format now.

Adaptive images
Matt Wilcox created Adaptive Images 41 back in 2011. The approach is to detect the screen size of the user visiting
a website and automatically create, cache and serve an image appropriate to the screen size.
This is achieved using a web server config file and a PHP script to detect if the image needs to be resized. If the
right sized image already exists, it serves it directly from the cache. If not, it is created on the fly, serves and
caches for the next request.
This approach will work on existing websites and is relatively easy to implement, providing a quick and low-cost
solution to the image problem.

36 http://responsiveimages.org/
37 http://picture.responsiveimages.org/
38 http://www.w3.org/html/wg/drafts/srcset/w3c-srcset/
39 http://www.lukew.com/ff/entry.asp?1851
40 https://github.com/scottjehl/picturefill
41 http://adaptive-images.com

Mobile Web Design and Development Best Practice Guide Page 56

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Adaptive images (cont.)
However there are some limitations to this approach: it won’t work if you use a CDN and if the JavaScript cookie
is not written fast enough, the smallest version of the image will be served.

Progressive jpegs
Progressive jpegs are a series of scans of increasing quality. A progressive jpeg will render a low-quality
version of the image quickly and the image quality will improve as each scan is layered on top of the other.

This means that something is loaded quickly with the space required for the image calculated faster and prevents
the page ‘jumping’ around as images load.

The result is that the page is perceived to load faster as you see the image quicker; the perception of speed is all-
important.

However, there is a brand consideration because inevitably the initial lower quality image isn’t as sharp as a
high-resolution version. For brands where the image is king, this may be not be ideal. It’s important to weigh up
the pros and cons of each approach.

SVG images
The Scalable Vector Graphics image format can be used for logos, icons and simple graphics. Vector data means
the files will be small in size and scale well across all resolutions, including retina.

A note on mobile carrier compression

It’s important to note that some mobile carriers, but not all, will compress and cache images requested over their
network. If you are compressing and optimising images on your site you might want to stop carriers doing this to
prevent your images appearing pixelated.

For more information on this see Kornel Lesiński’s blog post on mobile ISP image recompression42.

4.3.2. Creating a responsive code base

Broadly speaking there are two options, though there may be many paths to achieving these.

Converting an existing non-responsive website into a responsive site

Converting an existing non-responsive website to a responsive one is difficult and in many cases it
is usually quicker and easier to start again with a new code base (see Building a responsive
website from scratch below for a detailed explanation as to why this is so).

There are some exceptions. For example, if the existing code base uses a responsive framework
such as Twitter BootStrap but isn’t yet responsive, you can convert the site to being responsive in
a time efficient manner. However, in the vast majority of cases this isn’t going to be the case.

42 http://calendar.perfplanet.com/2013/mobile-isp-image-recompression/

Mobile Web Design and Development Best Practice Guide Page 57

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 Building a responsive website from scratch

Responsive design calls for a new approach to the design and development process, one that
allows for multiple devices and screen sizes in an efficient and cost-effective way. It’s simply not
practical or an efficient use of time to design in the way most websites were built in the noughties,
with Photoshop files being passed to developers to convert into HTML and CSS.

There are too many screen resolutions, devices and user experience issues to consider. Generally
an agile methodology is a much better fit for responsive web design than waterfall, allowing for a
short feedback cycle and regular reviews and demos. This means everyone is closely involved in
the process and able to make informed decisions based on working examples.

There are many different approaches to the process, with many designers, developers and
agencies publishing articles about their approaches to planning and building responsive websites.

Project methodology

Most approaches follow a similar pattern of discovery, design and UX, development, QA and
deployment. Each phase has implications for the technical aspects of building responsive
websites.

Useful reading material

A new responsive design process
http://www.creativebloq.com/responsive-web-design/new-responsive-design-process-2132848

An agency workflow for responsive web design

http://www.elezea.com/2013/09/responsive-design-agency-workflow/

Design systems: building for the future

http://mediatemple.net/blog/tips/design-systems-building-for-the-future/

Discovery

Discovery is vital to any project because a clear content strategy is essential before the technical
implementation starts. This will define the priority of the content, which allows developers to set
the order that content is displayed at each breakpoint. Put content first, write content before
starting the design and always ask: why are we using this content, who is the content for and what
is the business case? On mobile it’s prudent to streamline content as much as possible and this
means casting a critical eye over what is being included.

Thinking about content first and its priority is an essential step in building a future-proof website.
Steve Fisher and Alaine Mackenzie cover this well in their article “A Responsive Design
Process”.43

Design, UX and prototyping

Wireframing and UX form an important part of the responsive design process and help visualise
what you’re building. However, while wireframes can show the content priority and layout at each
breakpoint, they can’t show the transition between each point. For this reason it pays to get
working in the browser early on.

43 http://www.creativebloq.com/responsive-web-design/new-responsive-design-process-2132848

Mobile Web Design and Development Best Practice Guide Page 58

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
When designing a responsive site, a key consideration is how the navigation and content will work
at the various breakpoints (notice we said content, not layout). Adjust the layout for each
breakpoint, using the content priority as a guide to developing the page hierarchy.

Style tiles44 are popular in responsive design and a good way of visualising designs showing fonts,
colours and interface elements. Taking a style tile and implementing a component style guide in
HTML/CSS puts all the elements to be used in a website on one example page and will show the
responsive behaviour. Elements include:

 Colours
 Fonts (headings, paragraphs, lists etc.)
 Multi-column layouts for text
 Form elements
 Buttons
 Messages
 Tab or accordion interfaces
 Slideshows
 Product image slideshows
 Product image zooms
 Menus
 Filtering / layered navigation
 Pager controls

For each component the style will define how the component will react to changes in width and
interactivity on all devices; for example, how the slideshow interacts on a touch-enabled device.

Once the style guide is complete, we move on to working on prototype pages. In early 2014 Ara
Abcarians published an article called ‘Design Systems: Building for the Future’45, which
crystallised the idea of building re-usable components rather than whole pages.

Building on a page-by-page basis, often with different developers working on each page, can
result in different code to style the same elements, which is unnecessary code bloat. By developing
the style guide first and then building individual components for use across the website, the code
is optimised for re-use and there will be no duplication, which is good for performance and
ongoing maintenance.

While strictly speaking this approach is not specific to responsive design, it does work well,
allowing for early prototyping and interaction design directly in the browser.

If you’re building using a platform such as Magento, WordPress, SilverStripe or Drupal, you can
build your style guide and design systems directly on the platform. This allows fully working
prototypes to be built for review and feedback.

If you’re not working with a platform, building static HTML prototypes of example pages is the
best way to demonstrate the responsive aspects of the design to stakeholders.

The prototype is then developed into the final website during development. For clarity, in this
instance a prototype is a fully designed working page or website (if using a platform) and not an
early stage or grey box prototype.

44 http://styletil.es/
45 http://css-tricks.com/design-systems-building-future/

Mobile Web Design and Development Best Practice Guide Page 59

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Figure 14: Example components for design systems

Development

An agile approach to development generally works best when building a responsive website. By
this we mean regular demonstrations of the working website with short feedback loops, which
allows for stakeholders to see the responsive elements of the website and how the user experience
works. An iterative approach to development allows for feedback to be incorporated.

The biggest impact to development is two-fold:

1. Creating the code base (see Section 4.4: Implementation challenges for a detailed overview of
the impact on the code base).

Mobile Web Design and Development Best Practice Guide Page 60

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 2. Getting the page to render quickly on slow internet connections (we have outlined the impact
on performance and images in the previous section, and we also cover the coding details in
Section 4.4).

It’s important to note that the performance techniques outlined in this document are what would
be done in an ideal world. However, we recognise that it is not an ideal world and often
compromises have to be made, so start with the code base and have a plan for images – using
progressive JPEGs is a good starting point.

Be mindful of the critical rendering path for mobile devices but accept that this will require a
significant investment to achieve. It’s usually pragmatic to adopt a phased approach to reaching
rendering nirvana – set out all the elements you wish to implement, estimate the time and cost of
doing them, then prioritise based on impact. Phase the elements into an ongoing optimisation
roadmap and put performance monitoring behind it to measure the impact of improvements.

By adopting this approach, you don’t compromise on the long-term quality of the mobile site but
you give yourself a realistic development roadmap to work towards and can assess the impact of
each improvement and fine-tune before committing to the next set of changes.

Quality assurance

Cross-browser compatibility was already time-consuming even when we were only dealing with
desktop browsers. Add to this tablet and mobile versions and you have a big impact on both
development and QA, particularly if you are building a responsive website for the first time.

Be mindful of this and allow extra time for browser testing, especially if you are building a
responsive website for the first time.

4.3.3. Common mistakes and pitfalls

We’ve covered a number of common mistakes of pitfalls already: dealing with images, optimising
the project process for responsive design and allowing more time for cross-browser testing. These
are some of the big challenges for responsive design and the next section will outline best practice
for creating and maintaining a responsive code base.

Some other elements to consider are:

1. Headers and navigation – a responsive website will usually have two different menu systems:
one for smaller screen sizes and one for larger screen sizes. When designing the menu system
you will need to consider the priority of the items contained in the header and always put your
users first when designing the user experience for small screen devices.
2. Tables – tables can be difficult to design for small screen devices, but there are a number of
solutions out there.46

Dos and don’ts for developers

 Do build in the browser early and present prototypes to clients.

 Do consider building your website using design components or widgets.
 Do think about content priority for smaller screen sizes.
 Do consider using a mix of responsive and adaptive techniques to deliver the optimum
experience for all users.
 Do allow more time for cross-browser testing.

46 http://css-tricks.com/responsive-data-table-roundup/

Mobile Web Design and Development Best Practice Guide Page 61

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
  Do get feedback from stakeholders regularly.
 Do remember that your content is fluid in-between your defined breakpoints.
 Don’t try to present images of each and every page for sign-off.
 Don’t hide site content from small screen devices.

4.4. Implementation challenges

4.4.1. Creating a responsive code base
Essentially a responsive code base is a collection of coding techniques which, when combined,
allow a site to respond to the size of the browser viewport. The main components are:

1. Viewport meta tag and CSS rule

2. CSS box-sizing rule
3. Responsive CSS grid systems
4. Media queries

Viewport meta tag and CSS rule

This is a simple thing but ignore it at your peril. By default mobile browsers will serve up a
zoomed out ‘desktop’ version of a webpage unless instructed otherwise. This provides a poor user
experience for mobile visitors and makes the page difficult to interact with, without lots of painful
zooming and scrolling (at which point most sane visitors give up and find a competitor that
understands mobile UX).

We need a way to disable this scaling effect; step forward the viewport meta tag:

<meta name="viewport" content="width=device-width, initial-scale=1">

 ‘width=device-width’ sets the viewport width to the actual width of the device.
 ‘initial-scale=1’ means display the content at a scale of 1:1, so no zooming will occur.

Mobile Web Design and Development Best Practice Guide Page 62

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 Figure 15: Impact of using the viewport meta tag

So you can now sit back and relax surely?

Not yet you can’t! Change is in the air. In actual fact the viewport meta tag is not a valid W3C
spec. It was introduced in mobile Safari and subsequently adopted by other vendors. The issue is
that it’s mixing up presentational instructions that really should be a part of your CSS. W3C has
therefore introduced the @viewport CSS rule:

@viewport {
width: device-width;
zoom: 1.0;
}

The main downside to this at the moment is that @viewport is currently only supported by
Internet Explorer 10+ and Opera but we expect to see other vendors follow suit. For now we still
need to include the viewport meta tag along with the @viewport CSS rule until it becomes a web
standard. It pays to think ahead and add it now for forwards compatibility.

Useful reading material

Quick tip: don’t forget the viewport meta tag
http://webdesign.tutsplus.com/articles/quick-tip-dont-forget-the-viewport-meta-tag--webdesign-5972

Stop using the viewport meta tag (until you know how to use it)
http://blog.javierusobiaga.com/stop-using-the-viewport-tag-until-you-know-ho

How to build standards-compliant responsive design using @viewport

http://www.webdesignerdepot.com/2013/08/how-to-build-standards-compliant-responsive-design-using-
viewport/

Thinking ahead: CSS device adaptation using @viewport

http://blog.teamtreehouse.com/thinking-ahead-css-device-adaptation-with-viewport

Mobile Web Design and Development Best Practice Guide Page 63

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
CSS box-sizing rule

Unless you enjoy working out complicated maths this technique is essential. By default most
browsers add padding on to the width of an element.

Figure 16: Adding padding to elements47

The following CSS ruleset applies a natural box model to all elements, ensuring that the declared
width of an element is maintained while any padding is added to the inside.

*, *:before, *:after {
-moz-box-sizing: border-box;
-webkit-box-sizing: border-box;
box-sizing: border-box;
}

Using this technique also means you can mix units, so you can have the width of an element
defined as a percentage, but padding defined in pixels.

47 Image: http://css-tricks.com/box-sizing/

Mobile Web Design and Development Best Practice Guide Page 64

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Useful reading material
{ Box-sizing: Border-box } FTW
http://www.paulirish.com/2012/box-sizing-border-box-ftw/

Responsive CSS grid systems

All but the most simple of sites use some kind of CSS grid system these days. This enables
developers to quickly apply column widths to elements to build up a page layout.

Figure 17: Example of a CSS grid

Source: http://foundation.zurb.com/grid.html

Whether you create your own or use one of the many predefined systems available, the principle
is quite simple: define your column widths as fixed pixel sizes for non-fluid layouts (that only
change at certain breakpoints – more on that later) or percentages for fluid layouts, so they
dynamically adapt to the space they have available.

Taking the fluid layout for example (based on a 12-column grid), an element spanning six
columns would have a width of 50% or an element spanning four columns would have a width of
33.33333333333333%.

It’s considered good practice to wrap your columns in a row element and use ‘float’, or, somewhat
gaining in popularity, ‘display: inline-block’ to make your columns sit neatly next to each other.
Here is a very basic example showing the HTML markup and CSS using ‘float’:

HTML

<div class="row">
<div class="column full"></div>
<div class="column one-half"></div>
<div class="column one-half"></div>
<div class="column one-third"></div>
<div class="column one-third"></div>
<div class="column one-third"></div>
</div>

Mobile Web Design and Development Best Practice Guide Page 65

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
CSS

.row:before,

.row:after {
content: " ";
display: table;
}

.row:after { clear: both; }

.column { float: left; }

.full { width: 100%; }

.one-half { width: 50%; }

.one-third { width: 33.33333333333333%; }

Note: the rules applied to the .row element are collectively called the “micro clearfix hack” and
they stop the row height from collapsing when the columns inside it are floated.

Here’s the same example but this time using ‘inline-block’ to position the column elements:

HTML

<div class="row">
<div class="column full"></div><!--
--><div class="column one-half"></div><!--
--><div class="column one-half"></div><!--
--><div class="column one-third"></div><!--
--><div class="column one-third"></div><!--
--><div class="column one-third"></div>
</div>

CSS

.column { display: inline-block; }

.full { width: 100%; }

.one-half { width: 50%; }

.one-third { width: 33.33333333333333%; }

In general the ‘inline-block’ method is more appealing; it no longer requires the clearfix hack and
we’re using a display property to lay out our elements rather than ‘float’, which was never meant
for the purpose it’s now most often used for.

One thing you may have spotted are the strange comments in the HTML markup – ‘<!-- -->‘. The
reason for this is because, unless you remove it, browsers add whitespace between inline blocks
that are on new lines in the markup (which would mess with our nicely worked out percentage
widths). One of the easiest ways to deal with this is to start a comment at the end of one line and
then end it at the beginning of the next line, thus removing the whitespace. Another method of
removing the whitespace is to set ‘letter-spacing: -0.31em;’ on the parent element (in this case the
‘.row’ element) and then reset it back to ‘letter-spacing: normal;’ on each ‘inline-block’ element (in
this case the ‘.column’ element).

Mobile Web Design and Development Best Practice Guide Page 66

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 Semantic grid systems

Something else you may have come across before is a semantic grid system. This is based on the
principle that you shouldn’t litter your HTML with unsemantic markup and class names, so no
‘.column’ this or ‘.one-half’ that. What has made this approach a much more viable option is the
widespread adoption of CSS pre-processors, such as SASS and LESS.

Consider the following example:

HTML

<main></main>
<aside class="sidebar"></aside>

CSS

main { .column(8); }

.sidebar { .column(4); }

‘.column()’ is a pre-processor function that works out the column widths for you and outputs a
chunk of CSS that could look something like this:

main {
float: left;
width: 66.66666666666666%;
}

sidebar {
float: left;
width: 33.33333333333333%;
}

More on the wonderful world of CSS pre-processors later!

Useful reading material

A new micro clearfix hack
http://nicolasgallagher.com/micro-clearfix-hack/

Why you should use inline block when positioning elements

http://joshnh.com/2012/02/07/why-you-should-use-inline-block-when-positioning-elements/

Fighting the space between inline block elements

http://css-tricks.com/fighting-the-space-between-inline-block-elements/

Pure CSS Grid Core

https://github.com/yui/pure/blob/master/src/grids/css/grids-core.css

The semantic grid system

http://semantic.gs/

Mobile Web Design and Development Best Practice Guide Page 67

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 Media queries

One of the most important elements of a responsive site is media queries. This is the mechanism
by which you can adapt the layout/design dependent on the device width.

Figure 18: Example of media queries

Source: http://getbootstrap.com/css/#grid

Who better to put it than Ethan Marcotte in his seminal 2010 article, ‘Responsive Web Design’:

“A media query allows us to target not only certain device classes, but to actually
inspect the physical characteristics of the device rendering our work.”

Consider our CSS grid system example above. A ‘.one-third’ width column could become pretty
narrow on a smaller device. It might be better to make ‘.one-third’ columns span full width if the
screen is equal to or less than, say, 640px (this arbitrary breakpoint would of course depend
entirely on the specific design, layout and functionality of your site). You can achieve this by
creating a new CSS ruleset wrapped in a media query:

@media screen and (max-width: 640px) {

.one-third {
width: 100%;
}
}

What this is saying is quite simple – if the device is of a ‘screen’ type and the display has a
maximum width of 640px (or is less than 641px if you want to view it the other way), then apply
the enclosed styles.

And therein lies the real power of responsive web design, the ability to adapt designs and layouts
to the needs of the browser and user – the possibilities are limitless!

Useful reading material

Responsive web design
http://alistapart.com/article/responsive-web-design

Mobile Web Design and Development Best Practice Guide Page 68

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
4.4.2. What do developers need to do to create a responsive code
base?
In the previous section we looked at what makes up a responsive code base. We boiled it down to
the following elements:

 The viewport meta tag and CSS rule

 The CSS box-sizing rule
 A responsive CSS grid system
 Media queries

So what makes this different from a non-responsive code base? Well, not as much as you would
think. You won’t need a viewport tag or media queries for non-responsive sites but you are
already likely to be using the box-sizing rule and a good grid system.

However, one of the main differences that tends to go hand in hand with responsive design is the
way you organise your code through the use of a CSS pre-processor (such as SASS, LESS or
Stylus). A CSS pre-processor basically takes specially modified CSS and outputs it as vanilla CSS.
That’s not to say that you can’t create non-responsive sites using a pre-processor – of course you
can – but the rise of responsive web design and the widespread adoption of pre-processors
happened to coincide at the right time (probably no accident). Pre-processors make working with
any kind of code base, be it responsive or non-responsive, so much easier.

Figure 19: CSS pre-processors

So why is it that CSS pre-processors make things easier for developers? In a nutshell, they add the
‘functionality’ to CSS that you always wished was there.

Developers have long bemoaned the fact that CSS is basically a ‘dumb’ language. You can’t make
use of any normal programming techniques, such as variables, functions, operations etc. It’s also
harder, although not impossible, to write code that is modular and DRY (Don’t Repeat Yourself)
using regular CSS. Pre-processors allows developers to do all of this, with the output being lovely
vanilla CSS.

So what does this mean in real terms? It means that what could have brought a lot of added
complexity to a project is actually made far more manageable through the use of CSS pre-
processors.

Take Bootstrap, “the most popular front-end framework for developing responsive, mobile first
projects on the web”, for example. Bootstrap heavily modularises its code, making it much easier
to maintain and find what you’re looking for. In the core ‘less’ directory there are currently 40
LESS ‘modules’, from ‘alerts.less’ to ‘wells.less’.

One of these files is ‘variables.less’. Contained in this file, among many other things, are the core
variables controlling the media query breakpoints. The ‘@screen-xs’ breakpoint is set to 480px by

Mobile Web Design and Development Best Practice Guide Page 69

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 default. To change this value globally you only need to edit this one occurrence of the ‘@screen-xs’
variable and recompile the CSS. Another example – if you want to change the ‘.container’ sizes for
each breakpoint, you only have to change the ‘@container-tablet’, ‘@container-desktop’ and
‘@container-large-desktop’ variables and recompile.

The benefits of using a CSS pre-processor cannot be ignored and, although you can still enjoy the
benefits on a non-responsive project, they make developing responsive sites manageable and even
a pleasure.

Useful reading material

SASS
http://sass-lang.com/

LESS
http://lesscss.org/

Stylus
http://learnboost.github.io/stylus/

Ten reasons you should be using a CSS pre-processor

http://www.urbaninsight.com/2012/04/12/ten-reasons-you-should-be-using-css-preprocessor

DRY – don’t repeat yourself

http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

Bootstrap
https://github.com/twbs/bootstrap

Maintaining a responsive code base – good housekeeping

We touched on this in the previous section when talking about the use of CSS pre-processors and
how they make it much easier to work with a more modular code base. This makes code DRYer
(see useful reading material above) and more reusable. But there are a few more important
considerations when maintaining a responsive code base:

1. Define your goals

2. Coding conventions
3. Project structure
4. Front-end frameworks and component libraries
5. Pattern libraries and style guides
6. Version control

We can neatly sum up all these elements into what’s called a ‘design system’, coined by Mark Otto
in his ‘Build your own Bootstrap’ talk at FOWA 201348 and neatly summarised by Ara Abcarians
in his article ‘Design Systems: Building for the Future’49.

Define your goals

Before even starting a project you need to outline your goals. Ara Abcarians calls these ‘top-level
goals’ and lists them as:

48 https://speakerdeck.com/mdo/build-your-own-bootstrap
49 http://css-tricks.com/design-systems-building-future/

Mobile Web Design and Development Best Practice Guide Page 70

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
1. Organisation
Be organised from the start. Plan your approach and structure and stick to it. Untidy and
unwieldy code bases are time consuming to work with and will, ultimately, cost you money
and more than a few grey hairs.

2. Maintainability
Stick to clearly defined coding conventions and guidelines (more on this later). It would be a
perfect world where a team of developers starts work on a project and that same team then
sees the project through to completion and beyond. But this rarely happens; teams change. To
that end we need new developers to be able to jump in, quickly get up to speed and not make a
big mess of things.

3. Responsiveness
In a report about responsive web design this should go without saying. Needless to say, the
huge increase in mobile traffic makes it extremely important that any site we build these days
is “platform agnostic”. Even Google goes so far as to say it’s the recommended method for
serving content to all devices. Google’s stance comes from one of optimisation and
performance, which we will come to later.

4. Scalability
As a site grows and expands you need a code base that can grow and expand with it. This
comes down to modularity, DRYness and good organisation/structure.

Coding conventions

Looking at things from a broader coding perspective, you should be using good coding practices
throughout your code base, whether that is in HTML, CSS or JavaScript. The principles outlined
below are equally important whether you’re working on a responsive or non-responsive code
base.

Language writing principles

As front-end development has matured over the years, so have the methods and techniques.
Developers have realised that in order to work effectively from project to project, or in teams, they
need to follow recognisable patterns or things will quickly become messy and unmanageable. That
doesn’t mean creativity is stifled, merely that developers should adhere to good coding practices.
Simply put: “All code in any code base should look like a single person typed it, no matter how
many people contributed.”

There are a few simple resources that we recommend using:

1. Principles of writing consistent, idiomatic HTML 50
2. Principles of writing consistent, idiomatic CSS51
3. Principles of writing consistent, idiomatic JavaScript52

BEM syntax

An extension of CSS language writing principles is BEM53, or Block, Element, Modifier syntax.
Building on the principles of OOCSS54 (Object Oriented CSS) and SMACSS 55 (Scalable and

50 https://github.com/necolas/idiomatic-html
51 https://github.com/necolas/idiomatic-css
52 https://github.com/rwaldron/idiomatic.js/
53 http://bem.info/method/
54 https://github.com/stubbornella/oocss/wiki
55 http://smacss.com/

Mobile Web Design and Development Best Practice Guide Page 71

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 Modular Architecture for CSS), BEM syntax (or at least a BEM ‘style’ syntax, a slightly more
readable version, popularised by Nicolas Gallagher 56 and Harry Roberts57) is fast gaining traction
as a way for developers to organise and write meaningful class names, or “a way of describing
reality in code”. This makes maintaining a code base, particularly a larger one, much less of a
chore.

Probably the easiest way to illustrate how BEM works is by way of examples. The basic
components of BEM are as follows:

.block {}
.block__element {}
.block--modifier {}

‘.block’ describes the element at a component level. ‘.block__element’ describes a child element of
the component level block. ‘.block--modifier’ describes a modified state of a block (you can also do
‘.block__element--modifier’).

To use a ‘real world’ example, consider a list of navigation links. Using BEM we could describe
them as follows:

.nav {}
.nav__link {}
.nav__link--active {}

‘.nav’ describes the nav component as a whole, ‘.nav__link’ describes an individual link element
and ‘.nav__link--active’ describes the current active link.

You might be wondering why we’re using double underscores and hyphens? The reason is simple
– it allows us to still use single hyphens as delimiters e.g. ‘.main-nav__level-one-link--active’.
Obviously this is an extreme example that you probably wouldn’t want to use in reality, but
hopefully you get the idea.

BEM can look a little funny and unwieldy a times, especially to those used to writing class names
as succinctly as possible or heavily nesting HTML tags in their CSS in order to use as few CSS
classes as possible (yes, this was actually ‘a thing’ for a while). However, the benefits far outweigh
the negatives in terms of making code much easier to understand and follow, especially in a team
environment.

Useful reading material

OOCSS
https://github.com/stubbornella/oocss
SMACSS
http://smacss.com/
BEM
http://bem.info/method/
A new front-end methodology: BEM
http://coding.smashingmagazine.com/2012/04/16/a-new-front-end-methodology-bem/
MindBEMding – getting your head ‘round BEM syntax
http://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/
About HTML semantics and front-end architecture
http://nicolasgallagher.com/about-html-semantics-front-end-architecture/

56 http://nicolasgallagher.com/about-html-semantics-front-end-architecture/
57 http://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/

Mobile Web Design and Development Best Practice Guide Page 72

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Project structure

It’s no good having nicely written and formatted code if the structure of your project is
unorganised. It doesn’t really matter how you organise things as long as it makes sense to the
team working on the project.

The overall structure of a project will largely depend on the type of site it is. There are no rules as
such, only perceived best practices.

It’s fair to say that most developers these days understand the importance of separating elements
that make up a project. Using a very basic, high-level example you might have a directory
structure that looks something like this:

<project name>/
|-- docs/
|-- framework/
|-- temp/
|-- tests/
`-- theme/
|-- css/
|-- images/
`-- js/

Frameworks and CMS

Figure 20: Using frameworks

If you’re working with a framework or CMS then you will have little control over the overall
project structure; you will have to work within their constraints, but these tend to be fairly well

Mobile Web Design and Development Best Practice Guide Page 73

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 thought out already. For example, Zend, the popular PHP framework, recommends this project
directory structure58.

Flat file sites and web apps

Fast gaining popularity through the use of static site generators such as Jekyll and tools such as
Grunt JS, smaller ‘flat file’ projects might look something like this:

<project name>/
|-- build/ # Our compiled site
| |-- css/
| |-- images/
| `-- js/
|-- docs/
|-- node_modules/
|-- src/ # Our precompiled project files
| |-- bower_components/
| |-- css/
| |-- images/

| |-- js/
| `-- templates/
| |-- layouts/
| |-- pages/
| `-- partials/
`-- test/

The main things to point out here are the ‘src’ and ‘build’ folders. The build folder contains our
production-ready site files, ready to publish. The ‘src’ folder contains a more modularised version
of our site. If you look closely you will see that it includes a ‘templates’ folder, from which the
pages are built using a similar method to our CSS pre-processors – the files in this folder are
effectively ‘pre-processed’ before being turned into raw HTML files and placed in our ‘build’
folder.

Useful reading material

Zend recommended project directory structure
http://framework.zend.com/manual/1.12/en/project-structure.project.html

Jekyll
http://jekyllrb.com/

Grunt JS
http://gruntjs.com/

58 http://framework.zend.com/manual/1.12/en/project-structure.project.html

Mobile Web Design and Development Best Practice Guide Page 74

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 CSS

The following simple example (one which we know developers often base their own project
structures on) is by John W. Long, Managing Editor of The SASS Way59. Although this is based on
a SASS project, it applies to any environment that uses a pre-processor.

css/
|
|-- modules/ # Common modules
| |-- _all.scss # Include to get all modules
| |-- _utility.scss # Module name
| |-- _colors.scss # Etc...
| ...
|
|-- partials/ # Partials
| |-- _base.scss # imports for all mixins + global project
variables
| |-- _buttons.scss # buttons
| |-- _typography.scss # typography
| |-- _reset.scss # reset
| ...
|
|-- vendor/ # CSS or SASS from other projects
| |-- _colorpicker.scss
| |-- _jquery.ui.core.scss
| ...
|
`-- main.scss # primary SASS file

The main thing you will notice is that the SASS files are organised into folders that describe their
status/purpose:

1. Modules – code that isn’t directly output as CSS, so variables, mixins and functions.
2. Partials – this will form the bulk of your project, all the components and structural elements
of your site. This could be buttons, forms, navigation, typography etc. It may be necessary to
further subdivide this folder in order to make it more manageable.
3. Vendor – third-party CSS from other components, plugins etc.

Looking at the files themselves there are a few things of note:

1. ‘main.scss’ is the primary SASS file. This file only contains imports that pull everything
together.
2. ‘_base.scss’ contains global project variables and loads our module file ‘_all.scss’.

For a more detailed overview check out John’s article on The SASS Way60.

Useful reading material

A little structure for your large SASS project
https://medium.com/p/7fe19ab647fa

How to structure a SASS project

http://thesassway.com/beginner/how-to-structure-a-sass-project/

59 http://thesassway.com/
60 http://thesassway.com/beginner/how-to-structure-a-sass-project/

Mobile Web Design and Development Best Practice Guide Page 75

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 Front-end frameworks and component libraries

It seems that the whole front-end world is going through a big mindshift at the moment, and one
of the key differences in the way many development teams are starting to approach responsive
design is through the use of modular front-end components.

Dave Rupert has talked about responsive deliverables. He wrote that “old PSD-to-HTML
workflow served us well for many years, but isn’t able to stand in the face of all the complexity
that responsive web design and the multi-device web have introduced”.61

He argued that we need to start thinking in terms of modules, not pages, and that “we should be
thinking about deliverables as modular pieces of the larger system”.

Many developers have been using modular front-end frameworks such as Bootstrap and
Foundation for some time now, so this way of working/thinking has been a natural progression.

Some developers are taking the things they’ve learned from these high-profile frameworks and
writing their own stripped back, more fit-for-purpose component libraries, such as Inuit, Pure or
SUIT. That’s not to say that Bootstrap and its ilk aren’t good, they’re absolutely amazing, but their
one-size-fits-all nature doesn’t sit so well with a faster, leaner, more optimised web. At the end of
the day you will need to decide on a project-by-project basis which route to take. Whatever you
decide, front-end frameworks or component libraries are an essential part of a developer’s
responsive arsenal.

Useful reading material

Responsive deliverables
http://daverupert.com/2013/04/responsive-deliverables/

Bootstrap
http://getbootstrap.com/

Foundation
http://foundation.zurb.com/

Inuit
http://inuitcss.com/

Pure
http://purecss.io/

SUIT
https://github.com/suitcss/suit

Build your own Bootstrap

https://speakerdeck.com/mdo/build-your-own-bootstrap

61 http://daverupert.com/2013/04/responsive-deliverables/

Mobile Web Design and Development Best Practice Guide Page 76

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 Pattern libraries and style guides

There is a growing trend, once you’ve pinned down your front-end framework, to create pattern
libraries or style guides. These are ‘living’ documents that compile all the elements of a site into a
single reference point for developers, site editors and clients. Branding agencies have been
creating brand guidelines for eons, so why not do the same for websites? Anna Debenham has
been one of the key proponents since 2011:62

“We all know that feeling: some time after we launch a site, new designers and
developers come in and make adjustments. They add styles that don’t fit with the
content, use typefaces that make us cringe, or chuck in bloated code. But if we didn’t
leave behind any documentation, we can’t really blame them for messing up our hard
work.”

Pattern libraries have become an integral part of the design system and make the transition from
design (be that style tiles or more ‘old-school’ full-page visuals) to a working prototype/site that
much quicker and easier. They allow for a more agile, iterative and feedback-driven process with
the client and key stakeholders.

There is a growing number of style guide boilerplates out there. One you might consider is the
Style Guide Boilerplate, another is Origin by David Bushell, who is highly regarded. In practice
each project is so different that you usually need to create a new style guide on a per-project basis.
That said, each style guide you create will have components that can be reused on the next one.
Here is an example of GPMD’s own style guide: http://styles.stage.gpmd.net/.

Useful reading material

Style tiles
http://styletil.es/

Front-end style guides, by David Bushell

http://dbushell.com/2013/11/05/front-end-style-guides/

Front-end style guides, by Anna Debenham

http://24ways.org/2011/front-end-style-guides/

Style Guide Boilerplate

https://github.com/bjankord/Style-Guide-Boilerplate

Origin
https://github.com/dbushell/dbushell-Origin

62 http://24ways.org/2011/front-end-style-guides/

Mobile Web Design and Development Best Practice Guide Page 77

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Version control

Figure 21: Explaining version control

Although not unique to responsive web design, version control and its related processes are an
integral part of maintaining any kind of code base, especially one being worked on by a team. We
won’t go into too much detail but there are a few things worth highlighting:

1. Version control systems

There are a number of popular version control systems, such as SVN or Mercurial, but it’s fair
to say that Git is the most popular, largely because of the wonderful Github (probably due to
its cute logo).

So what is Git? Well, according to Google ‘Git’ is “an unpleasant or contemptible person”...

No wait, that can’t be right! Sorry, “Git is a free and open source distributed version control
system designed to handle everything from small to very large projects with speed and
efficiency.”

In a nutshell, Git monitors and tracks changes to your files, so you know who has done what,
where and when.

Mobile Web Design and Development Best Practice Guide Page 78

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Useful reading material
Git
http://git-scm.com/

SVN
http://subversion.apache.org/

Mercurial
http://mercurial.selenic.com/

Github
https://github.com/about

2. Gitflow

Figure 22: Git branching model

One of the best things about Git is the ability to create ‘branches’. A branch is basically a whole
new snapshot of your code base at a point in time. You create branches to code new features and
functionality and then merge these changes back into the master branch at a later stage.

In order to manage this process effectively, you can use something called ‘Gitflow’. To fully
describe Gitflow is beyond the scope of this report but here is a quick summary.

At the core of the GPMD project example are two branches, ‘master’ and ‘develop’. All
development is done off of the ‘develop’ branch. While working on a project the agency creates
additional ‘feature’ branches off of ‘develop’. Once the ‘develop’ branch is at a stage where they
want to publish, they create a ‘release’ branch off of ‘develop’. Work can then continue on the
‘develop’ branch with new features. The new ‘release’ branch is then merged into the ‘master’
branch. And so it goes on in an endless loop. It might sound a bit complicated but once you start
using it you’ll find you quickly get to grips with it.

Check out Vincent Driessen’s excellent article on Gitflow, A successful Git branching model, for
more information (see below).

Useful reading material

A successful Git branching model
http://nvie.com/posts/a-successful-git-branching-model/

Mobile Web Design and Development Best Practice Guide Page 79

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 3. Semantic versioning
Version numbering should form an important part of your version control process, especially
if you’re using Gitflow as a branching model. For example, GPMD uses semantic versioning as
a reference for its version numbering.

In summary, a version number would look something like 2.5.3 and is built of these three
elements – Major, Minor and Patch.

– Major – major update i.e. incompatible API changes

– Minor – additional, backwards-compatible functionality
– Patch – backwards-compatible bug fixes

Useful reading material

Semantic versioning
http://semver.org/spec/v2.0.0.html

4.4.3. Code validation

First things first – do you actually need to validate code?

There was a time when having a W3C ‘Valid HTML’ or ‘Valid CSS’ logo on your site was a badge of
honour. These days, less so. The problem is that front-end designers and developers want, and are
already using, new HTML and CSS features all the time. Having a set of static standards is
limiting in today’s fast moving internet age.

Take HTML5. Web developers have been using it for some time, right? Did you know that
according to the W3C it’s not a ‘standard’ yet and won’t become a recommendation until later in
2014? The WHATWG takes a slightly different stance – they define HTML5 as a ‘living’ standard,
the concept being it will never be complete, and will always need to be updated and improved
upon.

Then you have the interesting situation surrounding CSS3. Due to the modular nature of the spec,
some components of CSS3 have reached ‘recommendation’ status (i.e. stable) while others are
considered only moderately stable and are therefore only at ‘candidate recommendation’ status.
Many CSS3 properties also still require vendor prefixes to work, i.e. ‘-webkit-’, or ‘-moz’, which
are not valid CSS (note: vendor prefixes are usually dropped when a module reaches candidate
recommendation status). Try telling a designer/developer he can’t use CSS3 drop shadows
because it will require invalid CSS; they’ll likely kick you out of the door!

The point we’re trying to make is this: in this day and age you should take a considered view about
what is important; know when to fight your battles. Does any ‘invalid’ code you’re using ‘break’
the site in any way? Does it degrade the user experience? At the end of the day your users don’t
care if the code is valid, just that the site works.

We like how Jeff Atwood sums up this very question in his article, HTML Validation: Does It
Matter?

HTML validation: does it matter?

“But the question remains: does HTML Validation really matter? Yes. No. Maybe. It depends. I’ll tell you the
same thing my father told me: take my advice and do as you please.”
Jeff Atwood, Co-founder of Stack Exchange and Discourse

Mobile Web Design and Development Best Practice Guide Page 80

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
So, assuming we are going to validate our code at some level...

A recommended view, that has hopefully come across throughout this whole section on creating a
responsive code base, is that if you follow good coding practices and conventions, use well
established front-end frameworks and CMS and maintain an organised project, you will probably
find you come across less validation issues than you might think.

Also, the way in which many front-end developers work, and the tools they use, make invalid code
through user error much less of a possibility.

Figure 23: Code editors and IDEs

Most developers use code editors (such as Sublime Text, which has a good plugin called
SublimeLinter) or IDEs (such as PhpStorm) that ‘validate’ syntax on-the-fly. By validated syntax
we don’t mean ‘valid’ in the sense that W3C do, simply code that is error free.

CSS pre-processors

If you use a CSS pre-processor, such as SASS or LESS, your syntax will be validated every time
you compile. There are many ways to compile SASS or LESS, from dedicated apps such as
CodeKit, through to the command line and Ruby Gems. Any method you use will spit out errors if
you try to enter invalid syntax, giving you the opportunity to fix things early.

JavaScript

The same applies to JavaScript, with most developers running their code through some kind of
‘linter’, meaning they know that the syntax and general structure of their code is at least correct.
Again, you can use a dedicated app such as CodeKit or, more likely if you’re a JavaScript
developer, a command line tool, such as JSHint, which will automatically run as part of your build
process.

Mobile Web Design and Development Best Practice Guide Page 81

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 Figure 24: JSHint screenshot

An absolutely invaluable tool in a JavaScript developer’s arsenal is the console found in Chrome’s
Developer Tools or Safari’s Web Inspector. You should make it a point to fix all errors logged here
– your page may seem to be functioning correctly but an error is a sign of ‘bad’ code (it might only
be a deprecated function, or just a warning, but nonetheless…) and it should be fixed. You never
know what else might be affected by that error now or in the future.

If you need to run your site’s HTML or CSS through a validator then the W3C has excellent online
services for both:

1. Markup Validation Service

2. CSS Validation Service

References
W3C
http://www.w3.org/

WHATWG
http://www.whatwg.org/

Living standard
http://www.whatwg.org/specs/web-apps/current-work/multipage/

HTML5 is not ready yet – and will never be (and that is a good thing)
http://christianheilmann.com/2012/03/14/html5-is-not-ready-yet-and-will-never-be-and-that-is-a-good-thing-
html5-question-1/

Mobile Web Design and Development Best Practice Guide Page 82

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
References (cont.)
CSS vendor prefixes
http://webdesign.about.com/od/css/a/css-vendor-prefixes.htm

HTML validation: does it matter?

http://www.codinghorror.com/blog/2009/03/html-validation-does-it-matter.html

Sublime text
http://www.sublimetext.com/

SublimeLinter
https://github.com/SublimeLinter/SublimeLinter-for-ST2

PhpStorm
http://www.jetbrains.com/phpstorm/

CodeKit
https://incident57.com/codekit/

SASS RubyGem
https://incident57.com/codekit/

JSHint
http://www.jshint.com/

Chrome Developer Tools

https://developers.google.com/chrome-developer-tools/

Safari Web Inspector

https://developer.apple.com/safari/tools/

Markup validation service

http://validator.w3.org/

CSS validation service

http://jigsaw.w3.org/css-validator/

Mobile Web Design and Development Best Practice Guide Page 83

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
4.4.4. Optimising responsive sites for optimal page speed
Hopefully by now you have a good idea of what needs to be done to optimise for page speed. You
can use Google’s PageSpeed Insights tool63, which offers sound advice on how to specifically
optimise your own (or your client’s) site.

How can I optimise for performance?

So as a developer, what are the key things you can take away from this (in plain English we hear
you say)? In order to break the 1000 ms barrier you must:

1. Inline ‘above the fold’ CSS (and JavaScript), keeping it under 14KB
Simply put, create a small inline stylesheet that contains only the bare minimum of styles
required to display something ‘nice’ to a user. For example:

<html>
<head>
<style>
.main { ... }
.navigation { ... }
.sidebar { ... }
/* And so on... */
</style>
<script>
// Voodoo magic...
</script>
</head>
Google’s own developer article on optimising CSS delivery makes a good read and expands on this
principle: https://developers.google.com/speed/docs/insights/OptimizeCSSDelivery.

2. Defer non-critical assets i.e. move JavaScript to the bottom of the page
Using Ilya’s own simple example from his talk, your code could look something like this:

</head>
<body>
<!-- All your content here →
<script>
function run_after_onLoad() {
load(‘stylesheet’, ‘remainder.css’)
load(‘javascript’, ‘remainder.js’)
}
</script>
</body>
</html>

In the example above the main CSS and JavaScript files are being deferred until most of the page
has loaded. As the CSS is loaded dynamically using JavaScript, the page won’t be blocked from
displaying before the CSS has loaded. Taking this a step further, it might also make sense to
further optimise things and break the CSS up into page- or purpose-specific files rather than load
the entire CSS code base in one go (you would still only load one CSS file per page, but it would
only contain styles relevant to that page). It’s worth noting though that every extra file you load
requires another HTTP request and is an additional file that needs to be cached by the browser.
Unless your CSS code base is huge it may still be worth leaving it as one file.

63 https://developers.google.com/speed/pagespeed/insights/

Mobile Web Design and Development Best Practice Guide Page 84

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 Many development teams are already loading their JavaScript modules dynamically and
asynchronously using tools such as RequireJS. It stands to reason that we could also do the same
with our CSS files, loading only those page- or purpose-specific styles that we need, when we need
them. There is a RequireJS plugin called RequireCSS that looks promising. It can either ‘inline’
your CSS dynamically or, even better, load your CSS asynchronously so it doesn’t block the page
from rendering, which is key when considering your critical rendering path.

One downside to using a tool such as RequireJS is that it’s easy enough to implement if you’re
working on a flat file site or web app, or a framework that is flexible enough to allow you to set up
and load your CSS and JavaScript assets as you wish. But if you work with a platform like
Magento you’ll quickly discover that it has its own (outdated?) methods for asset loading that
aren’t necessarily that easy to circumvent. Yes, you can just ignore Magento’s methods and load
your own scripts however you like but what about the 16 (yes you heard that right) JavaScript
dependencies in the head that are loaded by default? Try moving them to the bottom of the page
or loading them asynchronously and see where it gets you...

View from the expert – optimising CSS asset loading

“I’m only in the infancy of my own thinking when it comes to optimising CSS asset loading, so I don’t really have
any other tried-and-tested methods to suggest, but it’s becoming clear that it has to be a consideration.

“Github published an article last year about how they created and optimised their mobile site by minimising the
amount of JavaScript and CSS loaded compared to their desktop experience. Also, The Guardian shared some
really interesting page size and requests stats across devices in Mark Zeman’s article Rapid response –
performance techniques for responsive web design – the load ‘weight’ on the smallest devices is 67% less
compared to a desktop machine!

“If you’re interested in checking out The Guardian’s responsive code base they’ve open-sourced it on Github.
We’re definitely on new ground here, but it’s exciting being on the cutting edge!”

Matt Bailey, Creative Director, GPMD

3. Make maximum use of same domain for critical assets

This is to avoid unnecessary server connections or DNS lookups needing to be made.

Just to summarise, if any of your critical assets are hosted elsewhere (on a CDN for example) this
will require at least one extra round trip to the server in order to download them.

For the sake of clarity a critical asset is defined as anything that is required to put something
useful on the page within one round trip. For example, the assets required to display the site
header.

It’s important to note we are not suggesting that you ditch your CDN. Content delivery networks
can give you performance improvements when loading static assets across your website.

4. Optimise your code

We’ve really already covered this in the Maintaining a responsive code base – good housekeeping
section, but we want to reiterate here how important good coding conventions and language
writing principles are. A well formatted, DRY and scalable code base is performant code and that
is key.

Mobile Web Design and Development Best Practice Guide Page 85

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Useful reading material
Optimizing the critical rendering path
https://www.youtube.com/watch?v=YV1nKLWoARQ

Rapid response – performance techniques for responsive web design

http://calendar.perfplanet.com/2013/rapid-response/

Building smartphone-optimised websites

https://developers.google.com/webmasters/smartphone-sites/

Google PageSpeed Insights

http://developers.google.com/speed/pagespeed/insights/

Optimising CSS delivery

https://developers.google.com/speed/docs/insights/OptimizeCSSDelivery

RequireJS
http://requirejs.org/

RequireCSS
https://github.com/guybedford/require-css

How to load CSS stylesheets dynamically with jQuery

http://www.vidalquevedo.com/how-to-load-css-stylesheets-dynamically-with-jquery

Github’s on your phone

https://github.com/blog/1559-github-s-on-your-phone

The Guardian’s responsive code base

https://github.com/guardian/frontend

4.5. Pros and cons

Having reviewed the previous two sections, how do you evaluate the pros and cons of
implementing a responsive website? What criteria should you consider when making the decision
and what factors are critical to the success of the project?

4.5.1. Criteria to consider

Impact on your existing website

If you already have a fully tested and smoothly operating website that isn’t responsive you will
need to consider the impact of going responsive. It will more than likely mean starting again with
the front-end theme of your website and I would suggest the best time to go responsive is when
you are contemplating a complete redesign, rather than just making your existing design
responsive.

Most websites have a lifecycle, usually between three and five years, although sometimes much
longer. The right time to go responsive is at the end of the current lifecycle.

Complexity

There is certainly a learning curve for any team implementing responsive design for the first time;
this should be factored into your project timeline. Our suggested approach to tackling the

Mobile Web Design and Development Best Practice Guide Page 86

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
challenges outlined in the previous sections is to approach them bit by bit, approaching the issues
around creating a responsive code base first.

One advantage any team going responsive now will have over the early adopters is the huge
wealth of information and advice available (this report and the references listed for example).

The performance issues are typically only just being addressed by many teams now and when the
major browsers support the picture element one major challenge will be a lot easier to solve.

Many companies and agencies have been making big strides towards solving the technical
challenges in 2014 and beyond; once solutions are available the complexity of going responsive
will be greatly reduced.

Cost and time

If you can adapt your process and follow the guidelines described in this document the impact on
the design and development of your code base can be minimal. Certainly you should allow more
time for testing, but the initial design and build process is usually a very efficient way of
producing websites.

The performance issues will have a greater impact on time and cost, but these can be addressed
one step at a time. When approached in this way the cost can be absorbed as part of ongoing
maintenance and code refactoring which is considered best practice anyway.

Integration with legacy systems

Largely speaking responsive design should not affect the underlining functionality delivered by
your web platform, however some of the techniques outlined in this document can be hard to
achieve depending on how your platform of choice deals with templating the front-end code base.

Any impact your platform has in this area will need to be evaluated by your technical team and
assessed. The results of this exercise will depend on your legacy platform.

One important thing to note is that an effective implementation of the picture element is likely to
require some re-working on most web platforms. In particular, finding the balance between
admin overheads (i.e. creating multiple versions of each image) and performance is key; most
websites will need to find an automated way of creating the required version of each image.

Maintenance

If you follow best practice for coding standards your impact on maintenance should be no more
than before. Most maintenance issues are caused by poorly crafted and hard to read code; if you
use solid naming and coding conventions you will minimise the impact of this.

Site performance and page load

As previously stated, this is an area that still requires work. However, there are plenty of solutions
out there that will enable you to deliver a high-performing responsive website.

We would also suggest that if you optimise your website for performance over low speed internet
connections and mobile devices you will feel the benefit when viewing the website on high speed
internet connections and desktop devices – it will be super-fast.

This is of particular relevance to transaction websites where website speed has a direct impact on
conversion.

Mobile Web Design and Development Best Practice Guide Page 87

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 SEO impact

The impact on SEO is dealt with in a later section of this document; however, the impact of
responsive design on SEO should be minimal. Make sure you review the main points outlined in
this document and cover all the usual best practice for the technical aspects of SEO.

Usability and UX

The main impact here is that you will need to consider mobile and tablet specific requirements
throughout the project lifecycle, considering touch devices, mobile (click-to-call) etc.

Is this a pro or a con? No – these devices and how people use them are critical to your
organisation’s success, so whatever solution you implement you will have to consider this.

Critical success factors

So, of all these factors, what is critical to success? The ones that impact your customers directly
are those most likely to impact the success of your website:

1. Site performance and page load

2. SEO
3. Usability / UX

When considering these in the context of responsive web design, make sure you compare against
your existing solution and alternatives.

Can you deliver a website the loads in less than five seconds on a mobile? (Acceptable, especially
if you currently have no mobile solution.)

Has your SEO team evaluated all the potential issues with a responsive solution?

Make sure you design your UX either mobile first or with mobile clearly in mind.

4.6. Example sites

As we’ve highlighted, responsive web design isn’t new and there are lots of examples of websites
adopting this design approach. Below we have provided three examples that provide a useful
illustration of how websites are changing the page layout and content at specific breakpoints to
provide a consistent UX/UI design pattern across devices.

For further reading, we recommend the following blog posts:

 http://www.mobify.com/insights/70-stunning-responsive-sites-for-your-inspiration/
 https://econsultancy.com/blog/63172-10-great-examples-of-responsive-design-from-around-
the-world

Mobile Web Design and Development Best Practice Guide Page 88

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Figure 25: United Pixelworkers

Figure 26: Currys

Mobile Web Design and Development Best Practice Guide Page 89

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Figure 27: B2B – Salesforce

Mobile Web Design and Development Best Practice Guide Page 90

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
4.7. Case studies
4.7.1. Schuh
Acknowledgment
Thank you to Stuart McMillan, deputy head of ecommerce at Schuh, for providing a case study on their evolution
towards responsive web design.

Schuh is a company that is big on numbers. In the shops it measures footfall and conversion,
looking at the profitability of every shop very closely. Online, it looks at productivity by marketing
channel, the sales by product category and brand. The web team also looks at the devices its
customers use to connect to the website, measuring change over time.

You can see from the graph below that the past two years have seen a major traffic shift towards
mobile and tablet.

Figure 28: Schuh desktop, tablet and mobile traffic trends

Schuh typically sees around a 1% movement from desktop every month, although the adoption of
mobile and tablet happens faster at Christmas. The business attributes this to an increase in the
number of devices in circulation but also due to the number of people off work having the
opportunity to use their device. On a day-to-day level, it is not unusual for there to be 12% fewer
visits to desktop devices on a Sunday compared to Friday, on a proportional basis.

The increasing mobile traffic led Schuh to evaluate the user experience that www.shuh.co.uk
provided on a mobile device: the team decided that the website was, quite frankly, unusable.

Schuh launched its first mobile site in November 2011 before tablets were a significant traffic
contributor. The site had the occasional update but constantly lagged behind the desktop site;
mobile may be a growing traffic segment but it is still overshadowed by desktop traffic.

Mobile Web Design and Development Best Practice Guide Page 91

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 In mid-2012 the business could see that tablet was becoming an increasingly important traffic
source. Although there wasn’t as much of it as there was mobile traffic, it performed far better. So,
a tablet site was launched in November 2012. It’s a lovely looking site, which made the business
think hard about producing a higher quality design that is nice to interact with.

User-centred design
“I think the tablet site was perhaps our biggest step change towards a truly user-centric approach to design. The
site has many faults, but I think it has been an important step on our path to digital maturity”.
Stuart McMillan, deputy head of ecommerce, Schuh

In January 2013, Schuh started to think more seriously about a responsive site. The business has
an outlet site, www.Branch309.co.uk, which was often neglected. Like Schuh, it had an
increasingly mobile audience and in 2011, it had many mobile-specific usability problems. The
business wanted to ensure that Branch309 was more suitable for an audience using a wider
variety of devices and screen sizes, but the comparatively lower traffic volume meant that it
couldn’t justify separate, device-specific websites. The lower volume nature of the site also meant
that there was greater willingness to take a risk; a new responsive site seemed like a great option.
It would also act as a pilot for a future Schuh responsive site.

The timeline would give Schuh a responsive pilot before Christmas 2013, then looking towards a
Schuh responsive site in mid-2014 – giving a timeline like this:

Figure 29: Schuh project timeline for responsive build

Branch309 is a much simpler offering than Schuh, there are fewer products, fewer delivery
options, fewer features in general.

The planning process

Before Schuh even started planning responsive, it had a look at the mobile site. Moving to
responsive was obviously going to take a while; they wanted to ensure that the business wasn’t
losing out too badly on mobile in the meantime. The web team walked through the core journey
and came up with a list of quick usability wins that could be made to improve the user’s
experience until the new site was ready. It didn’t take long to plan or execute and was good for the
conversion rate.

These quick wins gave breathing space to not rush in to a responsive site for Schuh. The analytics
data gave context, then the business set some ground rules, established what was important
before starting the design process:

Mobile Web Design and Development Best Practice Guide Page 92

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 1. Must be designed mobile first
2. Must apply usability best practice
3. Must have service and content parity for all devices
4. Must use the same HTML for all ‘variations’
5. Must be fast
6. Must be SEO friendly
7. Must have analytics planned from the start
8. Should validate

The next step was to conduct some usability research; Schuh engaged PRWD to carry out some
moderated user testing of the core journey over desktop, mobile and tablet. The videos and
analysis that came out of that process were invaluable; the team could clearly see where its
interface strengths and weaknesses were, as well as the inconsistencies between the sites. It could
then add to the objectives of the site: ensure that all high-priority friction points identified in the
review are fixed in the new site.

It would be hard to overstate the importance of approaching the project in a mobile-first way. It
isn’t a thought process that comes naturally; Schuh had to work hard to change its mindset. For
example, whenever mock-ups were presented, they would typically be shown desktop first. Stuart
McMillan would then re-arrange the mock-ups so that mobile was always talked about first.
Whenever someone would talk about a concern they had with the site, he would always reach for
the mobile design and ask them to clarify. They would inevitably say “I meant the desktop layout”;
they hadn’t considered mobile.

It’s an easy trap to fall into: we all work in front of a desktop computer of some sort; we may use
mobile devices when away from our desk, but when we’re carrying out the business of improving
websites, we do so from large screens. It’s just easier.

Top tip from Schuh

“So, a top tip from me: find a way to be disruptive to people’s desktop-first thinking.

“I believe increasing adoption of mobile browsing is starting to change people’s expectations of web design.
‘Simpler is better’ really would appear to be the case. Approaching it mobile first really helped us with our design.
It helped us eliminate unnecessary UI elements, whereas in the past we would have included them just because
we felt we had plenty of pixels to spare. This simpler design philosophy really helped us focus on user attention,
to aid this we have started to use EyeQuant, which is an algorithmic version of eye tracking; it programmatically
simulates how the human eye will look at a page.

“In the example overleaf of the Branch309 basket page, EyeQuant predicts that user attention will be focused on
the product and the main call to action. At first glance this may look good but it shows that customers might not
notice the delivery method picker. This would cause a problem as choosing a delivery method is mandatory
before proceeding.

Mobile Web Design and Development Best Practice Guide Page 93

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Top tip from Schuh (cont.)

“I was concerned that this could cause some user frustration. We then revisited the design, simply adding a
slightly higher contrast background to the heading; EyeQuant indicates that this should be enough to increase its
visibility.

“We have event tracking for the error where the customer does not choose the delivery option; A/B testing
verifies that there is a problem when the heading is less visible.

“For Schuh, we have changed it further, removing the mandatory option choice.”

Stuart McMillan, Deputy Head of Ecommerce, Schuh

Mobile Web Design and Development Best Practice Guide Page 94

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 This stripped back approach to design is not without its challenges, not least of which are the
competing views of various stakeholders. Everyone insists their feature/link/widget is vital to the
success of the page and must appear. There were heated discussions and nobody got exactly what
they wanted.

Stuart thinks that in many cases Schuh didn’t actually strip it back enough, but the business has
plans to split test many small elements to work out how much they would be missed if they were
removed or deferred to a deeper page. The footer navigation is a classic example of this: Stuart’s
opinion of footer navigation is that it often is a place to dump links that someone says they have
to be on the page but nobody can think of a better place to put them. He thinks that unnecessary
links/UI elements dilute the saliency of necessary links/UI elements.

If your design is going to work on mobile as well as desktop, you have to make sure you don’t
waste space with unnecessary page elements.

Top tip from Schuh

“As well as making sure we removed excess UI clutter, we also looked at element priority. While notions of the
fold may be of less importance than they once were, we wanted to make sure that the most important elements,
including the main call to action, were visible on the first page load without needing to scroll.

“Here in this example of our product page, all important product details are visible on the one screen; we have
scrolled the page down automatically past the navigation:

Mobile Web Design and Development Best Practice Guide Page 95

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Top tip from Schuh (cont.)
“Here’s the Branch309 product page over the three different breakpoints (mobile, tablet, desktop); there is a real
consistency between the designs.”

Stuart McMillan, Deputy Head of Ecommerce, Schuh

Another important part of Schuh’s design methodology was page speed. To have one site for all
devices, it had to work well on all connection types. Again, simplicity was Schuh’s friend here, as
well as its mobile first approach. If the business could build it well enough to cope with a slow
mobile connection, then it would be fast on desktop by default. Site speed is essential for a good
user experience; it’s also becoming more important for SEO.

In the next chart you can see how site speed has improved for Schuh over the past 12 months. The
web team had been making improvements anyway and the responsive launch in late November
has continued this trend.

Mobile Web Design and Development Best Practice Guide Page 96

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 Figure 30: Page speed trends

The Branch309 result

“We put the site live and conversion went up. However, in all honesty, I would not put this down to responsive.
Yes, we were now providing an experience for users on mobile but we could have given them a mobile site and
had the same result. We saw a conversion uplift on desktop; I’d put it down to one thing: we provided them with
a better experience. We actually thought about what was a good experience, designed and built as a unified
whole.

“What it does give us is an excellent single platform to take higher and higher. This will be one of the major wins
when we finish the Schuh rebuild: a fantastic platform to support future growth.”

Stuart McMillan, Deputy Head of Ecommerce, Schuh

4.7.2. Ted Baker

Acknowledgment
Thank you to Michelle Sheppard, Business Analyst at Neoworks, for providing this case study.

Background

Established in 1988 as a shirting specialist, Ted Baker London is a global brand fusing together an
irreverent sense of humour with steadfast attention to detail to deliver fashion that is anything
but ordinary – and it remains one of the only brands to be built into an international designer
label without an advertising campaign.

Eve Henrikson, Head of Ecommerce at Ted Baker, spearheaded a project to overhaul their online
business with a view to develop a solution that would be flexible enough to support their current
operations as well as the brand’s future aspirations. Using a responsive web design approach, Ted
Baker demonstrates that a carefully considered ecommerce platform, built around well-defined
business objectives and customer needs, together with a realistic understanding of its goals and
limitations, is a worthwhile investment.

Mobile Web Design and Development Best Practice Guide Page 97

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
The goals

For Ted Baker the goal was to have a website that functioned exactly the same regardless of
whether the website was being viewed on a desktop or mobile phone. This was so much more than
just making the site look good on any device; it was about delivering a seamless customer
experience so that the act of shopping online was as easy on a mobile phone as it would be on a
PC.

The three obstacles Ted Baker was looking to overcome were:

 Improve the performance of their website.

 Sweep away restrictions to their efforts to internationalise their brand and have a localised
offering.
 Solve the problem of managing different websites for different devices.

The approach

Responsive web design (RWD) – the new buzzword on the tip of the tongue of anyone involved in
digital content or design.

RWD isn’t the only answer to delivering online content to multiple devices and there are instances
where a mobile application is a more suitable solution, but in the case of Ted Baker it was the best
strategy. This decision was driven by the designs templates which were targeted for a mobile
phone display and a desktop display, together with the fact that it was thought that one code base
would be easier to maintain. The website is delivered in such a way that it met the requirement of
functioning in the same manner whether a user was shopping on their mobile phone or on a
desktop.

The result

The project took an agile approach to the development of the ecommerce platform. Along the way
a number of technical trials had to be endured before the shiny new website was rolled out.
Challenges like inconsistencies present in the designs compelled the UX team to reconsider their
approach; this necessitated more code being written to account for the deviation and the decision
was taken to go with two breakpoints on the grid, rather than the initial preference for three.

This was less a compromise and more a solution as, despite these exigencies, the site snaps neatly
between PC and mobile views and operates without any visible loss of performance – so pages still
load smoothly.

Unveiling their new website in early November 2013, the teams collaborating on the Ted Baker
project solved the challenges they’d been tasked to overcome:

 Ted Baker is no longer restricted in their international offering and can now have websites
tailored to their chosen territories.
 New merchandising opportunities, allowing Ted Baker to link styles, display products at
colour level and have on-site search, improved their ability to market their products.
 Managing different websites for different devices was corrected by their adoption of RWD.

In the chairman’s statement on group performance, ecommerce generated £9.4 million for the
company (51.6% increase in sales) in 2013/2014 – showing that RWD together with a carefully
considered ecommerce platform and a solid understanding of customers is a recipe for success.

Mobile Web Design and Development Best Practice Guide Page 98

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
5. Adaptive Web Design
Contributors
This section was written by Markus Karlsson, CEO at Affino (@MarkusKarlsson), David Skerrett, Managing
Partner at Nimbletank (@skegz) and Matt Curry, Head of Ecommerce at LH Group (@mattycurry).

Adaptive web design is credited to Aaron Gustafson. It is similar to responsive design and Aaron
prescribes a similar mobile first approach to the process.

Adaptive web design is about designing different layouts while enhancing the experience as much
as appropriate, based on certain devices. Using browser and device detection, different pages are
served up to enhance the experience based on the context of the user. It provides the ability to
predefine specific layouts to popular screen sizes.

If context is king and budget is no object, then adaptive currently takes the crown.

But budget is always a big object…

Adaptive web design is no longer the primary approach to determining the size and presentation
of a webpage. The era of m-dot sites (explored in the next section), the ultimate in adaptive
design, is a fading one and responsive web design has taken over when it comes to delivering
optimised layouts to end users.

Go back a couple of years and adaptive and responsive web design were frequently used
interchangeably when describing what is now known as responsive design. Gradually responsive
web design has moved into the ascendancy and is now the dominant approach to delivering web
interfaces that have an optimised fit on the screen.

But adaptive and responsive don’t have to be mutually exclusive. A website built on a responsive
code base can use server-side adaptive techniques to customise the presentation of content and
features to mobile users. It’s important to understand how adaptive design works and the pros
and cons for adopting this development approach, which is often used alongside responsive. In
this section we take a look at the implications of using adaptive web design.

Adaptive, defined and contextualised

“Adaptive design defined: layout is determined server-side enabling the delivery of the most appropriate version
of the site based on the functionality of the device.

“If RWD is the silver bullet, then adaptive is the gold standard, particularly for travel and retail brands.”

David Skerrett, Managing Partner, Nimbletank

Mobile Web Design and Development Best Practice Guide Page 99

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
5.1. What does ‘adaptive’ mean?
Adaptive and responsive – common ground

Perhaps a little confusingly, responsive sits within adaptive and they share similar principles such
as using media queries to apply CSS rules based on screen size. Both adaptive and responsive
have similar objectives too: they seek to provide the optimum experience on a single website when
it’s viewed on a multitude of devices, from desktop to mobile and tablet devices, and anything in
between.

A key distinction is that adaptive uses JavaScript, responsive doesn’t and with adaptive, the
changes are made on the server side rather than the client side.

Understanding what adaptive means

“The alternative to going responsive is to adopt a technology known as adaptive delivery, something more brands
and businesses are turning to these days.

“With adaptive delivery, the most significant difference is that the server hosting the website detects the devices
making requests to it, and uses this information to deliver different batches of HTML and CSS code based on the
characteristics of the device that have been detected.

“Using an adaptive design approach, a server can choose how to optimally render pages, as well as enhance or
remove functionality on the fly, based on the capabilities detected, as well as information known about the
particular user.

“The most important thing adaptive delivery allows you to accomplish is a highly differentiated experience that is
built for the specific intent of your mobile customer. A good example is Lufthansa’s mobile website, which
focuses on the actions a mobile user is most likely to take, such as looking up their itinerary, checking in, and
getting flight status information.”

Ravi Pratap, CTO, MobStac [Source: Venturebeat.com64]

64 http://venturebeat.com/2013/11/19/responsive-design-adaptive/

Mobile Web Design and Development Best Practice Guide Page 100

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
5.2. How does an adaptive website work?
If RWD is the silver bullet, than adaptive is the gold standard

Companies often design mobile sites for the lowest common denominators, such as screen size,
device, browser and OS, which can mean ignoring all the other exciting stuff that mobile apps
provide, such as location. If your business could benefit from delivering a more
contextually relevant experience, then adaptive design, while it is an expensive
solution, could be worth the investment.

Adaptive sites are created in several different versions beforehand. The server detects factors like
device and OS, and then sends the correct version of the site. Adaptive design is a lot more
complex and expensive, but it’s the only way to reach the broadest mobile audience. That’s
because responsive design uses CSS media queries, a relatively recent technology that is not
supported by older mobile phones.

Adaptive design’s magic ingredients

1. Progressive enhancement
Where you provide a baseline acceptable experience and make judicial choices to layer on top
additional device relevant functionality, such as adding a ‘Use Current Location’ button.

2. Device detection
Adaptive uses code based browser sniffing to change presentation, based on a large database of
device capabilities, and serve up the most appropriate version of your site. Like responsive,
adaptive uses fluid/proportional based sizing but its actual definition is that it’s breakpoint based
(e.g. changing at specific points like 1280, 800, 640, 320px).

Adaptive vs. responsive – the key differences

 With responsive the layout is determined on the client side – the layout decision is made on
a user’s browser, so the same file is sent to all consumers but significant parts of the file may
be hidden from the user.
 With adaptive the layout is determined on the server side – layout decisions are made on
the web server, not the client or browser. The server detects factors like device and OS, and
then sends the correct version of the site on the fly, making it quicker for the consumer.

The other key difference is in regard to feature phones, thanks to adaptive design’s more
sophisticated device detection scripts. Low-end mobile phones are not capable of understanding
media queries and require a more complex solution. For low-end devices in developing countries
in Latin America, Asia and Africa, you could serve the lightest content such as automatically
streaming lower-resolution video to users with less bandwidth, lower-power processors and worse
batteries. This means more reach for your site to more mobile devices.

Finally unlike RWD, with device detection scripts you may not even be able to tell that a website is
designed using an adaptive approach if you only view it on a few devices. No guaranteed party
trick for your boss when you pull the bottom right of the browser window inwards to show the site
going squishy!

Adaptive functionality examples

 Can this device access my location? If so, inject a ‘Use Current Location’ button onto the site
in addition to the basic store finder form.
 Does this device understand touch events? If so, make this image carousel swipe-able in
addition to the ‘previous’ and ‘next’ buttons.

Mobile Web Design and Development Best Practice Guide Page 101

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
  Does the browser support HTML5 canvas? If so, replace the static image with a canvas
element.

These are all concrete examples of how experiences can adapt based on the capabilities of the
device/browser.

5.3. Technical and commercial challenges

Adaptive design uses a series of static layouts, based on breakpoints. Unlike responsive, adaptive
files do not respond once they are loaded. If you introduce too many breakpoints it has huge
effects on resource and budget, so it’s much better to restrict initially based on device strategy and
choose the highest penetration pixel points for each type of device. You can reduce the cost and
complexity by keeping the number of variants down. For example, you may design a webpage at
three different sizes: 320 as a base level for mobile phones, 760 pixels for tablets and 960 for
desktop browsers.

Choosing the key devices upfront is therefore a critical decision. Use your web analytics data and
other analytical tools to help you.

Addressing the ever expanding mobile device landscape using an AWD method will add
exponential cost in the form of longer development cycles, more testing and maintenance. It’s
important to understand this implication for the business.

As with any site development, web teams should look at their current user behaviours and device
use as well as their incumbent platform and technologies before scoping such a radical change.

5.3.1. Decision criteria

Current systems

Assuming you just have an existing desktop site, you have either made some concessions to
mobile in terms of graphic simplicity/scalability and layout or ignored it entirely. For once the
latter approach would be better suited to those looking to go adaptive, as you will be looking to
answer the question of what is the best experience for specific devices.

If you have an existing mobile site, served through an m-dot or similar redirection mechanism,
then the important question to answer is how is this mobile site managed? Through its own CMS
or does it share systems with your desktop site? Does your mobile site work by consuming
product feeds and scraping content from your desktop experience? In which case, while you’re
refactoring content and serving into a mobile-specific UI, you work off of a single repository of
content and your images will simply be scaled and compressed.

If your mobile site uses a shared CMS, then you will have much of the logic in place to store
different but analogous content to dynamically serve, dependant on device and context. If not,
you will find the most significant part of your development to be back-end, creating a process to
store the multiple versions of content and logically link them together to simplify your production
workflow.

Furthermore, if you think a RESS model will better suit, the requirements of responsive design
also take effect i.e. a minimalist design with fluid layout within each of your device templates.

Current users

Your decision to ‘go adaptive’ should be user-based. Can you envision a conversion rate increase
high enough to offset the development and maintenance overheads? The best way to decide this is
to look at your analytics tools to understand the current behaviour of your users.

Mobile Web Design and Development Best Practice Guide Page 102

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
The major selling point of adaptive design is that it can offer the best solution for the user, given
the device they’re using and the environment they’re in. So what we’re looking for are noticeable
changes in the pages viewed (both in terms of number of pages and the pages themselves),
conversion rate and bounce rate dependant on device (both resolution, viewport and functionality
such as input method), network or user state (if you store this as a custom variable or dimension).
Network is important; do users of the same device act differently when on a broadband network
to a mobile network?

From this data, you can expect to build up a portfolio of device and use cases. Do any of your
devices have similar resolutions and functionality? You would group these into a device type to
target.

If you’re implementing RESS, you can then go a step further to target resolutions not available via
the user agent, such as super-wide desktop resolutions that are frequently used but rarely catered
specifically for.

It’s important however to keep your device and use case portfolio to a manageable size because in
a pure adaptive scenario you’ll be treating each as a separate website.

Technology

Adaptive design hinges on having a robust device detection library. While it’s possible to develop
this in-house, such libraries are now available as commercially licensable solutions, either cloud-
based or locally installable as an enterprise solution.

How elaborately is your content distributed across content delivery networks? CDNs may only
cache a single version of your content, irrespective of the user agent that it is destined for. You
may wish to disable caching at implementation, then selectively turn back on depending on user
agent support.

People

Once you’ve decided that you are technically capable of developing an adaptive site, you need to
determine whether or not your content, trading and creative teams are robust enough to handle
this increase in expected output.

The move to AWD means a move to a multi-site mentality. You can expect to increase the
workload across your teams, as they will be performing their current functions multiplied by the
number of devices and user contexts you are targeting.

Your UX and QA teams will see the largest increase in workload. While there is a sizeable
opportunity presented by AWD to create best-fit experiences per device and per user context, it
does come at a cost. Pure AWD delivering full-page templates to devices will simplify the QA
workload to just concentrate on your device portfolio. However, a move to a more component-
based model, where devices will have functionality overlaid dependant on capabilities (for
example, some mobiles will have touch, others not), means an increase in the combinations of
device and function that your QA team will have to account for.

If improved conversion rates come at a cost of additional headcount, as well as increased

developer time for rollout of new features, you may find you’re not making an overall return on
investment.

Mobile Web Design and Development Best Practice Guide Page 103

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
5.3.2. Critical success factors
Firstly, you want it to pay for itself within a given timeframe. What is your anticipated increase in
conversion rate for the devices you are targeting? Given your current visitor rates for those
devices, how long will it be before you see a return? Since you will be developing specifically for a
device, you should expect higher conversion rate increases than through responsive design, where
you are just refactoring existing content and layout.

Without going too deep into technical implementation, is your current platform capable of
adaptive delivery without having to create a new instance of your platform for each device? For
example, can your CMS be abstracted enough to allow for multiple headers, footers and
merchandising blocks per device? Similarly, you will need to develop for multiple sizes and crops
of the same image, stored logically. How would your platform provider consider this move? You
need to ensure that your provider isn’t anticipating charging an increased licensing fee for these
‘new’ sites.

At the user end, you might wish to return different content (most likely visual merchandising) for
those who are logged in. Traditionally this would be done client-side using user cookies, however
as session state (and any session variables) are available to you server-side, you may want to
incorporate this into your library of adaptive components. Is this functionality something you can
test on a user segment client-side first, to measure uptake and improved conversion before it
reaches the adaptive development specification stage?

You will need to draw up your KPIs for the development project; how will you measure these once
you have gone live with an adaptive site?

 Conversion improvement
– While theoretically you could implement an adaptive site within an A/B testing
environment (by recording at server level whether the standard or an adaptive template is
served), this would create additional development overheads and complexity to a project
you have already committed sizeable resources to.
– The lack of a control group means you will need robust historical data on conversion rates
by device and by user segment to compare with.
– For your comparison to be accurate, implementation should be scheduled during ‘peace
time’, that is any month that does not sit within a peak trading period or when other
significant changes are taking place. In practicality though, in a busy ecommerce business
this is rarely possible!
– Post-implementation user testing and a pre- and post-sampling of a task completion rate
metric will both be a measure of success and will inform your next design and development
iteration.

 Page speed
– Analytics tools like Google Analytics will provide a per-device/per-network type level of
statistics that means you can set a benchmark prior to development, as well as a target
improvement you will set as a goal during development. Furthermore you can use Google’s
PageSpeed Insights to ensure you are fully optimising for each device type.

 Minimising overhead increase

– As previously discussed, staff overheads can increase dramatically as multiple sites are now
being managed. As a web manager, your role is to ensure that teams are properly balanced
and tasked so that the sites are being resourced relative to their rate of return. You may
wish to create separate creative, development and UX teams, yet have singular content and
QA teams.

Mobile Web Design and Development Best Practice Guide Page 104

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
5.3.3. Impact on the business of going adaptive
When you build either an adaptive or responsive website, there has to be a fundamental change in
the mentality of the business from “we have this one site” to “the user may see this differently”.
One of the actual reasons standalone mobile sites don’t convert as well as their desktop
counterparts is that they are simply not given as much attention. This means inconsistencies, UX
problems and layout issues can creep onto a mobile site unnoticed, demanding a more structured
approach to sign-off and QA processes, including a rigid workflow that covers your device and use
case portfolio.

The structure of your development team will also change. You may wish to separate out the team
into device-type groups, with developers, UX and design members focusing on a single device
type. However, some front-end development must be considered with a level of abstraction,
thinking about functionality rather than device. You wouldn’t, for example, include a touch event
JavaScript library on a device with keyboard input.

There will have to be a change of culture within creative and content teams about the context of
the user. You will already be optimising images, however, as adaptive allows for a level of art
direction your creative team will be cutting multiple of images on each brief, so your workflow will
need to accommodate this.

You can expect the user/device culture to spill over to trading and visual merchandising. Do
mobile users purchase fewer products? Would bundling help you increase mobile AOV?

Finally, having a robust reporting framework that looks at devices and type of users in place is
most likely what brought you to implementing adaptive design. However, ensure that this is
ongoing to identify any further changes in behaviour and to measure your successful
implementation.

5.3.4. Mitigating the risks of adaptive design

In the long term, the cost of maintaining your adaptive site for your portfolio of targeted devices
will be larger than the initial cost of development. You priority will be to manage this increase in
expected output per team and maintain a headcount that continually adds to revenue.

One of the pitfalls of adaptive design is over-optimisation. It would be nearly impossible to target
individual devices, so you’ll want to ensure a manageable number of groups of device types within
each development iteration.

Following a phased approach

“Taking progressive enhancement and applying it to the device you’re targeting, you can build up a phased
approach, splitting out your supporting devices into new groups of device types at each phase.

Phase 1
Desktop and Tablet Mobile

Phase 2
Mobile
Desktop Tablet Mobile(Low Speed)
(Broadband)

Phase 3
Mobile Mobile (Low Speed)
Desktop Tablet Phablet
(Touch|Broadband)

Mobile Web Design and Development Best Practice Guide Page 105

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Following a phased approach (cont.)
Phase 4
Desktop Phablet
iPad 3 and above iPhone 4/5 (Broadband)
iPad Mini Samsung Galaxy S3 and above (Broadband)
Other Tablet Other Mobile (Touch|Broadband)
Other Mobile (No Touch|Broadband)
All Mobile (Low Speed)

“And so on, ensuring that there is an anticipated increase in conversion rate, projected revenue over time and a
measurable change in user behaviour at each iteration. Typically a site would be very highly trafficked to warrant
phases 4 and above.”

Matthew Curry, Head of Ecommerce, Lovehoney

5.4. Implementation considerations

5.4.1. Adaptive layers of progressive enhancement
One of the key pillars of the adaptive movement is using server-side browser detection through
the browser string. The big issue is that it is not entirely reliable as mobile and corporate networks
frequently over-cache, meaning that layout code intended for one device is delivered to others.
That in turn means that a proportion of the customer base will have a degraded experience.

Where does that leave adaptive web design?

The best way to approach adaptive web design is to deliver layers of progressive enhancement to
the user interface, which allows you to create delightful user experiences.

Touch is the most obvious layer to be considered and is frequently the first that is added. It does
not make sense to serve a whole layer of code that is optimised for swiping or multi-touch when a
device doesn’t support it. Instead the code should only be sent through to compatible devices.

Other layers include geo-location, camera uploads, voice input and using the accelerometer
(shake to reset). Adaptive web design can also be used to optimise speed and to deliver better user
experience depending on the user context.

The key for delivering successfully on AWD is to use client-side pull to identify the capabilities of
the browser and to pull in the correct code from the server, rather than rely on browser strings.

5.4.2. Design trends

It’s worth looking at how design trends are evolving to see where adaptive web design is winning
and where it is retreating. Going back a couple of years, many websites were optimised around
specific devices. The most frequent way you could see this was in the styling of the buttons and
other user interface flourishes on the webpages when viewing mobile-optimised pages on the
iPhone.

The device-specific approach has been steadily fading with the ascendancy of Android and the
impossibility of tailoring the user experience to the multitude of Android versions and derivatives.

Mobile Web Design and Development Best Practice Guide Page 106

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 At the same time flat design has been in the ascendant, first championed by Microsoft with the
Metro/Modern interface and since then taken up by Google and Apple.

Instead the evolution has tended to be towards device groups i.e. desktop / laptop vs. tablets vs.
smartphones. The key exception is in ecommerce where even a fraction of a percentage change in
conversion rates can have a big impact on online revenues. Delivering adapted experiences based
on the device brand experience can have a positive uplift in conversion rates.

This has allowed web/UX designers to focus more on the core experience and less on having to
worry about the specific device that it is running on. UX/UI design considerations for mobile are
covered in more detail in Section 7: UX/UI Design.

5.4.3. Context is king

The first major trend for adaptive design was the advent of the mobile-optimised site, or m-dot
site. This worked well on feature phones and was a big step up from the experience of trying to
view a full website on a 1.5″ browser. As soon as the iPhone was released it was clear that the days
of the mobile only site were numbered. Too frequently you were looking at a site optimised for a
postage stamp on a device capable of much more.

Since then, with every progressive development of device capabilities, the lines have become more
blurred. How do you determine upfront what the user experience is going to be for the end user
when you don’t know what they’re doing? The user could be using a keyboard with the iPad or
they could be swiping on a slate. Simple device/browser detection can lead to flawed user
experiences and it has moved more of the core interface logic to the browser and further away
from the server.

It means that the era of determining what to serve from the server-side is waning and good
practice is evolving towards delivering this from the client/browser. It is beneficial to focus
delivery on the capabilities and context for each and every user session and not determine the
user experience on preconceptions derived from the device the user is on.

That said, there are some situations in which mobile-specific sites have an advantage, or when
using an m-dot site as a gateway to a future responsive web design is a logical development path.
This is covered in more detail in the next section.

5.4.4. Technical challenges with going adaptive

The two biggest technical challenges to going adaptive are detection and caching.

Detection

This is where you are identifying what the browser, device and screen size are. Detection needs to
be smart and be led from the browser, which should result in the optimised experience being
delivered.

Caching

Caching is where you serve pre-generated code to the browser. Caching is a potential minefield
that needs to be navigated with extreme care.

To deliver at scale you need to focus on extremely capable cache management. Getting caching
right on the delivery side allows you to deliver pages and assets at speed, getting it wrong means
slow and imperfect user experiences. Understanding how network caching can catch you out is
key to avoiding most of the mistakes and pitfalls that can trip you up along the way.

Mobile Web Design and Development Best Practice Guide Page 107

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 There are many points where the code you’re looking to deliver from the server might be cached:
on the servers, on the content delivery network, on the ISP’s network, corporate networks and
right through to the mobile network provider. When that caching happens, for it to work reliably
the caching servers have to cache for each and every browser string, which in turn takes up many
more resources than if they cached in a more generic manner. This is why they are frequently
tuned to cache on a higher level.

To effectively deliver adaptive webpages you need to overcome the biggest challenge associated
with it: speed. By definition, adaptation means providing different user experiences to different
users in differing contexts. This is why a typical webpage is three times the size of a mobile-
optimised webpage and twice the size of a regular webpage.

There are many causes for pages using adaptive design being larger than usual. The primary
reason for the increased size is that they have to work across multiple screen sizes and
resolutions, and have to handle the transitions between them. Different sized screens require
different sized text, different spacing and layout changes, which demand additional CSS and
JavaScript to the scenario where you are simply delivering to one screen.

Adaptive delivery can overcome a big part of the challenge but there are significant limitations
that you must adhere to. The first is that you can’t always know upfront what the end user is
capable of based on the browser string. So you can’t build a pre-optimised delivery approach
based solely on the browser string, you also need to do as much verification as possible client-side
(i.e. on the browser).

The detection gap

Until network providers commit to not over-caching, there will always be an issue with knowing
exactly what the device is that you’re delivering to. To close the gap as far as possible, don’t just
rely on the identified browser string via the server. You should also use a client-side JavaScript
library to verify the browser where possible, to maximise the chance of serving the correct
adaptive code. Calling an image via your application with a unique identifier for the session
ensures the best chance of getting an accurate browser string, which is what Google does for
Google Analytics.

Better yet, wherever possible add additional functional detection and serve adaptive code based
on device capabilities that you have identified. All this means developing a smart detection
package, which has a cost, but it will result in the best overall user experience.

5.4.5. Overcoming caching challenges

The biggest challenges around adaptive delivery centre on caching. You need to optimise your
page delivery speed and overcome the hurdles of network caching en route to the user’s browser.

Depending on the level of personalisation in content delivery you will be geo-targeting/blocking

the page content. This means at the simplest level displaying differing content based on the user’s
location but more significantly it can mean displaying different products, prices, currencies,
delivery methods and languages. It also means that you will be presenting different user interface
capabilities or indeed an entirely different user interface depending on the actual browser/device
capabilities.

Separating delivery to logged-in users, guests and bots is also essential for delivering optimised
performance. You can do much more preparation and packaging of the content for guest users
and bots than for logged-in users who have a fully personalised experience.

Network caching is the bane of most well laid plans when it comes to delivering pre-defined pages
to end users. Mobile carriers and corporate caches tend to be extremely overzealous when it

Mobile Web Design and Development Best Practice Guide Page 108

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 comes to caching content. This means that pages optimised for one user/device will be shared
around entire networks if you don’t get this exactly right.

It is also the main reason why it is best to focus the adaptive delivery approach on ‘browser pull’
rather than exclusively ‘server push’. Otherwise you will, in some scenarios, have content
personalised for one user served to another.

Fundamentally you have to architect for the worst-case scenario, which is full end user content
and experience personalisation through to an over-caching network, at scale.

This means breaking down each page/user interface/content element you will be serving,
ensuring that it can be cached in a static package wherever possible and delivered in the optimal
manner, preferably as static elements (CSS/JavaScript /HTML/media) via content delivery
networks (CDNs).

When the user then hits the URL and it is fed through, you need to serve the appropriate content.
For guest users and bots this could be entirely pre-cached from one of a number of cached
variants (depending on location/currency etc.). For a more personalised experience you need to
pull in the elements dynamically with caching optimised around each element, different user
access levels and pre-cached elements. These then need to be organised into the HTML package
with associated CSS/JavaScript/media elements.

Essentially you’re caching static universal elements that are served to all users and dynamically
serving up the personalised elements within them, as this speeds up the whole process and
minimises the server load.

5.5. Key dos for adaptive design

A key element in delivering the browser pull/server delivery for the adaptive layers is the
underlying server stack. There are many approaches to this and there are many pros and cons to
the different underlying technologies being used. There are certain best practices that will help
you deliver this at speed.

Focus around delivering based on the browser capability

Build the adaptive layers on top of it. This does not mean you focus on specific versions of a
browser, rather the capability that the browser may have e.g. touch swiping support, camera
upload, microphone support etc.

Architect around auto-failover/auto-scaling

This means running your server nodes on an auto-scaling cloud setup. This can be in-house, on
Amazon or other cloud providers, or across multiple providers. Ensure that you can scale
effectively with the minimum of cost penalties – this means running on open source/cloud
services as far as possible across the technology stack.

Architect around smart-caching

This ensures that every element that can be cached is cached, whether it is CSS/JavaScript, media
assets or even HTML elements. Ensure that these assets are delivered via CDNs wherever possible
and where not that they are stored in packets and served from memory.

Minimise the number of elements

It is essential that you do everything possible to have the smallest number of distinct
CSS/JavaScript elements and that you deliver the media assets based on the screen size and
resolution of the end user device.

Mobile Web Design and Development Best Practice Guide Page 109

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 Focus around optimised Ajax-based (dynamic) delivery of personalised content

For example, the shopping basket, personalised ads, personalised content and adaptive user
interface layers. This will allow you to optimise the end user experience by allowing maximum
caching of content throughout the delivery and delivering the personalised content in the fastest
way with the minimum of resources used.

5.6. Common mistakes and pitfalls

Go back quite a few years and there was an era when everything had to be Netscape 1 compatible.
It lasted for many years and led to a time when web user experience was severely stunted.
Virtually overnight though the focus changed from being compatible with the ancient browser and
became much more focused on improving the user experience.

We are now going through the second major generation shift with the move towards fully
responsive/adaptive delivery. Core to this are HTML5, CSS3 and JavaScript. The single biggest
mistake is to architect around the principle of graceful degradation, which does not include
support for any of these elements.

The principle of graceful degradation is that you architect your page to work with different levels
of browser capabilities. At one end it might be whether it works with camera uploads or
microphone input, at the other end it might be whether or not it is running JavaScript.
Responsive and adaptive web design both require JavaScript to be running, so it is no longer
possible to degrade to the level where it is not running.

The second biggest mistake is not taking into account just how far network providers can hijack
the delivery process, which is why you must focus on browser pull for an increasing part of the
page package. See the detection gap above.

Not having an auto-scaling architecture will also mean that you will need to heavily over-invest in
your infrastructure, as an increasing part of the page delivery is dynamic and therefore processor
intensive.

5.7. Creating an adaptive code base

5.7.1. Coding for adaptive layers
There is a multitude of factors that will have an impact on your code base. Many are driven by the
technical and network requirements outlined above, others will depend on the coding
methodology. The simplest approach is going to be to focus on developing great browser
capability detection and then using this to serve up appropriate adaptive user interface layers.

Given that many of these layers, such as touch, can be served up as CSS and JavaScript packets,
much of this work will be around the conditional logic of what static packages are delivered. It
also means that on the initial page load you will want to lazy load and pre-load many of the user
interface elements that the user might later be using on your site.

Lazy loading means deferring the loading of page elements until they are required using
JavaScript. For example, you might have a product scroller and display three items, then only
load up the remaining items when the scroller is swiped or the navigation buttons pushed.

Pre-loading is where you might pre-load time-critical elements, such as elements used for the
shopping basket, so that there is a minimum time delay when the user comes to check out.

Mobile Web Design and Development Best Practice Guide Page 110

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 This will often mean larger page downloads for the user, but since these elements are only loaded
after the page has rendered on the browser they will simply speed up subsequent interactions and
will not affect the speed at which the user can experience the initial page.

If you are driving the initial page load from the server in an adaptive way, then depending on the
identified browser you can send through pre-optimised page parts e.g. mobile versus desktop
header.

5.7.2. Maintaining an adaptive code base

Developing and maintaining the adaptive code layers around the capabilities they deliver is
essential to having a well-structured adaptive code base. Ensuring that the adaptive layers are
developed as tightly as client/server objects/packages as possible will ensure that they can be re-
used effectively throughout your web application. It will also ensure optimised delivery of the
front-end code and speed for the interactions and back-end processing.

By client/server objects/packages (CSOPs) we mean using the best browser and device detection
capabilities to optimise the interface elements and code sent through e.g. drag-and-drop picture
uploading on a desktop vs. camera upload interface on an iPhone.

There are many frameworks that can help with this such as jQuery where you can then use
existing components like TouchSwipe, a jQuery plugin for touch devices. In practice there are lots
of options and selection is often driven by which one(s) will work best for you based on personal
experience.

5.7.3. Good house-keeping

To maximise performance it is critical that you deliver the browser-based code in an optimal
manner. It means minimal inline CSS and JavaScript and maxing out how you aggregate this code
into separate CSS and JS files.

To truly nail down the code minification, you will need to do a manual analysis of all the code
which is output, using Firebug or similar on the browser. This is because inline code is frequently
pulled in via plugins, using WYSIWYG editors and JavaScript libraries. Ensuring that the code
base is fully optimised is an ongoing process.

Whatever your development platform, having a defined methodology whereby you can code your
CSS and JavaScript to discrete files is key for adaptive design because it allows for minimum page
sizes and maximum beneficial caching.

Tools such as Google PageSpeed are very useful as a guide to the page performance. However, the
best tests are with real people, finding out how responsive they feel the page is.

A few key tips:

1. Make sure that the components you develop are architected securely and have been
thoroughly tested across all priority devices and multiple scenarios – any architecture is only
as strong as its weakest link.
2. Ensure that every function and object is secure by itself and can’t be called insecurely.
3. Code against cross-site scripting and SQL injection.
4. Have third parties validate the security and if necessary open your source code (at least
partly) to outsiders for validation.
5. Keep the adaptive code libraries distinct with very clear naming conventions built around the
adaptive layer they’re delivering – this will help with code re-use.

Mobile Web Design and Development Best Practice Guide Page 111

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
5.7.4. Code validation and quality assurance
Testing for adaptive design is very much a hands-on affair and is best done by making sure that
all the developers and testers have access to the key platforms. For most organisations this
actually means Android, iOS and Windows 8 devices.

It is essential that when developing new adaptive layers – for example, a photo uploader or touch
navigation – that you do real-world testing on all the priority devices and remote testing on lesser
ones. In fact, it’s essential that you develop the code with unit testing in mind as much as for the
end user; that way you can ensure the best performance and minimum issues throughout the
lifetime of any website or web application.

Below is a list of some of the many tools that can assist you with the quality assurance process:

 Browser capability
– BrowserSpy – http://browserspy.dk
– Browserscope – http://www.browserscope.org
 Remote device testing / automation
– BrowserStack – http://www.browserstack.com
– Selenium – http://docs.seleniumhq.org
 Local device testing
– Muir – http://labs.iqfoundry.com

5.7.5. Optimising for performance and page speed

Optimisation is dependent on having the right technical stack in place and coding for that in an
optimal manner.

Key recommendations include:

 Minimise HTML, CSS and JavaScript.

 Ensure code optimisation for caching.
 Defer non-essential JavaScript.
 Pre-load key user interfaces e.g. shopping basket.
 Deliver appropriate interfaces depending on capabilities e.g. drag-and-drop image uploading
vs. camera.
 Optimise mobile images.
 Use sprite sheets.
 Use compression.

Mobile Web Design and Development Best Practice Guide Page 112

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
5.8. Pros and cons
5.8.1. Key pros
1. Super-efficient page loads, much quicker on average than pure responsive sites
Adaptive websites are much better for load time performance and overall user experience. This is
because adaptive delivery works by only transferring those assets necessary for the specific device
and optimising images and multimedia content on the fly to suit display resolution and size.

For example, when a high-density retina display is detected, high-resolution images are
transferred and used instead of defaulting to high-resolution images for everyone.

This opens up the opportunity to have, for example, three weights of experience: high, medium
and low, and deliver these based on location, connection speed etc. So rich assets are developed to
quick smartphone owners connecting over Wi-Fi in developing countries.

2. Allows you to tailor the experience based on user intent and context
For some businesses, a mobile user’s intent is to engage with the business in a very specific way
that is different from their behaviour on a desktop website. The experience on an adaptive site can
be finely tuned to the device, so that it is intuitive, super quick and leverages things like location,
voice and HTML5.

3. No need to scratch your existing website completely

Developers don’t have to go back to the drawing board and re-code the existing website from
scratch. This is important because many websites are complex, with a lot of legacy code built up
over time, and scratching all the effort that has gone into it is generally not an option.

4. Reach the maximum mobile universe (more than RWD) including non-
smartphones
So if developing markets are important to your business this is the most inclusive globally robust
approach.

5. One URL with associated SEO and discoverability/sharing benefits

As is the case with RWD, this approach is Google friendly and reduces the need to maintain two
content management systems with the mobile-specific site development approach (see Section 6:
Mobile-Specific Website Development).

If you need a highly interactive, secure site that works for everyone who might ever visit your site
with any type of mobile device, then you have to create an adaptive design.

5.8.2. Key cons

1. Resource and budget heavy
Adaptive requires a large team of developers and the budget to handle the complexity that comes
with choosing to develop and support an adaptive site.

2. Complexity
Adaptive is a good approach, but creating too many separate designs takes a lot of work and can
defeat the purpose of trying to use one set of content on one URL.

Mobile Web Design and Development Best Practice Guide Page 113

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
5.9. Adaptive checklist
Choose an adaptive design approach if:

 Your consumer has different needs and intentions depending on device. Vertical categories
such as commerce/retail, automotive, alcohol, news and travel spring to mind. For example,
mobile users for airline websites are likely to be most interested in accessing current flight
information, checking in and accessing their tickets.
 You want to deliver an optimised experience on as many mobile devices as possible,
particularly if developing markets are important to your business in Latin America, Asia and
Africa.
 You can afford the most premium website development option available (perhaps coupled
with a RWD approach) – can you justify the return on the increased investment required in
order to differentiate your site against your competitors with a device orientated quick
solution?
 You want to sidestep RWD flaws such as load time and the handling of tabular/grid-based
information.
 You want one domain with associated search benefits and don’t want to maintain two
separate incidents of your CMS.

5.10. Example sites

Below are three examples of leading brands that have used an adaptive web design approach for
their mobile sites.

5.10.1. American Airlines

The most advanced adaptive web designs, such as the one American Airlines created at aa.com,
use a sophisticated auto-detection script to identify each device that visits the site and then
deliver the best version of the site, adapted to display based on the size and capabilities of each
device. In addition to screen size, that means removing large images or videos before delivering
the mobile version to low-end phones.

As a result, the American Airlines site doesn’t change if you drag the browser while you view the
site. However, if you visit the site on different mobile devices you’ll not only see different designs,
you may even see different content because with adaptive design you can send completely
different versions of your site to each device.

For example, on a smartphone check-in, boarding passes, flight status and Wi-Fi information is
prominently displayed, whereas on tablet and PC the login and booking process is more
prominent. This is acknowledging that the different user contexts vary across devices, meaning
consumers want different things at different times.

Mobile Web Design and Development Best Practice Guide Page 114

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Figure 31: American Airlines using an adaptive approach to mobile web

Mobile Web Design and Development Best Practice Guide Page 115

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
5.10.2. Lufthansa
The most important thing adaptive allows you to accomplish is a highly differentiated experience
that is built for the specific intent of your mobile customer.

A good example is Lufthansa’s mobile website, which focuses on the actions a mobile user is most
likely to take, such as looking up their itinerary, checking in and getting flight status information.

Figure 32: Lufthansa tailoring mobile content to specific user needs

Mobile Web Design and Development Best Practice Guide Page 116

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
5.10.3. USA Today
Another good example is USA Today’s website, which has been adaptively redesigned.

If you open the site on a desktop, you’ll notice that the screen layout doesn’t change as much
when the browser window is made smaller. But if you open on a smartphone or a tablet, you’ll see
a different layout, optimised for that screen.

Figure 33: Adaptive redesign by USA Today

Mobile Web Design and Development Best Practice Guide Page 117

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
5.10.4. eBags.com
A nice retail example is US retailer eBags’ website, which uses a combination of adaptive and
responsive techniques. The smartphone experience deals with menus and touch events
differently.

Figure 34: Adaptive and responsive redesign by eBags.com

Mobile Web Design and Development Best Practice Guide Page 118

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
5.10.5. Epicurious
Recipe site Epicurious chose adaptive in order to customise layout and content, thus enriching the
customer experience across devices.

Unlike a responsive website, which would load the same code across devices, this iPhone site only
serves smartphone-specific HTML. Notably, on a smartphone the users’ ‘recipe box’ feature is
prominently displayed in the navigation, making it easier and quicker to access favourite recipes.

Mobile Web Design and Development Best Practice Guide Page 119

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
6. Mobile-Specific Website Development
Contributors
This section was written by Tomas Honz, Director of Technology Strategy at Summit (@summitmedia), Will
Garbutt, Senior UX Manager at Summit and David Skerrett, Managing Partner at Nimbletank (@skegz).

Some websites are developed specifically for mobile, so they have a different user interface and
size to the regular desktop website, either with the same or different content. Usually these
websites sit on a unique domain, for example m.companyname.com.

Mobile users often display different behaviours to desktop users, so it seems pretty logical to have
a website built specifically for mobile users. However, this has become an out-of-date approach
for dealing with mobile devices due to device proliferation. Today there are so many different
sizes of device that having a separate m-dot site doesn’t necessarily give an optimal experience to
many users.

Due to the popularity of the iPhone and the Galaxy it’s a common mistake to think that mobile
phones have a standard size. However, Apple and Samsung combined represent less than half the
total mobile handset market share. The remainder comprises hundreds of different mobile
handset makers and a mind-boggling array of device types and sizes, especially in the Android
ecosystem.

That said, there is still a role for the m-dot site. In some cases the business case for investment in
a responsive site doesn’t stack up because the cost and complexity of updating a legacy platform
outweighs the projected revenue benefits. This section looks at the commercial and technical
challenges that a mobile-specific development approach presents to digital teams.

Let visitors switch between site versions

“Allow users to override the setting. I often find myself clicking ‘view the full site’ link more often than not,
usually due to restricted options and poor experience design of mobile sites. But having the choice is a good
thing.”
David Skerrett, Managing Partner, Nimbletank

6.1. What does ‘mobile-specific’ mean?

What defines a mobile-specific site?

A mobile website is a website built specifically for mobile devices. It doesn’t share the same code
base with the desktop website (or shares only parts of it) and is, in effect, a standalone website. As
a result, mobile websites can be customised to provide an entirely different customer journey,
functionality, page layout and design. They can also have a different navigation and catalogue
structure, pricing and promotions than a desktop website.

A separate mobile version of a site is hosted on a separate subdomain or subdirectory with unique
templates and a separate incident of the CMS to the desktop version of the site e.g.
m.domain.com. Mobile templates specific to the mobile user experience (stripped down
navigation, smaller image sizes, bite-sized content) are delivered. This type of mobile site is
sometimes referred to as an m-dot site. This approach provides a pure experience specific to
mobile devices.

In 2014 this feels like a legacy choice, the option you ideally shouldn’t have to make anymore. But
it is a valid way to turn the lights on as a quick fix, particularly for a more static non-commerce
site.

Mobile Web Design and Development Best Practice Guide Page 120

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
It can better cater for the mobile user by delivering tailored information that better suits the
location, customer intention and the smaller screen environment. The user interface can have the
customised look and feel of mobile applications and present only the information required
without cluttering the screen.

When a user’s browser requests a page, a ‘mobile detection layer’ on the hosting infrastructure
detects whether it is a desktop or mobile browser and redirects the user to either one or the other.
Tablet users are also redirected to either a mobile or desktop site depending on the tablet screen
size and how well the desktop site is optimised for tablet use. A well designed mobile website
should also allow users to switch from a mobile to a desktop website, usually via a simple text link
in the site wide footer that redirects to the corresponding desktop URL e.g. if the user is on a
category page it links to the matching category page on the desktop site.

As discussed in previous sections, the alternative to a mobile-specific website is to render the

desktop website differently on mobile devices, using the principles of responsive design.
Responsive design relies on flexible and fluid grids and will change pages to fit the screens of
mobile devices. However, unlike a standalone mobile website, it will use exactly the same page
templates and functionality, only hiding some elements from the user and changing the
appearance of others. Neither can responsive add new functionality nor provide entirely different
user flows.

An example of a standalone mobile website is the UK flooring retailer Carpetright overleaf.

The first image shows the homepage of their desktop website, which includes 28 various types of
navigational and functional elements.

Mobile Web Design and Development Best Practice Guide Page 121

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Figure 35: Carpetright homepage on desktop

Mobile Web Design and Development Best Practice Guide Page 122

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
The homepage of the mobile website only includes 11 of these elements, providing the
functionality users require so they can comfortably operate while on the move.

Figure 36: Carpetright homepage on mobile devices

As you can see, the desktop site uses far more complex page templates and offers more
functionality than the mobile-specific website. Some of the key differences include:

 Omitting some display elements such as banners and ‘info pods’.

 An entirely different layout for the mobile website.
 Removing the transactional functionality including basket and checkout from the mobile
website altogether (not a decision made lightly).

Mobile Web Design and Development Best Practice Guide Page 123

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
6.2. Commercial implications and challenges
Let’s start by making an objective comparison of mobile-specific site development versus
responsive web design using a standard set of ecommerce criteria.

The table overleaf highlights the major differences between a mobile-specific website and a
desktop website which adapts itself to a smaller mobile device screen using the principles of
responsive design.

Key: 1 best, 10 worst

Criteria Mobile-specific website Responsive web design

Rating Rating
Design freedom 1 5
Different functionality 1 8

Different content 1 8

User experience 1 6

Development costs 4-6* 2

Implementation times 4-8* 2

Hosting costs 2 1

Impact on existing platform 1-5* 2

Integration with legacy 1-10* 1

systems
Maintenance costs 2-5* 1

Impact on performance 1 7

Impact on conversion 1 5

Impact on SEO 5 1

Operations management effort 2-5* 1

*Depending on the platform used

The rating system in context

Design freedom
Functionality, layouts and style of a mobile website are not constrained by the existing desktop website in any
way and therefore, don’t impose any restrictions on design freedom.

Different functionality
Although a combination of a responsive design and adaptive techniques, such as manipulating the page
templates on the server, allows changing of some of the functionality, it also adds extra complexity and costs to
the project and the website maintenance.

Different content
As above, adaptive techniques can allow different content to be served to both desktop and mobile websites. This
too will add complexity and costs to the project as well as ongoing support and maintenance.

Mobile Web Design and Development Best Practice Guide Page 124

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
The rating system in context (cont.)
User experience
A mobile website can be fully tailored to a mobile user and as it is usually faster to load, it provides a better user
experience than a responsive website.

Development costs
Building a separate mobile website, which in some cases would also include the entire data integration, requires
far more effort than a responsive website running from the same code base as the desktop website.
Hosting costs
Hosting a separate mobile website requires an additional hardware or software mobile detection system as well
as the additional server resources required to run the website. The total website traffic will not increase and the
bandwidth is likely to decrease, due to the lower mobile page template sizes, but extra resources will be required
to run the mobile website application and also, if completely distinct from the desktop platform, a separate
database.

Impact on existing platform

If the existing platform already supports HTML5 and jQuery, building a new website won’t have any impact on
the platform. However, if it doesn’t, it will require either updating the entire platform or amending it in order to
allow using different technologies for the presentation layers of the mobile and desktop website, which requires
significant additional effort.

Integration with legacy systems

If the existing platform allows the building of a separate mobile website as another store, no extra integration
effort will be required. However, if the mobile platform would have to be built on a different platform, there will
be massive effort required to integrate all data and content again.

Maintenance costs
A separate mobile website will always require more effort to maintain than a single responsive website. If the
mobile website will be built on the existing platform the extra maintenance is likely to be limited only to its
presentation layer and the additional functionality, but if a separate platform will be required, all maintenance,
including the platform itself, will be duplicated.

Impact on performance
The layout of a mobile website will be simpler and more likely to include less functionality than the desktop
version. In addition to this, a mobile website will also be built using the lightweight mobile technologies such as
HTML5 and jQuery Mobile. This will lead to a reduction in application processing times as well as page template
file sizes, which will improve the mobile website performance.

Impact on conversion
The increased performance of the website and the user flows, optimised for the best mobile experience, will
increase the mobile website conversion rates.

Impact on SEO
Retailers who have a mobile-specific site do not tend to rank as well on Google as retailers who have a responsive
site. There are a number of reasons for this and they’re discussed in Section 8: Technical SEO for Mobile
Development.

Operations management effort

Managing two separate websites will require more effort than maintaining a single responsive site. In the case
where both websites run from the same platform the additional effort will be low, but in the case of two separate
platforms, it’s likely to be twice as much as it would be with a single responsive website.

Mobile Web Design and Development Best Practice Guide Page 125

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
In summary, a mobile website may require a greater investment from a business but this could be
offset by the better customer experience it provides that will ultimately deliver improved
conversion rates and positive brand experiences. Ecommerce teams should only consider building
a mobile-specific website if:

 There is a strong enough business case to justify it.

 The mobile website will have different functionality and support different user flows than the
desktop website, therefore delivering an improved experience for the customer.
 The existing platform allows creating and managing a mobile and desktop website from a
single installation without the need to duplicate the content, product catalogue, customer,
order, pricing and stock information and all operational management effort.
 The existing platform is outdated and will not support latest technologies such as HTML5,
CSS3 and jQuery Mobile.

To understand the additional questions that need to be answered, please see the flowchart
overleaf. It describes the decision-making process for an ecommerce mobile website but most is
applicable to content sites too.

Mobile Web Design and Development Best Practice Guide Page 126

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Figure 37: Mobile-specific site development decision-making process

Mobile Web Design and Development Best Practice Guide Page 127

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
6.2.1. Evaluating the commercial implication
If your research and business goals are steering you in the direction of a mobile-specific site, the
following are key areas that you need to evaluate and consider before you make your final
decision. Essentially, what you need to do is weigh up the investment of building and managing a
mobile-specific site with the expected ROI of providing the ideal mobile experience for your
customers.

Design

A mobile-specific site requires a new set of wireframes and page designs. You will be able to use
your existing brand assets, but the actual page templates will be different from your current site.
A UX expert is well worth the investment at this stage to ensure the most relevant and important
calls to action are present within the viewing space on the device. A review of your existing
analytics should also confirm which features and elements are most often clicked, to help guide
the layout you produce here.

Complexity

Although some of your existing code may be re-useable, you will essentially be creating a separate
code base when building a mobile-specific website. Therefore any planning and development for
the desktop site needs to factor in the additional time it will take to implement these changes on
the mobile site. For example, a new search facility for the website would need to be integrated
twice if a separate mobile website was built. However, having this separate code base means you
can also choose not to add the new feature to the mobile site if you deem it unnecessary for your
mobile users.

Cost and time

It is clear that with increased complexity there will be an increase in cost and time to manage the
additional code base of the mobile site. Cost and effort are also attached to the additional design,
testing and optimisation that need to be done. For example, site speed is key for mobile site
performance, so time needs to be invested in minimising and optimising code for the browser,
adding to the development time and cost.

Resource

Maintaining two separate sites will require additional internal resources to keep these updated.
Tasks such as managing promotional offers and reporting need to be replicated across both
platforms and could become time consuming. Before choosing a platform/supplier to build your
mobile website it is imperative that you ascertain what functionality exists within their CMS to
maintain the content without duplicating the entire content management process you already
have. So for example you may look for features that allow content in a WYSIWYG editor area to be
published to the desktop, mobile or both platforms simultaneously. If you have limited resources
internally to maintain the website, then this is a key consideration when deciding which approach
to adopt.

Integration

If you operate with fast moving lines or products with limited depth to the range, then it is
important to understand when selling the ‘last piece’ how the stock file is integrated with the
mobile site. Will the stock level be checked in real time during the basket and checkout process?
Or will both websites rely on a frequently refreshed stock file? With the latter it’s important to
ensure that double selling the last unit is avoided.

Mobile Web Design and Development Best Practice Guide Page 128

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 The best way to do this would be to upgrade your web infrastructure to support a real-time web
service call being made during the purchase process to ensure that your customers are purchasing
stock that is actually available.

Future proofing

Reworking may need to be done to adjust to changes in smartphone technology and browser
updates. When choosing a mobile-specific website, you should be considering emerging new
technologies, such as iBeacons and in-store tracking, to see if there are any benefits in having a
mobile-specific site.

SEO

It’s important to make sure you have not inadvertently created and published duplicate content
by offering the same content across two different URL structures.

Critical success factors

A sound business case
Prior to starting any project, it is important that you assign clear business goals and objectives that you can then
benchmark performance against. The principles here are the same with any project but it is important that you
assign specific goals for the mobile website, rather than reviewing statistics at an overall business level, and split
these between desktop and mobile, as differences will exist.

Conversion rate
The industry standards for mobile conversion rates are considerably lower than desktop and table, they can be
anywhere between 0.5%-0.95%. Based on your customer analysis and business goals, set yourself a conversion
rate target for each device and ensure your mobile site is meeting the goals you initially set out.

Site speed
You’ve chosen to build a mobile-specific site because you want to provide the optimum mobile experience; speed
is a key element of this. There’s no point in having a great mobile site if it takes forever to download. Site speed
directly impacts conversion rates and is something many retailers are now focused on when reviewing
performance of the desktop site. As mobile devices are often used on the move, with varying levels of
connectivity, a poorly implemented site can result in significant decreases in conversion.

User experience
Building a mobile-specific site gives you free reign to build the ideal user experience. There is no excuse for bad
user experience on a mobile device. Regularly review your analytics from both the desktop and the mobile sites,
to identify the key features, articles and elements that users are interacting with. Constantly adapt the mobile site
templates to accommodate these.

One of the biggest barriers to conversion on a mobile site, either in responsive format or mobile-specific version,
is that the checkout can often be cluttered with too much to fill out and boxes too small to complete. Now is the
time to look at integrating a one-click checkout process that will not only increase conversion, but also encourage
repeat business.

Customer feedback
Ultimately your customers will decide if the website is a success. This will be seen through the conversion rate,
traffic and average order value, but you should also monitor your customer service feedback and reviews, and
seek to constantly evolve the mobile site, based on the feedback, to ensure they are seeing what they want to see,
when and where they choose to view it.

Mobile Web Design and Development Best Practice Guide Page 129

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
6.2.2. Platform considerations
Technically, a mobile site is a different website to a desktop site and uses a separate code base.
However, it can still inherit and reuse some of the elements from the desktop site. This depends
on your business needs and the platform the desktop site is built on.

The business requirements could be different for each site. Using the Carpetright website as an
example, the desktop site is fully transactional and includes basket and checkout, whereas the
mobile website provides the catalogue browsing and ‘call to buy’ functionality. The mobile website
is also location aware (using geo-location to map where a mobile device is) and therefore includes
extra functionality such as store finder integration with phone navigation and contact phone
numbers with the phone dialpad. Creating a truly customised experience like this for a mobile
visitor is facilitated by a dedicated mobile site.

Some platforms require brands to create two instances to satisfy desktop and mobile needs, some
require the business to use a different platform altogether for the mobile website. In the case of an
ecommerce mobile website, this usually requires integrating the same product catalogue plus
customer and order details twice, as well as keeping the data between the platforms synchronised.
This presents additional challenges, such as synchronisation of sessions when a user switches
from a mobile to a desktop website. A non-transactional, content-only mobile website is simpler,
but still requires integration of content and imagery. This approach requires significant effort to
maintain, upgrade and operate the two websites.

Platforms like Magento allow businesses to create different store views within one installation.
This allows a business to create one store view for a desktop site and another one for a mobile site,
while sharing central architecture and data.

Each of these store views/websites can then be configured to have a completely different look and
feel, use different page layouts and have different functional elements embedded within. The
differences in mobile functionality can range from using simplified navigations, through removal
of elements from basket or checkout, to inclusion of mobile-only functionality such as a store
finder integrated with a phone’s GPS navigation or direct dialup functionality for contacts.

When both the desktop and mobile websites are based on the same platform, if required they can
both use the same product catalogue, customer and order details, as well as price and stock
information. The store views could also be configured to use different catalogues and create
mobile-only products or mobile-only pricing and promotions.

It follows that platforms with such inheritance capabilities vastly reduce not only the time and
effort to build a standalone mobile website, but also its operational management and
maintenance, along with further enhancements and updates.

6.2.3. Design considerations

To deliver the best possible user experience, a dedicated mobile site should have a dedicated
mobile design. There are two possible approaches:

1. Dedicated mobile site with the look and feel of a mobile application
With this option the user interfaces are made to appear and behave like a mobile application for
one of the three main mobile operating systems: Android, iOS or Windows Mobile. Each of these
systems treats the interfaces slightly differently and has their own distinct look and feel.

The designer uses the user interface library typical for the operating system selected as a baseline
for their designs. For example, if iOS is selected as a baseline, the buttons will be flat and opaque,
wheel selectors will be used instead of dropdowns and sliders will have the rounded ‘dots’ at the
ends. The Android version will have menus instead of wheels and Windows will have a tiled Metro

Mobile Web Design and Development Best Practice Guide Page 130

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
interface instead of buttons with spaces in between. The selection of which operating system to
build for usually depends on the analysis a brand has done to identify what system their target
audience is most likely to use and the, often subjective, preferences of the decision makers.

However, the ease of implementation should play its part in the decision-making process too. The
easiest one to implement would be Windows followed by Android and the most difficult would be
iOS. Windows uses a simple grid with the flat tiles ‘floating’ next to each other, which is relatively
easy to design, develop and test. Android’s icons and user controls and element grids are more
complex, which makes their resizing and repositioning on different screen sizes more difficult.
iOS interface elements and effects are very detailed (for example, the selector wheels or sliders),
which makes them even more difficult to develop and test on all devices.

The option of replicating the look and feel of a mobile application is far more difficult to design
and implement than a standard mobile website and therefore should only be selected if there is a
strong enough business case to justify it. This is because the user experience and design teams will
have to design the interfaces for all possible mobile and tablet screen sizes and orientations and
adapt the designs to look correct on all of these combinations. This is a massive challenge, which
will require a huge effort not only in design, but also during the development and testing phases.

An example might be a simple date picker for an online appointment or a delivery date. On a
typical mobile or responsive website it is likely to be displayed as a simple calendar, where the
user would select the date by clicking on the appropriate field; such a calendar is easy to design
and implement. However, if the mobile website is to exactly replicate the look and feel of an iOS
app (for example, iPhone 5), the wheel selector below would need to be used.

Figure 38: Different design options for calendars on mobile sites

Replicating the functionality and look and feel of this interface will be extremely difficult to
implement on a mobile website.

This is an extreme example, which is unlikely to be implemented in practice and a compromise

would usually be reached. For example, the iOS icons could be used on a mobile website
homepage and the sliding selectors used throughout the website, but instead of the scrolling
wheel, the date picker from the first example could be implemented. This is the approach
Carpetright has chosen.

2. Dedicated mobile site with the look and feel of a mobile website
With this approach the mobile website will have the look and feel of a website instead of a mobile
application. The website interfaces will still be different and simpler than the desktop site and
fully optimised for a mobile user experience, but are slightly less elaborate in their appearance.
The functionality will remain the same.

For this option it is best to use the principles of responsive design. Responsive design relies on
flexible and fluid grids that automatically adapt to any mobile device and screen size, instead of

Mobile Web Design and Development Best Practice Guide Page 131

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 being specifically designed and developed for each screen size individually as would be the case
with the first option.

This flexibility allows designers to create only a few different options for each page (for example,
for Galaxy S and iPhone 5 in portrait and landscape modes) and leave the rendering of the layout
in other phones on the fluidity of the code itself. This means that the designs will not be exactly
the same on mobile phones with different screen resolutions and, as a result, will require a certain
level of flexibility and open-mindedness from the decision makers approving the designs and the
final site build.

This approach enables the use of rapid prototyping tools that allow designers to create the initial
designs on the fly. This approach can speed up the design process as it bypasses the need to
design flat concepts using software such as Adobe Photoshop or Fireworks, which are then built
into HTML. There are quite a few of these tools available on the market today, with new ones
coming out almost weekly. A few examples are Jetstrap, Adobe Edge or Microsoft Expression.

These tools allow designers to ‘draw and colour-in’ the individual pages and then publish the
results as an HTML prototype. Decision makers can open the designs on their mobile devices and
visualise more effectively how the final pages will look and behave on different devices and screen
sizes.

This approach can save significant amounts of effort and money and also make the website far
easier to maintain.

6.2.4. Creating page templates

There are two options for creating page templates for a mobile website. The first is to duplicate
and amend the code from the desktop website and the second is to build new page templates from
scratch.

The first option might seem faster to implement but if the desktop website (and its code) is a few
years out of date or if the mobile website is to have entirely different functionality it’s
recommended to develop mobile-specific templates from scratch. Although writing new templates
will initially require more effort than adapting the existing desktop website code, there are
additional benefits with this.

Mobile website page layouts are usually much simpler than desktop layouts; therefore page
templates could be far simpler too. This includes the structure, styling and positioning as well as
functional scripts such as jQuery Mobile, HTML5 and CSS3 and. JQuery Mobile has been created
to be specifically lightweight and fast.

As a result, well-written mobile-specific code will reduce the file size of the page templates leading
to improved website performance. As site speed has an impact on conversion rates, having
lightweight page templates is a critical factor for a successful mobile site.

Additionally, a website created on these technologies will work well in all modern mobile
browsers and its maintenance and updates will require much less effort too. However, this
approach should only be considered if the platform already supports HTML5, CSS3 and jQuery
Mobile.

If the platform can only publish the same code to both desktop and mobile websites then in the
best-case scenario it will utilise HTML5 and CSS3, but not jQuery Mobile. In the worst-case
scenario, where the platform is outdated, it’s unlikely it would even support HTML5 and CSS3. In
this case the only viable option would be to build a mobile website independent of the main
platform, from scratch.

Mobile Web Design and Development Best Practice Guide Page 132

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
6.3. Technical challenges
6.3.1. Planning the development
Your approach to development depends on the route chosen: a standalone mobile website or a
mobile website running from the same platform as the desktop website.

1. A standalone mobile website

A standalone mobile website, which is independent of the main desktop website and the platform
it runs on, will require the duplication of all existing functionality. This has both advantages and
disadvantages.

Pros

The key advantage is that the functionality, as well as page templates, can be developed
specifically for mobile devices and, therefore, be made lightweight and built on the latest
technologies available. Also, as any code changes will not have impact on the code base of the
existing desktop website, it will require less careful planning and can be developed and deployed
much faster.

Cons

The biggest challenge is that all existing content, data and third party integration will have to be
recreated from scratch. For an ecommerce website this includes integration of the product
catalogue, customer and order details, and pricing and stock information. Payment gateway
integration and website tracking will also need to be re-integrated. Although it will usually be
possible to reuse some of the existing code, most of it will still have to be developed and tested
again on the new website.

The same applies to website functionality, which will have to be either partially or fully
redeveloped then tested, as with any new website build.

After the mobile website launch, all new functionality will have to be developed and released twice
and operational maintenance and code updates will require twice the effort too.

2. Mobile and desktop websites running on the same platform

A mobile website that runs from the same platform as the desktop website doesn’t need separate
data integration, can reuse most of the existing functionality, provides easier operational
management and lowers the maintenance and hosting costs. However, it requires a more
experienced development team and more careful development and release planning.

When planning a mobile-specific site, the team will need to decide how they will separate mobile-
specific functionality within the main code base. There should be as much code inherited from the
main code base as possible and only mobile-specific functionality separated into distinct modules.
This will not only make the development, testing and maintenance simpler, easier, faster and less
expensive, but also less risky because it will minimise the impact any bugs in the mobile-specific
functionality would have on the main website.

The development team will also need to adopt and adhere to a strict set of rules and coding
standards, which will reduce the risks associated with working on a common code base and also
help to eliminate any potentially risky ‘hacks’ to it.

During the initial development, as well as with any future updates, the implementation of the
functionality and the code should be regularly reviewed by an experienced software architect and,

Mobile Web Design and Development Best Practice Guide Page 133

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 where required, the source code should be regularly refactored; otherwise any future changes will
be difficult to do and maintain.

6.3.2. Mobile site development

When developing a mobile-specific website, there are best practices to be adhered to and common
pitfalls to be avoided.

Dos

 Develop a fluid architecture.

 Carefully prioritise content on a mobile page and only then start developing the templates.
 Only include the content that’s most relevant to a mobile user.
 Optimise all website assets such as imagery, CSS, HTML and JavaScript files.
 Use server compression while serving page content and assets.
 Cache as many assets and content as possible.
 Minimise HTTP requests.
 Use data URI to save HTTP requests.
 Be careful when selecting fonts (not all fonts are supported by all mobile devices).

Don’ts

 Use several JavaScript libraries; select one that suits your needs the best and use it
throughout.
 Think ‘clickable’, think ‘touchable’.
 Use fixed widths and heights; use em or percentage together with max-width instead.
 Open links in new windows.
 Use iframes and avoid HTML tables where possible.
 Create large forms; split them into smaller steps and keep input (form elements) minimal.
 Use the same device for development and testing.

6.4. Implementation challenges

6.4.1. Responsive vs. mobile-specific code base
The responsive approach utilises the same code base with the desktop site and, therefore, doesn’t
fully duplicate the development or maintenance effort. However, there is some extra effort
required in development and testing.

In development, any new functionality and layout elements added have to be optimised for the
fluid behaviour and in some cases extra functionality has to be added to the templates. This is
related mostly to user interfaces, where some of the elements and their behaviours have to be
amended in order to support touch instead of hover-and-click with a mouse.

A typical example of this would be navigation with a dropdown panel, where the top tab in a
desktop view on hover will open a dropdown with a submenu but on mobile devices the tab has to
be clicked to achieve that. Another example could be changing the layout of navigations from a
tab bar in a desktop view to a dropdown menu on mobile.

Mobile Web Design and Development Best Practice Guide Page 134

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 In other cases new functionality, available only to the mobile view, has to be added. An example of
this would be a contact phone number, which in a desktop view doesn’t have any specific
behaviour but in a mobile view can change to a clickable link, which will open a mobile phone’s
dialpad. Another example could be displaying information within a page instead of a popup, or
simplifying forms and other complex functionality, which would be difficult to operate on a
smaller touchscreen.

However, all of these are relatively simple changes, mostly achieved via CSS, HTML and
JavaScript alone and, therefore, constrained to within the page templates and the code behind
these, not a platform code as such.

All this is valid only when the code of the underlying desktop website supports the latest
technology standards and is not several years out of date. If it is, it would be very difficult, if not
impossible, to make it work equally well on desktop as well as on a mobile device, which generally
are built to much newer standards than those of desktop browsers.

In any case, there is an extra effort required in testing because in addition to the standard desktop
browsers, the responsive views have to be tested on several additional mobile browsers.

A mobile-specific website doesn’t share the page templates with a desktop website, therefore it
can be developed from scratch, specifically for mobile devices. Providing it is on a platform that
allows using technologies such as HTML5, CSS3 and jQuery Mobile, or is built on a separate
platform, developing mobile website templates is pretty straightforward.

6.4.2. Development frameworks

The development would be even simpler if the initial designs were not created and approved as
flat images, but as interactive HTML prototypes, created using the latest rapid prototyping tools
described in Section 6.2.3: Design considerations. Many of these will produce a valid HTML5 and
CSS3 code, which can then be adapted to the platform page templates. Some of these tools are
based on the latest development frameworks, such as the best known one, Twitter Bootstrap.
Bootstrap comes with most of the website elements already predefined and styled and all of it is
optimised for mobile devices. It includes all structural elements, forms and their validations,
navigational elements, image galleries and many others, which can then only be amended instead
of developed from scratch.

Even if the initial designs were created as image files without any prototyping tools, a
development framework should be implemented and used as a starting point for all front-end
template development. Its use will not only speed up the development, but also introduce far less
bugs and make the code easier to maintain and update when required.

There are a number of excellent frameworks available on the market. The best known CSS
frameworks are Bootstrap (by Twitter), LESS or Gumby and JavaScript frameworks jQuery
Mobile, Bootstrap and Sencha. Bootstrap combines both CSS and JavaScript (using jQuery
Mobile).

There also are many others. When choosing the right framework developers should take into
consideration their stability and maturity, how well they are adopted by development
communities and very importantly, how well documented they are.

Mobile Web Design and Development Best Practice Guide Page 135

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
6.4.3. Development challenges
As described previously, modern mobile devices are built to the latest development standards
and, therefore, require a valid and up-to-date code to render the website correctly. To develop a
mobile website from a legacy code that’s five years out of date is impossible. In this section we will
assume that the underlying code will be HTML5, CSS and jQuery Mobile and discuss the
challenges associated with mobile websites in general, not mobile websites attempted to be built
on an outdated code.

The challenges can be divided into three areas. The first two are dependent on the platform used;
the third is common to both approaches.

A standalone mobile website

 The content and, in case of an ecommerce mobile website also the product catalogue,
customers and orders, pricing and stock information, will need to be integrated either with
the retailer’s CMS or ERP systems, or the main desktop platform.
 The logged-in user sessions, which will allow a user to switch between the mobile and desktop
website, will need to be synchronised via a common session pool or a single sign-on system.
 Any website updates and new functionality added will have to be developed, tested and
released twice.

Mobile and desktop websites running on the same platform

 The platform will need to support common libraries for both the desktop and mobile websites
(e.g. JavaScript libraries).
 The platform will also need to support latest technologies such as HTML5, CSS3 and jQuery
Mobile for both websites, or at least allow the use of different technologies for each website.
 As the websites will be running from the same base code, every new functionality developed
for either website will need to be compatible with the other.
 When designing any new functionality, the code inheritance will have to be taken into
consideration.
 Since changes can impact both websites, more testing effort will be required.

Common challenges

 A mobile detection and switching layer will need to be managed and maintained, including
the mobile device recognition library.
 As the mobile website performance is even more important than the desktop, all new code will
have to be reviewed and optimised for best performance to ensure a fast mobile site.
 In order to avoid the extra effort in creating and maintaining a library of two separate image
sizes (one for desktop, one for mobile), an automated image resizing mechanism will have to
be deployed and maintained.
 All new functionality will have to be tested on a large number of mobile devices. It will be best
to purchase these, because the online simulators do not work reliably.
 All assets, including imagery, HTML code, CSS and JavaScript files, should be optimised for
file size, merged together where possible and then compressed before being delivered to the
browser.
 All new code should be carefully optimised for performance and all page assets checked and
optimised for minimum file size.
 Reliable server and local caching mechanism should be implemented and managed.

Mobile Web Design and Development Best Practice Guide Page 136

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
  When designing a new mobile website or extending its existing functionality, caching
mechanisms and their potential impact on website functionality should be taken into
consideration.

6.4.4. Code maintenance

Whatever approach is selected, there will be a new project (“mobile website”) created in the
development environment. With the standalone website it would include all code, while with the
website integrated with the main platform it would include only the code specific to the mobile
website, without any of the common files.

Once this project and the associated files are created, they will not require any different effort,
skills or approach than the main platform. However, in the first case, where there will be two full
projects created, they will require twice as much maintenance and development effort.

Code validity

There are several steps that developers should take to validate the code.

The first step is the code compilation, where all new code produced, regardless of the technology
used, should be compiled. A successful compilation will verify that the code works and doesn’t
break anything else.

The second step is validation against the W3C standards. Any HTML, CSS and JavaScript code
should be validated using those standards and any issues or hacks found during the validation
test should be either fixed, or if that’s not possible (for example third party tracking code is
usually not valid and can’t be fixed) the developers should make sure that the website will work
correctly on all devices even with the issues left in.

The third step is website validation on one device. Once the functionality is completed, it should
be verified on the mobile device most commonly used by the website audience. This will identify
any major issues, which will most likely be replicable on all other devices.

If the functionality passes this test, the developers should validate it again on all other devices
agreed to be supported. Only once they all pass their test should it be passed to the quality
control team.

Code performance

Because of the mobile bandwidth limitations, the speed of a mobile website is even more
important than that of a desktop website. The speed is linked to the server infrastructure,
application response time and code file sizes. Assuming the website is hosted on an enterprise-
level infrastructure, the two areas the developers have to focus on are the application performance
and file size.

Application performance

For mobile pages to be downloaded quickly to a mobile device, they first need to be quickly
generated on the server. Therefore, the application optimisation should be the first step, where
the developers would identify any bottlenecks in the code itself and remove them. The goal should
be a maximum of 0.5 seconds for the page to be generated by a server and sent to a user’s mobile
browser.

The next step should be to implement a caching mechanism, starting with the server-side caching
and a reliable content delivery network. Once they are both fine-tuned to perfection, a local
storage cache, which will store the pages locally on mobile devices and tablets, should be
introduced.

Mobile Web Design and Development Best Practice Guide Page 137

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 Please note that although caching massively improves the website performance, it also brings new
challenges to the code deployment and a new release process for the live site will need to be
introduced. Without it, and a reliable mechanism for clearing all levels of caching, the changes
will be seen with a delay. In case of a local cache, they might not be seen by users at all unless they
clear their local cache manually (which they are unlikely to do), or unless the deployed changes
also force the refresh of a local cache.

You can test your mobile site speed using free tools like www.summit.co.uk/performance-
checker.

File size

Asset size is another important factor in website performance and page rendering. Therefore all
imagery, CSS, JavaScript and HTML files should be optimised, merged together where possible
and finally compressed before the server sends these to the mobile user browser.

All major web servers (such as Apache, Nginx, IIS server or IBM WebSphere) support page
compression. Using gzip compression can save up to 70% of file size and, therefore, also the
bandwidth required to download a page. As a rule of thumb, the total size of any mobile page
should not exceed 300kB, including all assets.

When designing any new functionality its impact on website speed should be taken into
consideration. When the functionality is then developed, the application performance and asset
file sizes should be re-tested before any new code is released to the production environment. All
this should be enforced by process, impacting the existing design, development, testing and
release procedures.

6.5. Summary – key pros and cons

6.5.1. Key pros
Customised for mobile

For complete customisation of the mobile user experience, hosting content on a subdomain or
subdirectory with mobile-specific templates, CSS and content is an option to think about.

This is by far the most customised way to deliver your message to visitors based on how they are
viewing your content (on a smartphone, tablet or desktop) and allows full search optimisation of
the mobile site (with mobile-specific keywords associated with location and device).

As long as desktop versions and the mobile site are cross-linked and mobile pages are listed in the
XML sitemap sent to Google, the mobile site will be crawled and indexed with the SEO value of
the desktop site shared with the mobile site.

Speed of deployment

Quicker, due to the fact that a mobile-specific webpage will be created to be lighter in size and less
complex than a desktop or responsive webpage. This can provide a better bespoke tailored
experience for mobile.

Short-term fix

Consider a mobile site as a potential quick fix; a way to turn the lights on for mobile users who are
having a bad experience with your desktop site. It is a potential bolt-on to your non-commerce
simple desktop website as a short-term measure.

Mobile Web Design and Development Best Practice Guide Page 138

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 Can be a highly cost-effective solution

For the reason that you are not really touching your desktop site and taking key principles to
provide a stripped back and/or easily used mobile experience and due to the number of relatively
low-cost CMS vendor options out there, the choice to go for a mobile site can lead to upfront cost
savings.

6.5.2. Key cons

Multiple domain names fragments the user experience

Multiple domains for desktop (www.domain.com) and mobile versions (www.m.domain.com or

mobile.domain.com) can cause user journey problems with social sharing and inbound email
traffic. For example, when a user shares a link to a page on the mobile site via social media, and
their followers check the link on their desktop, they see a page designed for a 4-inch screen
displayed on a 24-inch monitor.

The x2 CMS problem – time is money

Even though the choice to develop a mobile only site to complement your desktop site may have
been driven by a desire to save money, the potential need to maintain two content management
systems will be more resource inefficient post launch, so if you have a website with many pages,
that changes often, this option is not going to be for you.

Mobile-specific sites use separate code base, which increases maintenance costs. Content must be
updated in both the desktop (www.domain.com) and mobile versions (www.m.domain.com or
www.domain.com/mobile-site) as separate CMS incidents control the hosting of the different
versions of content.

SEO problems

Redirects negatively affect SEO. Even with a canonical link tag you may be punished by Google, as
they have stated that they prefer a single URL for your web content (please refer to Section 8:
Technical SEO for Mobile Development for SEO-specific advice). You need to correctly compress
and cache content properly so that spiders can crawl your mobile site quickly and easily.

Redirects cost in load time

With 3G latencies, you’re looking at up to two seconds for the redirect to an m-dot to complete.
The visitor to your mobile site will count this against you, which negatively affects their
impressions of your site and reduces the likelihood of a repeat visit.

6.6. Mobile-specific site development checklist

Choose a mobile-specific site if:

 You want a customised mobile experience for visitors with quick loading.
 You want a mobile ‘band aid’ (short-term solution, relatively quick to deploy live, and
relatively low upfront cost).
 You don’t have a site that requires frequent updates and lots of pages.
 You have the resource and maintenance budget to support and update multiple content
management systems.
 You don’t mind having multiple domains.
 You can compromise on having the best SEO and social sharing experience for visitors.

Mobile Web Design and Development Best Practice Guide Page 139

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
6.7. Example sites
There are lots of wonderfully quick, simple to use and visually appealing mobile sites out there. To
follow are examples from the New York Times, Marks & Spencer, Harrods and Ralph Lauren.

6.7.1. New York Times

Unlike the majority of publishers who have pursued the RWD option, New York Times chose a
mobile site as the best solution to deliver news and ad formats tailored for mobile. As you can see
the aim is to present a few key navigation options and focus on the news content. Ads appear in
the letterbox gap above the news and under the navigation.

Figure 39: New York Times mobile site

Mobile Web Design and Development Best Practice Guide Page 140

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
6.7.2. Marks & Spencer
M&S recently launched a new mobile site and it’s a joy to use; very quick with nice navigation and
layout. As a retail experience on mobile it is leading the pack. Commerce functionality is great –
you can buy products, view colours, read reviews, search for stores and see the latest offers.

Figure 40: New M&S mobile website

Mobile Web Design and Development Best Practice Guide Page 141

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
6.7.3. Harrods
Prior to the M&S launch, Harrods had one of the UK retail benchmark mobile sites at
mobile.harrods.com, delivering a super quick, simple to use, visually appealing experience.

The homepage does not require any scrolling on iPhone 5 and features a simple auto-scrolling or
user-controlled carousel, and a top navigation featuring search, favourites and shopping cart.
Email sign-up and social links are placed at the bottom of the screen.

Figure 41: Harrods mobile website

Mobile Web Design and Development Best Practice Guide Page 142

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
6.7.4. Ralph Lauren
Another high quality luxury brand mobile experience can be had at m.ralphlauren.co.uk.

Again, the homepage features stripped back navigation, search, shopping cart and a carousel.
However, legibility of copy on the carousel images is sometimes sacrificed as the same design as
the desktop is being used on mobile. Thank goodness for retina screens!

In this example there are some nice features such as click-to-call functionality and the ability to
view the full site.

Figure 42: Ralph Lauren mobile website

Mobile Web Design and Development Best Practice Guide Page 143

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
7. UX/UI Design
Contributor
This section was written by Justin Taylor, MD at Graphitas (@JustinGraphitas).

UX/UI design is arguably one of the most important aspects of building a mobile-optimised
website; it creates a seamless connection between a mobile device and the products and services
of a business.

Users frequently judge the quality or capabilities of a company based on their first interaction
with their website.

In this section we outline best practices and help steer you clear of the many pitfalls of mobile
UX/UI design.

Mobile has changed how we interact with devices

“We interact with mobile devices in a way that just isn’t possible on other platforms. We touch, we hold, we
swipe, we capture. Consequently we have come to expect that even the most complex tasks can be completed
with just a few taps or swipes.

“The problem is, the easier something is to execute, the less tolerant and more impatient we become when our
expectations are not met.”

Justin Taylor, Founder & MD, Graphitas

7.1. Importance of UX/UI skills for mobile

Capturing a consumer’s attention greatly increases the chances of conversion, so it stands to
reason that once you have a user engaged further gains can be made if the on-site experience
matches, or better still, exceeds expectations.

With the exception of brand familiarity and reputation, the user experience and the journey
through a website is one of the most important factors in a user’s decision-making process. A
consumer’s perception of trust, reputation, size and reliability can all be garnished and the views
we have about a company can be positively or negatively coloured from what we see in front of us
and how we interact with it.

On a website, we don’t have the benefit of physical human interaction to influence the user, so
we’re reliant on design techniques to communicate implicit and explicit messages and create
positive impressions. You could have the most amazing product in the world that will make
people leap with joy but if it’s not clearly communicated, or easy to access on your mobile site,
then that joy is lost in translation.

The burden of responsibility lies predominantly on the shoulders of designers and UXers. For a
site to reach its full potential it needs to look great and particularly in the case of mobile, it needs
to be a functional and slick experience for the user.

Mobile Web Design and Development Best Practice Guide Page 144

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Mobile has changed how we interact with devices
“It may seem like a contradiction considering the ever-increasing size of today’s smartphones but the screen on a
mobile phone is a relatively small space given the increasing possibilities that phones offer, and the potentially
complex interactions they are demanding.

“To this end it is more important than ever to do a detailed task analysis; this enables you to understand what
one thing the website should do if it does nothing else. This should then form the core focus of the user
experience. It is key to not let the call to action fall below the fold.

“Think about the physical context within which the application will be used. For example, when designing a train
time application think about the user’s circumstances; invariably they will be either running late for a train just
when they want to use it, or stood in a crowded carriage on a train moving through varying coverage trying to
quickly get information on a connection to be made.

“It is better to think in terms of tasks as a series of layers, rather than a task being distributed across in a single
screen layer, the most important action being placed on the top layer and the secondary information placed
lower in the architecture so as not to distract from the core task.

“For a mobile device ‘the content is the interface’. Users are not interested in elaborate menu mechanisms, smart
buttons or innovative gestures.

“The use of gestures can free up screen space for content. The zoom gesture has almost become a part of our
cultural language for interaction, to the point that children now try to use the same interaction in books. It is
therefore important that these languages are respected and only broken with the upmost care and attention.

“Think outside of the screen. How could you use the various input and outputs of a smartphone to improve
interaction? Could you employ the camera, the microphone and the other sensors within the phone to speed up
content input and provide shortcuts to tasks? You can even use the portrait to landscape as a shortcut tool.

“Every smartphone has a very broad user base and it would be difficult to be specific about user types. However,
you can try to build some scalability into your design to allow novices to easily get to grips with the level of
functionality they need, while also letting other people ‘grow’ and become expert users.”

Paul Moore, Service Design Lead, Fjord (part of Accenture Interactive)

Mobile Web Design and Development Best Practice Guide Page 145

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 Figure 43: Audi – a great example of a cool UX/UI

UX and UI – what’s the difference?

According to Web Designer Depot 65:

“UI is the saddle, the stirrups, and the reigns. UX is the feeling you get being able to ride the horse,
and rope your cattle.”

In simple terms UI is how the site looks and how it communicates with users. UX is the emotion stimulated and
the experience of using the site.

The risks of getting it wrong

Getting the UX/UI wrong can be catastrophic for a website, resulting in poor user engagement,
low sales and frustrated users, the consequences of which can be harmful to any business.

65 http://www.webdesignerdepot.com/2012/06/ui-vs-ux-whats-the-difference/

Mobile Web Design and Development Best Practice Guide Page 146

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
7.2. Touch screen considerations
The manner in which users interact with touch devices is different to non-touch digital platforms.
Swiping, pinching and double-tapping allow the user to communicate with a website in a way that
quite simply hasn’t been possible before. As a result, designers need to take into consideration a
number of factors to ensure their site connects with its users.

Figure 44: Swipe, pinch, double-tap…. it’s all the rage

Source: House of Fraser – www.houseoffraser.co.uk

Screen real estate

The fundamental difference in designing for touch screen is screen real estate. Particularly in the
case of mobile, a designer working on a touch screen should establish the objectives of the site
and ensure these are clear and instantly obvious.

Mobile Web Design and Development Best Practice Guide Page 147

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 Figure 45: Designing for screen size

Source: WWF – www.worldwildlife.org

7.2.1. How does screen size influence design?

The screen real estate available on desktop, tablet, phablet and mobile can be a challenging
problem for designers to overcome. The presence of an existing desktop site, technology, target
audience and budget all play a significant role in determining the best route forward with your
project.

Common mobile design strategies

 Adapt the desktop

Where an existing desktop site is in existence, an approach often used is to adapt it to work on
mobile devices.

 Mobile first
The mobile first strategy is a technique that has grown in popularity over the last few years.
The approach is well suited to responsive websites where the mobile and desktop sites share
the same content. As the name suggests, with mobile first the mobile version of the website is
designed and this site layout is then adjusted to work on tablet and desktop.

 Mobile-specific
The mobile-specific approach focuses purely on the mobile version of the site. This technique
largely ignores the layout of the corresponding desktop site and instead focuses on utilising
the available screen real estate of mobile devices. The mobile-specific technique is typically
used for adaptive site design and is not suitable for responsive site design.

Mobile Web Design and Development Best Practice Guide Page 148

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Target areas (hit areas)

One of the biggest challenges designers have to overcome when designing for touch screen is
making it finger (and thumb) friendly.

A key ingredient to successful touch screen design is allowing for the minimum target areas (hit
areas) within the design. Doing so allows the user to browse and navigate the site with intuitive
ease, without the need to zoom and avoid missing clicks.

Fingers and thumbs are inherently low precision input mechanisms, so it is wise to ensure site
design caters for this finger-sized issue.

Figure 46: Designing for fingers and thumbs

Touch gestures

A great technique for overcoming the design limitations on touch screen is the use of touch
gestures, in particular the swipe.

Facebook is a good example and has used gestures to its advantage on mobile devices. Photo
albums, recommended pages and app suggestions can all be viewed on the timeline via the use of
the left to right swipe.

Mobile Web Design and Development Best Practice Guide Page 149

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Figure 47: Expanding the mobile canvas with a swipe

The Facebook Paper app has taken the concept of touch design a step further, with clever use of
an interactive, content-aware canvas where the display adapts to user choices and ensures none of
the limited real estate on the smartphone screen is wasted.

Fortunately for mobile designers, the majority of gestures are supported across all common
smartphones and tablet devices.

The designer should take advantage of core gestures such as swipe, pinch and double tap
wherever possible as these are elements of the touch interface that feel completely natural to
users.

When implementing touch gestures the safest method is to use only the core gestures, as these
work across all common mobile operating systems.

For a definitive list of touch gestures and device compatibility download the Touch Gesture
Reference Cards by Craig Villamor, Dan Willis, and Luke Wroblewski66.

66 http://static.lukew.com/TouchGestureCards.pdf

Mobile Web Design and Development Best Practice Guide Page 150

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Figure 48: Core touch gestures

Rollovers and hover states

The mainstays of any self-respecting desktop website – rollover and hover states – are not a
welcome addition on mobile. The nature of the touch interface means there is no need and
therefore no ability for the rollover and hover.

Some sites replace rollover and hover states with tap actions; a user is required to single tap to
view what lies within the hidden state. However, this solution offers an extremely poor user
experience and should really be avoided.

To find the most user-friendly solution to the rollover and hover issue, you must first understand
the reason it was implemented on the desktop site and then determine the most appropriate
action to replace it with.

For example, if the rollover on the desktop site has been used to reveal detailed site navigation,
this is unlikely to be user friendly on a mobile site; therefore, consider replacing the cumbersome
navigation with a category landing page containing these key elements.

Although there are workarounds to the rollover and hover issues, best practice (if scope allows) is
to remove them totally and implement a solution which is best suited to a mobile platform.

See Section 7.4: Key design techniques for mobile sites for more information.

Remember, touch screen is not desktop

A common mistake when designing for touch screen is to take the same approach as designing for
desktop. This approach will never deliver the best results. To build truly engaging touch websites
the designer needs to embrace the technology, not adapt it, especially as touch offers many unique
opportunities to engage and interact with the user. The unique features of the touch interface
form the foundations of great touch websites and, as such, cannot be effectively added on after a
site has been designed and built.

Mobile Web Design and Development Best Practice Guide Page 151

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 Context

Context is arguably the most important aspect of touch and mobile site design. The portability of
mobile devices now means we are accessing the internet in every situation imaginable and this
creates some interesting challenges and scenarios.

A key factor in successful mobile design is understanding the context and situation in which a
user is likely to be accessing your site.

What are the key design differences in touch screen?

“An obvious starting point is the human finger and its various shapes and sizes. There are ergonomic guidelines
for button size, however, in practice these are quite restrictive and work on an assumption that a UI will try and
squeeze as many buttons onto a screen as possible. However, with good information architecture and a focused
task analysis these considerations become less important. The imprecise nature of mobile interaction, due to the
external context (walking, train travel, car passenger etc.), means that targeting can be difficult at the best of
times. Consideration needs to be made as to where action items are placed; will the user’s hands obscure or
inadvertently touch other parts of the screen as they reach for the desired button?

“Jakob Nielsen coined the phrase ‘read-tap asymmetry’, whereby the font may be legible in size but the touch
areas are so small that users are prone to missing the targets or are unsure whether the area is actionable or not.
Thumb use among mobile users is popular. Some users won’t always have two hands free when they are using
the phone and may prefer the convenience of using only their thumb. For key tasks users shouldn’t have to
switch from using one hand to two hands or from their thumb to their index finger to hit a target accurately.

“One of the most engaging features of touch interaction is direct manipulation. It is one of the key factors in the
success of the iPad. You feel like you are interacting directly with the content as it responds immediately to your
touch or gesture. Always try to use direct manipulation when dealing with content as it makes for a richer
experience.

“Multi-finger gestures can be useful shortcuts but they should be used in moderation and it is good practice to
enable features in other ways than just the gesture.”

Paul Moore, Service Design Lead, Fjord (part of Accenture Interactive)

7.2.2. Screwfix – an example of understanding user context

Screwfix is a UK-based supplier of trade tools and building products. In addition to their
comprehensive online offering, they also have a network of bricks-and-mortar stores throughout
the UK.

Screwfix understands that the majority of their customers will be building professionals and keen
DIY-ers. This often means that users of their site need products immediately, as without them
they may not be able to complete the job or project they are working on.

It is a fair assumption that a large proportion of their site users will be accessing their site from
building sites, gardens and remote locations and, therefore, users will often be using smartphones
over potentially slow connection speeds.

These same users will often want to quickly establish if Screwfix has the product they require and
find out the nearest branch with stock. The user context of this scenario is that they will most
likely be on a smartphone, on a potentially slow connection, in a remote location. Additionally,
the purchase could have an amount of urgency attached to it as it may be stalling progress of the
building project.

Fortunately Screwfix has designed and built the site to take user context into consideration.

Mobile Web Design and Development Best Practice Guide Page 152

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Site speed

Even on slow connections, the Screwfix site loads quickly. This has been achieved by removing the
majority of homepage images and by using CSS to create styling and button elements.

UI

The homepage design and layout is focused around users finding products quickly and easily. The
uncluttered design allows for clear target areas for buttons, a prominently positioned search bar
and clear navigation with logically organised categories.

Location services

When accessing the site from a mobile device, the site asks to use location services to establish
current location. Once the site has this information it quickly and easily allows you to search for
the nearest branch and will even show product stock levels in branches near to your geographic
location.

Click and collect/next day delivery

As well as showing local stock levels of products, the site also has a Click and Collect facility to
allow users to reserve the goods at the store for collection. Alternatively Screwfix also has a next
day delivery option for purchases with less urgency.

Store opening times

The Screwfix site shows store opening times, addresses and telephone numbers as well (these can
also be accessed based on location).

With their mobile site, Screwfix has demonstrated a clear understanding of user context and the
situations and circumstances in which customers are using their site. This information has been
used to create a mobile experience that embraces these problems and as a result the customer
journey and user experience is enhanced.

Figure 49: Designing for user context

Source: Screwfix – www.screwfix.com

Mobile Web Design and Development Best Practice Guide Page 153

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
7.3. Device-specific considerations
There are device-specific requirements that designers and developers have to consider when
designing for mobile. The vast majority of these deliberations fall into the category of screen size
and operating system.

Using platform guidelines

“The first rule when designing for a specific platform, be it Android, iPhone, Windows Phone or Tizen, is to
download the style guide. This is an invaluable source of information and a shortcut to a good UI solution.

“The Android guidelines tend to allow for more flexibility in design, so if you want to promote a brand then an
Android version will generally look more individual compared to other applications. On the iPhone there is a
tendency for the applications to be more representative of Apple.

“Android is also more flexible when it comes to hardware; this means having to make design considerations for
multiple screen sizes, shapes and resolutions. In recent times this has also included different button
configurations.”

Paul Moore, Service Design Lead, Fjord (part of Accenture Interactive)

7.3.1. Screen size

The variations of screen size and format is a headache for the touch designer as smartphones,
phablets and tablets all differ significantly in resolutions and screen real estate.

To overcome the issues, there are tried and tested techniques which can be employed.

Responsive design

Using responsive or fluid design templates allows the layout to automatically respond and reflow
to fit the available screen width of the device. With the number of devices and platforms growing
on a daily basis, this approach is considered by many to be the best method of future proofing
websites.

Responsive web design 101:

1. Cut the clutter

There are few things more irritating to users than an overcomplicated layout full of non-
essential information. Trim your content, users will thank you for it!

2. Be aware of breakpoints
Breakpoints are used to define common resolutions at which a responsive site should be
designed. The following will allow you to target smartphones through to desktops:

– <480px – standard (first generation) smartphones in portrait mode

– <768px – high-end smartphones and tablets
– >768px – large tablets and desktop

3. Media queries
Create specific CSS styles to target the breakpoint resolutions and combine this with media
queries to load the correct stylesheet, depending on the device accessing the site.

Mobile Web Design and Development Best Practice Guide Page 154

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 example media query = @media screen and (max-width:480px);
css style =

4. Images don’t support media queries (yet)

It is not possible to manipulate the ‘src’ attribute of an image through media queries (as yet).
A useful workaround to this problem is to specify the image as a background image. You can
then change the background image using CSS as part of a media query.

5. Flexible grids and fluid layouts

When designing responsive templates flexible grids and fluid layouts can offer huge
advantages. Fluid website layouts use percentage widths instead of fixed widths, which allows
the layout to adjust to the user’s screen resolution. A major advantage of this approach is that
the layout will remain constant on all devices.

How easy is it to flip a non-responsive template into a responsive one?

This question is really difficult to answer as it depends on so many variants, predominately how
complex the original site is. The answer isn’t always straightforward. The main issue that
designers and developers encounter is with legacy or closed platforms that simply do not allow for
responsive code to be implemented.

Viewport

To overcome variations in screen size, using the viewport meta tag tells the browser to scale a
website to fit the available screen width.

Useful viewport examples

 Width and screen width

Devices will often automatically render sites at 980px wide. However, on mobile this is usually
not the desired width.

To overcome this issue, specify the ‘width’ element in the viewport meta tag. In the example of a
mobile site that is designed and built to be 320px wide, specify the viewport width to be 320px so
the browser knows to render it at this size:

<meta name="viewport" content="width=320">

Be aware that using the tag in this manner will render the site at 320px wide in both portrait and
landscape orientations.

To render the page to the width of the device’s screen, specify the viewport width to be ‘device-
width’. Responsive layouts should specify this attribute as it allows the site to render at an optimal
size for the device.

<meta name="viewport" content="width=device-width">

 Disabling zoom
Disabling the user’s ability to zoom the site can be defined in the viewport tag by implementing
the following code:

<meta name="viewport" content="user-scalable=no" />

Mobile Web Design and Development Best Practice Guide Page 155

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 Initial scale
Mobile browsers will often attempt to scale websites. The ‘initial-scale’ parameter sets the zoom
level of a page on load. Responsive sites should work without this parameter, but it can be a useful
fix for certain browsers when changing the orientation mode.

In the majority of instances this will be set to 1, which is equal to 100% (any zoom level can be
applied by using decimal percentages: e.g. 1.5=150%, 2=200% etc.).

<meta name="viewport" content="initial-scale=1">

Page fold

Although page fold is largely irrelevant to mobile users, designers should take care to ensure key
calls to action and user triggers feature within the viewable area on this initial page load. Beware
of differences in screen dimensions (e.g. the screen height difference between iPhone 4 and
iPhone 5).

As you can see from the example below, the ‘Buy it now’ call to action is viewable on initial load
for iPhone5 users. On iPhone4 the button falls below the page fold meaning that users will need to
scroll to view it.

Adjusting the site layout and ensuring the call to action is viewable on all devices is a must. Along
with the obvious usability benefits this will also quite often deliver significant upturns in
conversions.

Figure 50: Page fold is still important for mobile designers

Serve desktop site on tablet

Don’t be afraid to serve desktop layouts to tablet devices, just make sure that you address any
issues with touch interfaces such as hovers and rollovers.

In almost all situations creating a tablet optimised version of a website is going to be the utopian
solution. In the real world, however, timescales and budgets will often mean that the benefits of
creating a tablet-specific version are outweighed by the time and cost.

Mobile Web Design and Development Best Practice Guide Page 156

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 Although serving the desktop site instead of creating a tablet-specific version is more efficient
from a development perspective, this is definitely not the case for testing.

Testing a desktop site on a tablet should be an extensive exercise, in exactly the same way as
testing a tablet-specific version should be. Don’t be drawn into the false sense of security that if it
works on desktop it will automatically work seamlessly on tablet, as this is rarely the case.

Extensively test everything! Rollovers, hovers, form inputs, images scaling, animations, sliders,
purchase processes etc.

If you discover tablet-based issues during testing, these can be fixed by using media queries to call
CSS which is specific to the tablet device.

Figure 51: BBC – desktop site served to tablet devices

Source: BBC homepage – www.bbc.co.uk

7.3.2. Operating system (OS)

Essentially the majority of users visiting your site from a touch-based web browser will find the
rendering and touch interaction is executed in a similar manner across all devices. This is
certainly true for iOS and later versions of Android which typically represent well over 95% of
mobile website traffic.

Often you will find small idiosyncrasies across various OS versions and flavours and the only sure
fire way of identifying these problems is to test the site on numerous devices.

For the most part, the majority of layout and page rendering functions work extremely well across
all mobile devices and on the whole, HTML5 implementation is extremely comprehensive.

However, where things get more complex and less reliable is in using some of the more advanced
features of HTML5. Audio and video are among the more troublesome areas of HTML5
implementation across mobile devices: a good example being that iOS opens video in a separate
window using the QuickTime player, whereas Android will play video on the page.

Mobile Web Design and Development Best Practice Guide Page 157

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 Developers using advanced HTML5 features such as audio and video will also need to be aware of
the issues caused by Android fragmentation. A large number of currently active Android devices
are not compatible with latest versions of the OS and therefore the latest browser versions and
HTML5 implementations are not available to some devices.

The best advice for any designers and developers using the more advanced HTML5 features is to
make sure you are undertaking a good level of device testing.

Good to know…

 Opera Mobile Classic Emulator – http://www.opera.com/developer/mobile-emulator

This emulator will allow testing of a mobile website on hundreds of mobile devices directly from
your desktop. It uses Opera’s web browser, but is a great tool for basic testing.

 HTML5Test – http://html5test.com/compare/browser/index.html
To find which HTML5 items are supported by which browser HTML5Test is a great resource,
allowing you to compare the support for up to five different mobile browsers at a time.

7.4. Key design techniques for mobile sites

7.4.1. Define your site
It’s a good idea when starting on a mobile design project to define the objectives of the site and
compile a cohesive list. Document all the features required, providing a checklist that can be
referred to throughout the project to keep it lean and on track.

As previously mentioned, a common pitfall of mobile site design is the temptation to include
features that offer little to the user experience and it is therefore imperative when designing a
mobile site that you are guided by the needs of users in order to achieve the desired outcome.

For example, when designing a mobile site for a hotel, it is a fair assumption that users of the site
will be interested in booking a room, an objective also shared by the hotel owner.

Therefore the designer has a clear route forward: the primary focus of the site is conversion and it
therefore makes sense to deliver the tools and information the user requires to achieve this. In
this scenario such tools are likely to be an availability checker, room rates, photos and location.
Other items that may be included within the desktop version of the site – such as menus, local
attractions, meet the staff etc. – are not as important to the mobile user.

Successful designing for mobile is about cutting the clutter, giving users clear information and
clarity of relevant content through a simple and concise user interface.

Determining which features are essential, which should be discarded and which fall somewhere in
between, can be achieved using prioritisation techniques such as MoSCoW. These can be
extremely useful methods for allowing teams to determine both essential and nice-to-have
features.

A few tips on creating a coherent site definition…

 Create a feature list

Start the process by putting together a list of the features you would like to include within the site,
with an explanation of the benefit to the user.

For an example feature list, see the case study in Section 7.8.2: Defining the site.

Mobile Web Design and Development Best Practice Guide Page 158

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
  Definite site objectives
The next step would be to define the site objectives in as few words as possible. In the example of
the hotel site the objectives would be something like “Generate additional revenue by allowing
users to book hotel rooms from their mobile device”.

 Understand your audience

There are a number of methods used to target and understand audiences. Some of these could
involve looking through historical data, social following, personas, gut feeling, feedback etc.
Essentially, whichever process you use, you need to end up with an indication of the type of
person you are marketing to.

Mike King from iAcquire has a great slide deck on building personas which is packed full of useful
tips and examples67.

 Trim it
Once you have your list of features, site objectives and an understanding of your target audience,
revisit your original feature list and review each item on it. If a feature is not essential to the site
objectives, set it aside and don’t include it within the site landing page.

Note: Removing a feature doesn’t necessarily mean it should be removed from the site, it just
means not including it on the landing page. If a feature is important but not essential, consider
making it accessible via site navigation or alongside relevant content.

 Context
Lastly and most importantly, consider the context in which users are accessing your site. In the
case of the hotel, users could be planning a romantic getaway from the comfort of their sofa, but
equally they could be accessing the site from a street corner on a slow connection after their train
has been cancelled. Particularly with mobile you need to be very careful not to alienate users on
slow or patchy connections.

7.4.2. Wireframing
The need to wireframe and A/B test mobile site designs is an invaluable and often overlooked
aspect of the design process. Prototyping a concept without the overhead of creating design
visuals not only gives the ability to gauge user reaction, test functionality and highlight usability
issues, but it can also reap huge rewards in time and cost savings.

A wireframe offers the unique opportunity to focus on the bare bones of a user interface without
the distraction of graphics, animations and imagery, so you can gain a clear understanding of
what is on each page, where it goes and why, thus achieving the correct layout and structure for
all pages.

For a more in-depth look at where creating wireframes fits into the design process, see the case
study in Section 7.8.5: Wireframing and site concepts.

7.4.3. Advanced techniques

Webfonts

Webfonts form the cornerstone of any self-respecting mobile design project, giving you the ability
to integrate beautiful and elegant fonts without the overhead of creating slow to load JPEG
graphics. This offers huge benefits for site speed, responsive design, cross-platform compatibility
etc.

67 http://www.slideshare.net/ipullrank/pub-con-personas-for-seo-2012

Mobile Web Design and Development Best Practice Guide Page 159

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Site speed

If your site doesn’t use webfonts then the likelihood is that images will be used for headers,
headlines and graphically rich assets. This approach means that the overhead of using graphics
instead of fonts will slow down page load (due to size of graphics and number of server requests)
which creates a poor experience for users.

Scalable

When targeting multiple screen sizes and multiple devices, it is inevitable that assets will need to
be scaled to fit the desired screen sizes. Webfonts can be scaled up or down in size without any
loss of quality. Pixel-based images on the other hand will deteriorate in appearance when resized.

CSS effects

Webfonts can be fully controlled with CSS. So changing size, colour and adding effects such as
drop shadows and gradients can be applied by updating the CSS file and without the need to
recreate the graphic within Photoshop.

SEO

Webfonts are SEO friendly, so all text contained within them can be crawled by search engines.
With images however, search engines can only crawl the ‘alt’ text attribute.

In short if you are not using webfonts in your mobile design projects, start now!

Figure 52: Putting webfonts to good use

Source: Jack Daniels – www.jackdaniels.com

Mobile Web Design and Development Best Practice Guide Page 160

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 SVG (scalable vector graphic)

The lightweight SVG file format offers huge speed advantages over traditional bitmap equivalents.

A plus for the resolution-independent vector-based format is that it can be scaled without loss of
quality, which is a big win when catering for different screen sizes and resolutions. Essentially,
one file will be suitable for all devices, whereas more traditional bitmap alternatives need to be
correctly sized for each specific device.

A word of warning: if you are planning on using SVGs, some older desktop browsers do not
support the format so it is advisable to use a PNG fallback to ensure full compatibility.

Icon fonts

A close relative to the SVG file format is the universally compatible icon font. An icon font
contains vector icons, logos and graphics all packaged into a single web font. There are thousands
of icon fonts available for free download and it’s also possible to create your own custom fonts by
using web services like Fontello or UIParade’s Glifo.

Advantages of the icon font are that they are fast, flexible, scalable and have the added benefit of
being able to be formatted via CSS.

Sprites

The use of image sprites has been considered good practice within the web development
community for a number of years. If you have frequently used graphics within a site, instead of
loading them individually, a better solution is to create a sprite sheet, which consists of all the
images in a single image file. The main advantage is a single HTTP request can load all of the files
on the sprite sheet, whereas individual files would require multiple requests and site speed would
suffer significantly as a result.

7.4.4. Responsive or adaptive

Mobile design and development forums are awash with threads debating the pros and cons of
responsive versus adaptive design techniques. The reality is that both techniques offer equally
significant advantages in comparison to their counterpart and consequently there is no clear
overall winner.

Responsive web design – pros and cons

Pros Cons

Device agnostic, will work well on all devices Site redesign and rebuild often required

Quicker development, as only one template Performance – slower page load than adaptive
required for all devices

Easier to maintain, as only one template to Unable to differentiate site on mobile/tablet

update

Mobile Web Design and Development Best Practice Guide Page 161

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Adaptive web design – pros and cons

Pros Cons

Site speed – optimum performance across all Harder to maintain – multiple templates to
devices update

Best experience – as design tailored for device Slower development on new site builds as
multiple templates need to be created and
tested

Can use different designs for mobile and

desktop to optimise experience

Designing without boundaries

The route that continuously produces the best results in mobile site design is to ignore the
framework and design a site which you believe has the best chance of delivering your customers’
objectives. Once the perfect site is designed, you can evaluate the framework and decide whether
responsive or adaptive is most suitable for your project. The design will then need to be tweaked
to conform to the nuances of the chosen framework.

Inevitably this approach will produce a considerably better final product. The ‘designing without
boundaries’ method creates a situation where the designer is able to push the UX and UI to its
limits, with any compromises carefully considered, which results in a site design that would
simply be unachievable when designing within the constraints of either responsive or adaptive
frameworks.

It is worth pointing out that consumers and users do not care whether a website is built on
responsive or adaptive technologies. They simply want to fulfil their objectives and visit your site
as quickly and easily as possible… if end users are framework agnostic, shouldn’t designers and
developers also be?

Note: There are certain situations when responsive or adaptive frameworks are predetermined
and not possible to be changed. In those situations the designing without boundaries
methodology is obviously not applicable. Such situations may occur when you are developing
for a closed environment, such as a legacy HTML output from a back office system or plugging
into an existing development environment which doesn’t give you control of the attributes
required for responsive layouts, such as designing a page for an eBay shop.

Mobile Web Design and Development Best Practice Guide Page 162

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
7.5. Key dos and don’ts
7.5.1. UX/UI
Cut the clutter

A key component to good UX/UI design is to focus on the areas of a site that are important to
users. It pays to be ruthless when it comes to trimming your content. Simplicity and clarity are
key to a functional UX and UI.

Keep form input to a minimum

Take away the heavy lifting for users by removing unnecessary form fields and inputs, and using
autofill to your best advantage. Essentially, do everything possible to make the site a breeze for
users. Simplistic and helpful interfaces will always leave users with a positive experience of your
site.

Don’t rely on your app

Just because you have an all-singing, all-dancing app doesn’t mean you can use it as an excuse to
neglect your mobile offering. The reality is that most users won’t download your app if they don’t
have a positive experience on your mobile site.

A mobile site is a shop window for your business, and a good mobile experience will go a long way
to nudge users into becoming regular customers. Regular customers are far more likely to
download your app than casual users.

Target/hit area

As mentioned previously in Section 7.2: Touch screen considerations, target/hit areas need
consideration. It’s a serious UX faux-pas not to give sufficient space to buttons and links.
Generally speaking the minimum pixel size should be 44pt x 44pt, although some user guidelines
suggest allowing even more.

For a more in-depth overview on the challenges and variations on target areas, see Smashing
Magazine’s Finger Friendly Design article68.

7.5.2. Mobile-specific HTML

Disable autocorrect on name fields

Unusual or obscure name and place spellings will often be autocorrected to match dictionary
words, but this annoyance can be easily avoided using the following code within a web form:

<input type="text" autocorrect="off" />

Enable autofill

Keeping form input to a minimum is good UX practice and a useful tip is to ensure autofill is
enabled on web forms:

<form autocomplete="on">

68http://uxdesign.smashingmagazine.com/2012/02/21/finger-friendly-design-ideal-mobile-touchscreen-
target-sizes/

Mobile Web Design and Development Best Practice Guide Page 163

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Numeric (telephone) keyboard for number fields

Avoid the frustration of inputting numbers through the QWERTY keyboard interface and present
users with a numeric keyboard for number fields (and always use in the case of credit card and
telephone number fields):

<input type="tel" placeholder="Telephone Keyboard" />

Email keyboard for email fields

An annoyance in a similar vein to those already mentioned is the necessity to navigate system
keyboards for the @ symbol when inputting an email address. Selecting the input type to email
overcomes this issue:

<input type="email" placeholder="Email Keyboard" />

Location services

Location services are a big win for sites which have location-specific requirements. A good
example is a branch finder. Instead of making a user type in the town or postcode to find the
nearest branch, enable location services and let the device do all the hard work.

Location code examples available here: http://www.w3schools.com/html/html5_geolocation.asp.

Click to call

Allow users to dial a phone number by simply tapping on it (this also works with images and
icons).

<!—- enable click to call on text -->

<a href="tel:012345678">012345678</a>

<!—- enable click to call on images -->

<a href="tel:012345678">
<img src"/images/graphic.jpg" alt="Example">
</a>

Click to SMS

This works in exactly the same manner as click to call.

<!-- enable click to SMS on text -->

<a href="sms://+44012345678"> 012345678 </a>

<!-- enable click to SMS on images -->

<a href="sms://+44012345678">
<img src"/images/graphic.jpg" alt="Example">
</a>

Disable auto detection of numbers

Certain mobile operating systems will attempt to be clever and detect a string of numbers within a
website as a phone number. To disable the accidental detection of non-phone numbers use the
following code (the code can be used in conjunction with the click to call code to ensure only
telephone numbers are clickable).

<meta name="format-detection" content="telephone=no">

Mobile Web Design and Development Best Practice Guide Page 164

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 View full site

Although the primary focus of a mobile site should be to deliver a slick and lean experience for the
majority of users, there will of course be some wishing to view information that is not
immediately available on the mobile version. It is highly recommended that a ‘View full site’ link
is added to the mobile version to allow users to view the desktop site.

UX tip: when adding a ‘View full site’ link to a website, ensure that clicking on the link keeps you
on the same page within the full site. It is extremely irritating if clicking the link redirects you to
the homepage.

7.6. Mobile designer’s toolkit

7.6.1. Software
Adobe Creative Suite – www.adobe.com

The Adobe Creative suite is a collection of tools that should be in every self-respecting designer’s
toolkit. Tools such as Photoshop, Illustrator, InDesign and Dreamweaver have long been
responsible for the creation of visually compelling websites and listed below are some of the key
components of the suite.

 Photoshop – Often the web designers’ tool of choice, used for every aspect of creating site
wireframes and visuals.
 InDesign – The increasingly versatile InDesign has, over recent years, become an extremely
useful tool in web design, and as a result has won over a number of Photoshop users due to its
speed and flexibility in creating web visuals.
 Illustrator – A must for web designers working with vectors and a long-time companion to
Photoshop.
 Edge Inspect – With the use of a Chrome plugin and a mobile app, Edge Inspect will allow
you to simultaneously view how a site is rendered on desktop, tablet and mobile, which makes
this an extremely useful testing and research tool.

Balsamiq – www.balsamiq.com

If you are looking for a comprehensive wireframe tool, Balsamiq is among the best of the bunch,
due to its ability to create interactive wireframes and prototypes. It makes the list ahead of other
tools due to its simple interface, cross-platform capabilities and Chrome plugin.

Opera Mobile Classic Emulator – http://www.opera.com/developer/mobile-

emulator
The exceptionally useful Opera mobile emulator allows you to view and test mobile websites on
hundreds of mobile devices directly from your desktop.

7.6.2. Tools
Favicon generator – http://realfavicongenerator.net/
Generate a complete set of Favicons for all browsers and platforms including touch icons for iOS,
Android and Windows 8 (including tile and taskbar icons).

Image compression – https://kraken.io/web-interface

Squeeze an extra few kilobytes out of your JPG and PNG files without compromising the quality.

Mobile Web Design and Development Best Practice Guide Page 165

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 Icon web font builder – http://glifo.uiparade.com/
Create icon webfonts directly from Photoshop (cost $19).

Retina/HiDPI – http://retinajs.com/

JavaScript generator to easily serve high-resolution images to devices with retina displays.

Web font kerning – http://www.kernjs.com/

A simple bookmarklet to put you back in control of your website’s typography.

7.6.3. Browser plugins

Firebug – http://getfirebug.com

A Firefox plugin that puts a wealth of web development tools at your fingertips while you browse.
You can edit, debug and monitor CSS, HTML and JavaScript live on any webpage.

7.6.4. Resources
Design resources

A selection of design resources to help with your web project, from templates and themes through
to buttons and widgets.

 Pixeden – http://www.pixeden.com/
 Premium Pixels – http://www.premiumpixels.com/
 UI Parade – http://www.uiparade.com/

Design inspiration

If you are struggling for inspiration, or just want to see some of the great stuff other people have
been up to, these sites are well worth a look.

 Dribble – http://dribbble.com/
 Awwwards – http://www.awwwards.com/
 Web Designer Depot – http://www.webdesignerdepot.com/

Responsive

The only resource you will need for everything responsive: http://bradfrost.github.io/this-is-
responsive/resources.html!

CSS animation

 Animate.css – http://daneden.github.io/animate.css/
 Easings – http://easings.net/

Mobile Web Design and Development Best Practice Guide Page 166

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
7.6.5. Developer resources
Browser support – http://caniuse.com/

Compatibility tables for browser support of HTML5, CSS3, SVG. Covers desktop and mobile
browsers.

SVG fallback generator – http://www.grumpicon.com/

SVGs are great, but some older mobile browsers don’t support the format. This drag-and-drop
tool creates failsafe PNG alternatives.

Code Canyon – http://codecanyon.net/

Plugins, themes, sliders, templates… you name it, it’s probably here.

CSS Tips – http://css-tricks.com/

Great resource of tips and tricks for CSS as well as HTML, jQuery and PHP.

7.7. Examples of good and bad practice

7.7.1. NHS Direct
Decommissioned site
Please note that the NHS Direct site was decommissioned just before we finished the report – always helpful!
However, we decided to keep the reference for the following reasons:

1. The page notifying users that the site has been decommissioned is not mobile optimised in any way.
2. Users are directed to NHS Choices instead and you’ve guessed it, this is not mobile optimised either!

So unfortunately for NHS Direct this still serves as an example of poor UX.

The NHS has long been the bastion of British healthcare and in the late 90s the NHS Direct
service was launched to provide health advice direct to individuals. The aim of NHS Direct was “to
provide people at home with easier and faster advice and information about health, illness and
the NHS, so that they are better able to care for themselves and their families”.

Taking the objectives of NHS Direct into account, it would be fair to assume that the fundamental
directive of this site would be to deliver key information quickly and efficiently, with the NHS
Direct telephone number and symptoms checker being the most important.

Sadly the NHS Direct site on mobile falls short – very short – on delivering this objective, so let’s
take a look at why…

Mobile Web Design and Development Best Practice Guide Page 167

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Figure 53: The NHS Direct homepage

A major issue of the site is that the desktop version is displayed when viewing on mobile devices.
Ultimately this means the site is impossible to read on a mobile device without zooming – a big
oversight in UX/UI design.

The site layout on mobile also does little to prioritise key areas and actions and as a result there
are no clearly defined calls to action for the user. That said, the symptoms checker is referenced
on the homepage three times, but unfortunately the rendering of the site on mobile makes it very
difficult to see any of these instances.

Also, it is surprising that despite NHS Direct being a predominantly telephone-based service their
phone number is nowhere to be seen on the homepage.

Lastly, the ‘Find your nearest’ section does not have location services enabled and supports
postcode entry only. Enabling location services could be critical for users of the site who are away
from home or on holiday, as these people are unlikely to know the postcode of an area they are
not familiar with.

Figure 54: Symptoms checker

Mobile Web Design and Development Best Practice Guide Page 168

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
It’s a similar story when users click on the symptoms checker from the homepage, which again is
not mobile optimised. Buttons and inputs are all considerably smaller than the recommended
mobile target areas. Text is practically impossible to read without zooming. Altogether, very hard
to navigate and an unfriendly user experience.

Figure 55: But wait, what is this…..?

Hidden in the footer of the site, there is a collapsed menu: ‘More from NHS Direct’. Clicking on
the hidden menu reveals a list of further options, one of which is the ‘Mobile symptoms checker’.

Figure 56: A mobile-optimised symptoms checker!

Yep, that’s right… there is already a mobile-optimised symptoms checker, yet it is located behind
a hidden menu!

So, why doesn’t this automatically load on the mobile version of the site?

Mobile Web Design and Development Best Practice Guide Page 169

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 Lessons of NHS Direct

It is vitally important to put yourself in the situation of the end user when designing a mobile site.
NHS Direct offers medical advice to the general public, so it is a reasonable assumption that a
large percentage of users will be distressed when viewing the site. The role of a designer in this
situation is to help the user find the information they are after as quickly and easily as possible.
The site should be the helping hand to finding the information, not the hurdle.

Most importantly, if you invested in building the tools (i.e. the mobile symptoms checker) don’t
hide it, make it load by default!

7.7.2. LateRooms.com
LateRooms.com operates in the extremely competitive discount hotel rooms market, a space that
is saturated with numerous operators selling the same rooms in the same hotels.

With an identical product offering, it’s vitally important for LateRooms to differentiate itself from
competitors and gain advantages wherever possible. One area it has succeeded in is the mobile
website.

Figure 57: Clear, uncluttered and very easy to use

The LateRooms.com mobile homepage has been designed purely with function in mind. The
pictures and distracting offers of the desktop homepage have been replaced with the items
required to book a hotel room quickly and easily.

The homepage on the mobile site is a pre-populated form with most of the information already
completed. LateRooms knows that the majority of bookings they receive from mobile are for the
same day, one room and two adults, so all the user needs to do is input their location… and they
even have that covered. Location services are enabled so you can search for hotel rooms around
your current location without the need to enter town names or a postcode.

Mobile Web Design and Development Best Practice Guide Page 170

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Figure 58: Minimal user input required

The well-considered and user-friendly interface continues onto the search results pages. Clear,
concise zoning of hotel information is restricted to show the critical information that the majority
of users require to make a booking (price, distance from location, satisfaction and an image). The
user experience is further enhanced with single-tap access to filter by ‘Star Rating’ and ‘Price’, as
well as the ability to sort results by price, distance and other common criteria.

Figure 59: Other pages

As you might expect, other pages throughout the site also adhere to the same well-considered
criteria. Hotel pages have one-tap access to facilities, reviews, maps and clear zoning of the
different room types. Selecting a room displays a ‘Book Now’ panel at the bottom of the screen to
allow you to view other pages. Search criteria can also be modified from any page thanks to a well-
conceived button. Once clicked, an expandable div opens to reveal the current search criteria,
allowing these to be amended and the corresponding results updated to reflect the changes.

Mobile Web Design and Development Best Practice Guide Page 171

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 What lessons can we learn from LateRooms?

The LateRooms approach is a shining example of what happens when the focus is on mobile
design and user requirements. They have resisted the temptation to include the upsell
opportunities featured on the desktop site and have instead focused on key user requirements: to
find available hotel rooms meeting their needs and the ability to book them quickly and easily.

By concentrating on their users’ requirements they have been able to create a lean and efficient
mobile experience. They realise that users will often be viewing their site on slow connections, in
stressful situations (missed train, breakdowns etc.) and they have designed a mobile site that does
most of the heavy lifting for users. They have clearly embraced the potential context in which the
site is being used.

7.8. Case study

Being equipped with the aforementioned information, techniques and methodology is great, but
putting it all into practice can be another story entirely.

The following case study demonstrates how these techniques can be put into practice on a mobile
project.

Note: The following case study is for demonstration purposes only and is not a genuine
customer brief. The procedures and processes used are genuine and the finished site can be
viewed on the following URL: http://www.graphitas.co.uk/randomboutique.

7.8.1. An overview of the brief

Random Boutique is an upmarket online women’s boutique, offering designer clothes and
accessories. They currently have a successful desktop-only web presence and want to expand their
offering to support tablet and mobile devices.

Their target audience is predominantly 20-40 year-old females, with a reasonable amount of
disposable income and active social lives. Typical interests of their target audience would be
fashion, beauty, celebrity and travel.

7.8.2. Defining the site

From the brief and discussions with the company the following list of potential features was
created.

Users viewing the site will want to:

– View and purchase clothing and accessories

– See current and seasonal offers
– Perform criteria-based search
– View clothing collections/styles
– Sign up for email newsletter
– Contact Random Boutique by phone
– View delivery details
– Find their nearest store
– View FAQs
– Find out more information about the company (‘About Us’ page)

Mobile Web Design and Development Best Practice Guide Page 172

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 – Meet the team
– Find out about recruitment
– Access social media accounts
– Read the blog

7.8.3. Target audience

To determine a typical customer of Random Boutique the existing users of the desktop site were
profiled and the social following was analysed. The following characteristics were outlined:

– Fashion conscious
– Regularly dine out
– Will go to bars/nightclubs at least once a month
– Will have a reasonable amount of disposable income
– Will have regular beauty treatments, such as manicures, hair, fake tan etc.
– Reads celebrity/fashion magazines such as Hello, More, OK, Look etc.
– Brand and label conscious
– Very active on social media, in particular Twitter, Instagram, Pinterest and Facebook
– Will have a smartphone and spend in excess of two hours a day using it
– Owns a tablet
– Uses mobile phone in preference to desktop device for browsing the web

7.8.4. Refine the original list of features

The next stage in the process is to compare the original list of features outlined in Section 7.8.2:
Defining the site against the user characteristics from Section 7.8.3: Target audience to decide if
the features should be included on the homepage, subpages or removed from the mobile site
altogether.

Techniques such as MoSCoW prioritisation (mentioned in Section 7.4.1: Define your site) can be
useful methods of determining essential and nice to have features.

For more information on the MoSCow prioritisation method, see

http://en.wikipedia.org/wiki/MoSCoW_method.

An example of a feature refinement

Feature Include on mobile site Notes

View and purchase clothing Yes (homepage) A key feature of the site, should be a primary feature of the
and accessories homepage and also be accessible throughout the site
Current and seasonal offers Yes (homepage) Should be prominent on the homepage as will be a key
mechanic to push new seasons, sale etc.
Perform criteria-based Yes (throughout site) Criteria-based search should be accessible from anywhere
search within the site
View clothing No Clothing collections, ‘shop the look’ would do little to drive
collections/styles sales and including this would add to homepage clutter
Contact Random Boutique Yes Represented on homepage with reasonable prominence,
by phone throughout the site contact details should be included in
the footer area

Mobile Web Design and Development Best Practice Guide Page 173

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Feature Include on mobile site Notes
View delivery details Yes (subpage) Delivery details will be represented at relevant areas of the
site (product and purchase pages)
Find their nearest store Yes A key feature of the mobile site, must take advantage of
location services, to be represented on homepage
View FAQs No Not an important item for the mobile site, specific FAQs
can be placed within relevant pages (i.e. returns/delivery
info within checkout process)
Find out more information No Not considered an important component for the mobile site
about the company (‘About
us’ page)
Meet the team No Not considered an important component for the mobile site
Recruitment No Not considered an important component for the mobile site
Social media accounts Yes Social icons should be visible on all site pages
Blog No Not considered an important component for the mobile site

7.8.5. Wireframing and site concepts

Now the feature list has been refined and audience characteristics have been defined, the creation
of wireframes and rough layout concepts is the next logical step in the process.

This is the stage where account managers, planners and the creative team discuss the site
requirements and target audience, with a view to creating initial wireframes and outline visuals.

During this process, creating rough sketches or wireframes is a huge advantage as it allows the
wider team involved in the meeting to comment and discuss content priority, layout etc. without
the need for creating time-consuming visuals. Additionally, the wireframes can be annotated to
highlight features and interactions of the UX and UI.

From experience the quickest way of doing this is using a layout pad and pencils. There are of
course many digital alternatives, but none which compare to the immediacy of sketching out
ideas.

Figure 60: Annotated homepage wireframe

The above wireframe incorporates the key homepage features and shows how they will be
represented on the mobile homepage.

Mobile Web Design and Development Best Practice Guide Page 174

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 Additionally, the annotations concisely explain the functionality, structure and any further
relevant information.

In this instance the wireframe has been freehand sketched. A major advantage of this approach is
that a designer can subtly theme the wireframes to reflect the target audience and give an
indication of the proposed site design.

Figure 61: Product page wireframe

7.8.6. Evaluating and planning

With the annotated wireframes complete, the next logical step is to include the teams responsible
for build and development. Concerns over technology barriers, usability, browser and platform
compatibility are then discussed. The wireframes are then amended accordingly and passed onto
the design team to create site visuals.

This stage would typically be where decisions on whether the site is responsive or adaptive are
made.

Note: On larger projects working prototypes are often created using the approved wireframes to
show the site functionality in greater detail. Prototyping tools such as Balsamiq, Adobe Muse,
Adobe InDesign etc. are all capable of creating working prototypes from wireframes.

7.8.7. Site visuals

Using the signed-off annotated wireframes, a designer can then create final site visuals. They will
bring together the layout, UI and UX features of the wireframe and add colour, backgrounds and
photographs to produce site visuals.

The finished visuals bring the wireframes to life and the resulting visuals are then ready to be
presented to the customer for feedback.

Mobile Web Design and Development Best Practice Guide Page 175

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Figure 62: From wireframes to finished site visuals

Mobile Web Design and Development Best Practice Guide Page 176

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
7.8.8. Build
Since the developers are heavily involved at the design and wireframing stage, there should be no
unforeseen surprises or resistance from the development team. Their buy-in to the project should
have already been cemented by involving them at the concept and ideas stage.

7.8.9. Finished site

Although this case study is for a fictitious site, all of the preceding steps should make up the
design process of any significant web build and to prove these concepts work we have built a fully
working (although non-transactional) example of the Random Boutique website.

The working example of the site can be viewed on either mobile or desktop (when accessing the
site on desktop click the mobile icon in the header bar to view site as a mobile user).

To view the site, go to the following URL: www.graphitas.co.uk/randomboutique.

Mobile Web Design and Development Best Practice Guide Page 177

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
8. Technical SEO for Mobile Development
Contributor
This section was written by Sohaib Siddique, Technical SEO Lead at Verve Search (@sohaibmsiddique).

Numerous studies now show that the majority of users start their consumer purchase journey on
mobile, using both organic and paid search. McKinsey estimates that 80% of all web traffic will be
through mobile in ten years’ time. Getting mobile SEO right today when it is on the rise will keep
you at least in line with the market, if not ahead of your competitors.

Google has updated its algorithm to take mobile accessibility into account and many other search
engines have followed. A technical mobile SEO strategy must be different than traditional
technical SEO. The good news is that exemplary technical mobile SEO is still rare, which gives
SEOs an opportunity to overtake competitors. The commercial implication of getting this wrong is
largely consistent with poor traditional technical SEO practices: a drop in rankings, traffic and
conversions.

In this section we look at best practice advice for mobile SEO.

User experience is central to mobile SEO success

“User experience is the single most important factor for the success of a mobile SEO strategy in 2014. Even top
retailers struggle with the mobile experience.
“User experience impacts a site’s ability to engage visitors, which we know has a direct impact on rankings. More
importantly, it impacts a site’s ability to generate conversions. Therefore, ensuring your site provides mobile
users with a great experience can improve your site’s rankings, as well as its ability to engage and convert visitors
into customers.”
Jay Taylor, 6 Essential Elements for Mobile SEO Success in 2014, Searchenginewatch.com 69

8.1. Development implications

The development method you chose for your mobile website will directly impact your site’s
visibility. Google has come out specifically and said that it prefers responsive web design
solutions. This does not mean that if you have an m-dot domain you will not rank high, but it’s
easier for Google to crawl one set of pages and index them rather than crawl two sets of pages and
then figure out which one to index for which platform.

8.1.1. Responsive web design

This is generally the most preferred configuration. These sites serve all devices using the same
URLs and HTML codes with the responsive elements coded into the CSS. This will change how
the page appears on devices with different screen sizes.

Pros Cons
 Single URL for all versions  Development and design can be long and
costly
 No duplicate content  Less mobile-unique content
 Lower redirects and page load time  Can be slower on a mobile if done
incorrectly
 Easily shareable

69 http://searchenginewatch.com/article/2320360/6-Essential-Elements-for-Mobile-SEO-Success-in-2014

Mobile Web Design and Development Best Practice Guide Page 178

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 Key dos
 Allow search engines to crawl the whole website in robots.txt, including CSS, JavaScript,
images etc.
 Attend to elements that don’t effectively display on mobile screens such as JavaScript, large
images, flash, videos etc.
 Change how content appears on a mobile website i.e. if navigation bars seem too cluttered,
change them to dropdown menus.
 Use breakpoints instead of pre-determined design sizes.

Key don’ts
 Disable the user’s ability to zoom in and out.
 Hide content which will not fit on a mobile screen using “display: none;”.
 Let the responsive nature determine the design; your design should always be adjusted based
on screen sizes i.e. by using a responsive grid system.
 Forget about the average size of a user’s finger; do not make links and other elements too
small. Apple recommends 44px to be the minimum touchable size on a mobile screen.

8.1.2. Adaptive web design

This type of setup serves a different HTML and CSS for the same URL based on the user agent
request.

Pros Cons
 Single URL for all versions  Development and design can be long and
costly
 No duplicate content  Complicated technical implementation
 Can customise mobile content
 Easily shareable

Key dos
 Implement a Vary HTTP header to allow search engines to discover the mobile content.
 Serve different HTML and CSS on the same URL by varying user agent requests i.e. mobile
users and mobile bots should see a mobile-specific website.
Example of HTTP header
GET /page-1 HTTP/1.1
Host: www.yoursite.com
User-Agent: (...insert user-agent string...)
(...rest of HTTP request headers...)
HTTP/1.1 200 OK
Content-Type: text/html
Vary: User-Agent
Content-Length: 5710
(... rest of HTTP response headers...)

 Understand common pitfalls that occur when detecting user agents; the process is error-
prone.
Key don’ts
 Forget to allow mobile users the option to view the desktop version and vice-versa.

Mobile Web Design and Development Best Practice Guide Page 179

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
8.1.3. Mobile-specific site development
This configuration involves different URLs for a desktop and a mobile version of your website.
The following is a common example of such implementation:

 Desktop: www.yoursite.com
 Mobile: m.yoursite.com

Pros Cons
 Easy to implement  Potential for duplicate content
 Can customise mobile content  Split of link authority

Key dos
 Ensure you have a consistent URL structure for mobile websites i.e. by using an m-dot
subdomain.
 Use 301 redirects to point mobile users and mobile bots to the mobile-specific website if
accessed on a desktop.
 Use 301 redirects to point desktop users and desktop bots to the desktop-specific website if
accessed on a mobile.
 Add a rel="alternate" tag on the desktop page which points to the appropriate mobile URL.
This can also be done in the sitemap and is called a switchboard tag.
 Add a rel="canonical" tag on the mobile page which points to the appropriate desktop URL.
This can also be done in the sitemap and is part two of a switchboard tag.

Key don’ts
 Forget to allow mobile users the option to view the desktop version and vice-versa.
 Forget to set an analytics filter to show the complete hostname in order to analyse m-dot
subdomain activity.
 Have logos, navigation etc. overpowering the actual content; mobile users want to see content
on the go and do not prefer scrolling endlessly to get there.
 Forget to link-build and drive authoritative content on the mobile version of the website;
remember, an alternate mobile website is a whole new website altogether.

Mobile Web Design and Development Best Practice Guide Page 180

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
8.2. Indexation
8.2.1. Verifying your mobile website
The first step to tell search engines about your mobile website is to verify it in the appropriate
Webmaster Tools settings. Verifying your mobile site with Webmaster Tools will give more
mobile-specific information such as search queries that do not show up as ‘not provided’.

Google and Bing require every subdomain to be verified separately from the parent domain, so if
you have set up a parallel website (i.e. using an m-dot domain), then you will need to add this to
Webmaster Tools. This is done exactly how you would verify a regular website.

8.2.2. Mobile sitemap

Google has specific criteria for mobile sitemaps; they are similar to XML sitemaps with an
additional <mobile:mobile/> tag requirement. An example is shown below:

<?xml version="1.0" encoding="UTF-8" ?>

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
xmlns:mobile="http://www.google.com/schemas/sitemap-mobile/1.0">
<url>
<loc>http://m.yoursite.com/article100.html</loc>
<mobile:mobile/>
</url>
</urlset>

You must ensure this is the sitemap you upload after you verify your mobile website on
Webmaster Tools.

8.2.3. User agent management

If your mobile website is dynamically served, or has a separate mobile subdomain, you will have
to tell the crawlers which user agent the website serves. This can be configured in the HTTP
request header for Googlebot-Mobile as shown below:

Figure 63: Googlebot-Mobile HTTP request header

Example of HTTP header for feature phone Googlebot

GET /page-1 HTTP/1.1

Host: www.yoursite.com
User-Agent: SAMSUNG-SGH-E250/1.0 Profile/MIDP-2.0 Configuration/CLDC-1.1
UP.Browser/6.2.3.3.c.1.101 MMP/2.0 DoCoMo/2.0 N905i
(...rest of HTTP request headers...)

Example of HTTP header for smartphone Googlebot

GET /page-1 HTTP/1.1

Host: www.yoursite.com
User-Agent: Mozilla/5.0 AppleWebKit/536.26 Version/6.0 Mobile/10A5376e
Safari/8536.25
(...rest of HTTP request headers...)

Mobile Web Design and Development Best Practice Guide Page 181

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
8.3. Ranking and clickthrough considerations
Google has implicitly stated that websites optimised for mobile will be at a ranking advantage
when a user accesses Google’s mobile index. The mobile search engine results differ from
standard results almost in the same vein as two different countries differ from one another; they
are two separate indexes.

Search engines rank mobile websites in the SERPs based on a slightly different criteria compared
to desktop websites. For example, search engines put more emphasis on page load times and
redirects. These all relate to enhancing the mobile user experience, the ultimate goal a mobile
website should aim to achieve.

8.3.1. Page speed

Mobile users are on the go and the best way to enhance their user experience is to offer pages
which load quickly. Because of the characteristics of data providers and the networks mobile
phones work on, it’s essential to decrease page load time as much as possible.

On multiple occasions, Google has announced that site speed will have a big impact on mobile
SERPs. The most significant source of increased page load times occurs when the HTML is being
parsed, usually caused by JavaScript. If the browser runs into an external JavaScript file when it
is parsing the HTML file, it halts the process until the JavaScript file is downloaded, parsed and
executed. On a mobile device, this results in more round trips, which not only slow down the
loading process, but also take up more network data. The same happens when a browser loads
external CSS files.

Having these codes and scripts on every HTML page is unrealistic; instead, the JavaScript and
CSS that is needed to render the page should be inline and any code and script that is required for
additional functionality should load externally and towards the end of the HTML code.

The following example shows the loading of JavaScript and CSS from inefficient to efficient, taken
from Bryan McQuade’s blog70.

70 http://calendar.perfplanet.com/2012/make-your-mobile-pages-render-in-under-one-second/

Mobile Web Design and Development Best Practice Guide Page 182

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Figure 64: Mobile HTML code

Example of inefficient mobile HTML code

<html>
<head>
<link rel="stylesheet" href="my.css">
<script src="my.js"></script>
</head>
<body>
<div class="main">
Here is my content.
</div>
<div class="leftnav">
Perhaps there is a left nav bar here.
</div>
...
</body>
</html>

Example of mobile-optimised HTML code

<html>
<head>
<style>
.main { ... }
.leftnav { ... }
/* ... any other styles needed for the initial render here ... */
</style>
<script>
// Any script needed for initial render here.
// Ideally, there should be no JS needed for the initial render
</script>
</head>
<body>
<div class="main">
Here is my content.
</div>
<div class="leftnav">
Perhaps there is a left nav bar here.
</div>
...
<!--
NOTE: delay loading of script and stylesheet may best be done
in an asynchronous callback such as `requestAnimationFrame`
rather than inline in HTML, since the callback will be invoked
after the browser has rendered the earlier HTML content to the screen.
-->
<link rel="stylesheet" href="my_leftover.css">

As seen with the example above, both the JavaScript and the CSS needed for ‘main’ and ‘leftnav’ is
loaded inline on the HTML and the external download of the JavaScript and CSS is moved to the
bottom of the code.

Mobile Web Design and Development Best Practice Guide Page 183

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
8.3.2. Redirects
Another source of page load delays is HTTP redirects. This is common when a website is
redirecting to a separate mobile website (i.e. from www.yoursite.com to m.yoursite.com). These
redirects add more delays because of TCP connection times and DNS resolution.

Faulty redirects will also directly affect your mobile website’s rankings. These are redirects where
a page listed in the SERPs redirects all mobile users to a single mobile page rather than to the
specific mobile-optimised version of the page the user actually wanted:

Figure 65: Faulty redirects

8.3.3. Google+ listing

Just like desktop search, Google has put emphasis on the presence of a Google+ listing. Many
SEOs believe that Google+ has influence on both personalised and non-personalised search
results. This is perhaps even more important for mobile SEO due to its portable nature; local
search represents about 40% of mobile searches.

Due to the size of a mobile screen, the presence of a Google Local listing will be more prominent
on a mobile phone than on a desktop. Having a Google Local profile will also put your website on
Google Maps, which shows up in the SERPs and also appears on the Maps app. Here are some key
considerations when optimising for Google Local on mobile:

Element Recommendation
On-page SEO Just like desktop, have dedicated pages for targeted locations
optimised in the content and title/meta tags.
Listing List your website on Google Places for Business to get a Google
Local profile.
Images Include images in the Google Local listing such as the storefront
with its surroundings and some product/service offerings.
Name/address/phone Ensure you have consistent NAP citations on page, in local
number (NAP) directories and any other relevant areas on the web.
Social presence Have a strong Google+ social presence and Facebook page.
Reviews Have regular up-to-date reviews on Google+ and on your website
which provide real insight.

Mobile Web Design and Development Best Practice Guide Page 184

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
8.3.4. Mobile markup
Again, due to the size of a mobile screen, markups that appear in the SERPs are more prominent
than on a desktop. Ensure you have one or more of the following markups for local in place:

Element Recommendation
Schema.org/Place Address and phone number
hCard Address and phone number
(microformats.org/wiki/hcard)
KML file for Google Maps Name, link, coordinates, description, icon etc.
Schema.org/LocalBusiness Local business markup

Regular markups that are used on desktop websites are also recommended for mobile websites:
i.e. reviews, ratings, rel="author" etc.

8.3.5. Title and meta description

Titles, meta descriptions and URLs should be short, relevant and to the point.

The key difference here is making your title and meta descriptions concise, always keeping the
mobile user experience in mind.

If you have optimised for local pages, ensure that these are included in the title and meta
descriptions as well.

8.4. Useful tools and resources

Google’s multi-screen resources page
http://www.google.co.uk/think/multiscreen/

Google offers numerous white papers and case studies on the mobile strategies from successful
major brands. There is also a tool on the site to analyse the speed of any website for mobile which,
when used, opens up Google’s PageSpeed Insights tool.

Google’s PageSpeed Insights tool

http://developers.google.com/speed/pagespeed/insights/

Measured on a score from 1-100, Google’s PageSpeed Insights tool will quickly diagnose some
problems holding a website back from being 100% mobile optimised from a speed point of view.

The tool not only identifies the weaknesses for mobile in a website, but offers some generic
information on how to fix them and highlights examples of problem pages. It also offers user
experience suggestions, such as font size, though these are still in beta and are not included as
part of their scoring metric. Another added bonus is that it quickly flips over to the insights for the
desktop version of a website, which has a separate speed score and suggestions for trouble areas.

Google’s ‘Fetch as Google mobile bot’ option

http://www.google.com/webmasters/tools/

This tool works the same as it does for the desktop version where Google will display a webpage as
Googlebot sees it. In Google Webmaster Tools, look under the ‘Crawl’ dropdown and find ‘Fetch
as Google’. Once there, enter the URLs from a website for Google to find, adjust which crawler to
use (‘Web’ used for desktop, ‘Mobile: cHTML’ used mainly for Japanese websites, ‘Mobile:

Mobile Web Design and Development Best Practice Guide Page 185

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
XHTML/WML’ used for feature phones, ‘Mobile: Smartphone – Deprecated’ for older
smartphones and ‘Mobile: Smartphone – New’ for newer smartphones) before it crawls and
returns the page as the bot sees it.

Compare the fetched version to the mobile version that renders regularly and look for gaps in
information that should be in the code for the fetched version but is missing. Focus on fixing
these areas to make them more visible for the crawlers. This tool has the added benefit of alerting
Google to new webpages on a site, so if a mobile version of a website has recently been built
Google can immediately index it using this feature.

Screenfly
http://quirktools.com/screenfly/

Screenfly is a nifty responsive screen testing tool from Quirktools that quickly adjusts how a
website will render on different screen sizes. Choose from a Motorola RAZR V3m sized screen at
176x220 up to a 1080p television set at 1920x1080. There is even an option to customise a screen
size, rotate the display device and scroll down the page.

Web Sniffer
http://web-sniffer.net/

Web Sniffer is an HTTP Request and Response checker which acts much like the ‘Fetch as
Googlebot’ tool but clearly labels the header responses of any website. Use this to test if dynamic
serving is set up correctly by choosing ‘iPhone Mobile Safari’ from the ‘User agent’ dropdown
menu.

User Agent Switcher plugin for Firefox

https://addons.mozilla.org/en-US/firefox/addon/user-agent-switcher/

Created by Chris Pederick, this free plugin for Firefox quickly changes a browser’s user agent to a
mobile device in order to see how any website responds. This tool has the added benefit of
viewing a website as Googlebot instead of using the fetch tool mentioned above, though it will
only fetch a site as the desktop Googlebot.

Mobile Web Design and Development Best Practice Guide Page 186

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
8.5. Examples of good and bad mobile SEO
8.5.1. Good mobile SEO – Vouchercodes.co.uk
Vouchercodes.co.uk scores a 91/100 for mobile on Google’s PageSpeed Insights, higher than
Google itself. It is one of the few websites that does not have any urgent warnings, although there
is still room for improvement.

Figure 66: Vouchercodes.co.uk mobile site

What Vouchercodes.co.uk has done well

 Avoided landing page redirects to save on requests sent.

 Enabled compression to decrease server file transfer size.
 Minified CSS and HTML files to save on server request size.
 Prioritised visible content to reduce network round trips.
 Decreased server response time to less than 200ms.

What Vouchercodes.co.uk could improve

 Eliminate render-blocking CSS files in above-the-fold content.

Google recommends that websites remove all additional JavaScript and CSS elements/files that
interfere with loading any above-the-fold content on a page. This is content that the user initially
sees on a screen when the page first loads. While Vouchercodes.co.uk has done this for the
majority of their CSS and JavaScript, there is still some unnecessary code.

Mobile Web Design and Development Best Practice Guide Page 187

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
8.5.2. Room for improvement – Wired.co.uk
It’s never flattering to be called out in a negative way so rather than using a website that appears
to have never even considered mobile SEO, we have decided to draw attention to one that has
implemented the basics.

Wired.co.uk has attempted some form of responsive design, however, it still scores a remarkably
low 27/100 in Google’s PageSpeed Insights tool with numerous urgent warnings.

What Wired.co.uk has done well

 Focused on visible content for the user.

 Considered browser size by implementing responsive aspects on certain parts of the website.

Figure 67: Wired.co.uk site focus

What Wired could improve

 Implement responsive design across the entire website instead of only the header.
 Reduce CSS files being loaded from three to one.
 Reduce the number of scripts loading from 33.
 Use browser caching to speed up load times for repeat visitors.
 Move JavaScript lower on the page to speed up the load time for visible aspects.
 Reduce the overall size of JavaScript code.
 Reduce the number of images loading (currently at 198).
 Enable compression via gzip or a similar function.

Mobile Web Design and Development Best Practice Guide Page 188

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
9. Summary and Recommendations
Contributors
This section was written by David Skerrett, Managing Partner at Nimbletank (@skegz) and James Gurd, Owner
of Digital Juggler and Head of Digital at CrowdShed (@jamesgurd) and contributed to by Ryan Webb, Digital
Development Director at Equimedia (@equimedia) and Jonny Stewart, Senior Ecommerce Manager Europe at
PerriconeMD.

Deciding on the development approach for your mobile website is a complex challenge but one
that is achievable if you approach it in a structured and methodical way. The key to any challenge
is to understand the goals you’re trying to achieve and the issues that could prevent you from
getting there, then evaluate the options in light of this to understand relative pros and cons.

As we’ve seen in this report, although responsive web design is fast becoming the model of choice
for many ecommerce teams, it isn’t always the right or best choice. Think about the implications
of your decision on all facets of the business, including the ongoing maintenance costs and the
resource demands you need to satisfy.

Rome wasn’t built in a day and to achieve the optimal result, flexibility is required; this often
means some compromises along the way. Some businesses discover that their end goal isn’t
achievable within the current business constraints, so a long-term project is devised where a
gradual progression towards the end goal is planned and implemented. Bear in mind that
technology and good practice evolve too, so your project needs to be agile and respond to these
changes. Don’t stick to a plan that is no longer practical simply because 12 months ago it was what
the business committed to.

Finding a way through the complexity

“Define and iterate the right approach based on the context of your business goals and capabilities along with
your customers’ needs. Consider speed, search, budget, time and what you have already in place. There is no
right or wrong answer, but it’s definitely worth taking one step back at the beginning to consider everything,
before taking two steps forward with the mobile solution that feels right for you and your business/brand.”
David Skerrett, Managing Partner, Nimbletank

9.1. Is there a ‘right’ approach?

There is a ‘right’ approach: the best approach available to you at the point you make
your decision, based on the context of your business goals and capabilities along
with your customers’ needs. The experience should deliver, and it should be quick.

Good isn’t good enough

Poor user experience doesn’t just increase bounce rates and reduce engagement and conversion, it
can mean loss of long-terms sales and brand damage. So empathy for the user across devices is
the right approach. With mobile, if you don’t get it right the first time you might not get
a second chance.

Technology should facilitate the achievement of goals; the technology is moving quicker than
most companies, so it’s important to do your research and get senior backing. Be collaborative, no
one department can crack this on their own.

Mobile Web Design and Development Best Practice Guide Page 189

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Fast isn’t fast enough

Unfortunately it is quite easy to make a slow responsive website. And a lot of brands do. Most of
the bad practice being used now utilises a JavaScript/CSS trick to hide unwanted HTML and
related assets which still forces mobile devices to download it. So responsibility is key when
choosing responsive design.

The reality is that mobile site development is complicated and ever changing. Solving it won’t be
easy but that doesn’t mean it’s not achievable with the right focus and effort.

Speed is of the essence. The trouble with RWD is that performance is being
neglected and not being fully prioritised. 71% of mobile users expect mobile sites to load as
fast if not faster than desktop sites. 74% of mobile visitors will abandon a site if it takes longer
than five seconds to load. So we have five seconds of someone’s time. Not long. In fact, a one
second delay in page load time equals 11% fewer page views, 16% decline in satisfaction and 7%
loss in conversions. Therefore technically you need to think about:

 Reducing requests and payload

 Conditional and lazy loading
 Responsive images
 Building mobile first

There isn’t really a silver bullet

Depending on your current business situation, one option is to do absolutely nothing – if it’s not
broken, don’t fix it. Or you could develop a standalone mobile site. Or you could develop a RWD
solution, or an adaptive solution, or a RESS hybrid one.

RWD is being touted as the silver bullet solution to the ‘splinternet’ – the multi-device
fragmenting internet age that we are witnessing. Desktop-only websites are being made ‘squidgy’
through RWD’s fluid grids (columns and proportions), flexible media (stills and video) and media
queries (the secret sauce). The problem is that most RWD projects are coming in late, are over
budget and leave a bad taste in people’s mouths.

One of the reasons for choosing responsive is that it is the least-worst option; it is the middle
ground between adaptive – which can be a costly option – and a mobile site, which delivers a
quick, often elegant solution but could lead to SEO and sharing issues.

The reality is there is no one single right solution that works regardless of business goals,
markets, budgets, resources and user need states. Responsive websites generally work well for
content-heavy websites such as news sites, with not a lot of difference in user intent between
mobile users and desktop users and fairly simple functionality.

Adaptive websites, on the other hand, shine in most cases where user intent on mobile differs
significantly and website performance becomes a crucial factor in determining visitor conversion
and satisfaction, such as in ecommerce or travel websites.

While both responsive design and adaptive delivery have their own merits, which one is right for
you can be answered by delivering against your customers’ needs while satisfying your business
goals. Any company, small or big, wants the same thing: things built fast, that have the maximum
desired effect, with the minimum cost possible.

Mobile Web Design and Development Best Practice Guide Page 190

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Equimedia’s approach to client solution delivery
“RWD is only one of a number of approaches to cross-device optimisation available – but it is a great approach
and solutions/techniques are developing all the time.
“Clients sometimes come to us asking for a ‘fully responsive website’ when actually they are confusing the
terminology. What they want is a website that is ‘optimised across devices’ but don’t realise they are using
terminology that is just one of the options available.
“We therefore challenge them to consider the best option with us – looking at all options available, rather than
immediately diving into a RWD solution.
“A responsive website may well be the right approach (for content/brochure-heavy websites it usually will be).
For other sites it may actually be one of the other more ‘adaptive’ solutions, which would work better for them
(for example, if their audience engage with their website in very different ways on different devices or if their
desktop journey is just too complex to translate to a smartphone screen).
“We often point to BBC and eBay as examples of non-responsive solutions (although they do have large budgets
of course!). A mobile app (native or web-based) may also be a better (or additional) option in some cases.
“As with all our client decisions, we help them pull together a business case and with a plan to deliver ROI most
effectively. In specific instances it is very easy to get a very quick landing page in place to partially resolve the
solution while you carefully consider the options.”
Ryan Webb, Digital Development Director, Equimedia Limited

Deal with complexity by asking fewer, better questions

The key challenge initially is to take one step back to take two steps forward. The best way to deal
with complexity is to ask the right questions upfront.

 How about we start with your business goals… What does success look like for my web
project? How will I measure it? What are the KPIs?
 And your customers… Who are they, where are they, how do they use various mobile
devices, what are those devices and how does their behaviour differ by time of day, location
and device? What desirable behaviour do we want to see more of, or what problems are we
trying to solve? What are your user insights? How will you optimise?
 Think about the context, need state and the experience you wish to deliver. If
you’re a car manufacturer, mobile visitors may want to call a phone number to get something
fixed, or find their nearest dealer, not necessarily read a brochure or configure a car, which a
tablet user may prefer to do. Focus is a good thing here: learn to prioritise.
 Think mobility and usability, not just making a website render on mobile devices. If you
get too focused on the limitations of a 4-inch screen, you forget the relevance and value you
can add through location and other mobile sensors accessible to us as marketers.
 And your resources… How much time do you have and what is your budget? Do you have a
suitable partner? What does you future roadmap look like? Can you launch and then change
direction if you need to?
 What kind of unique mobile functionality you might deploy in the project
roadmap: maps, payment, videos, imagery, sharing, search, multi-variant testing and log-in,
through to more involved technology such as iBeacon, NFC or access to camera.
 Search optimisation – Are you (and your stakeholders and consumers) okay with multiple
domain names that may hamper your SEO efforts? Do you want social sharing to push
desktop users to a mobile website designed for a 4-inch screen? Do you have the resource and
time to maintain two separate content management systems, one for mobile and one for
tablet and desktop? If you can answer “yes” to these questions then a dot mobile site could be
an option, particularly if you have budget constraints and limited CMS updates to make.

Mobile Web Design and Development Best Practice Guide Page 191

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
 Design for the future

However, we don’t know for certain what will happen in the future.

Three years ago when the iPad was announced, many influential people took great delight in
saying they didn’t know why they would need a tablet. One reviewer said the iPad “looks like a
giant iPod touch” and couldn’t imagine how it could fit into his life. Now look at tablet usage
globally. Three years is a long time in mobile so projecting forward is very hard.

What we do know is that inside every marketer is a consumer. And our inner consumer wants to
be visiting sites that understand what we need almost before we do, that load in an instant
regardless of location or connection type or device. We want to flip between devices seamlessly
during the day or week and still be delighted with highly visual, highly relevant content and
commerce options that recognise who we are. That might sound like too much to ask for right
now, but expectations among mobile consumers are only going to rise, given our emotional
attachment and dependency on our devices and our desire to squeeze as much out of our 24-hour
days as possible!

Build it and they won’t come

Search is the front door to the web; get it wrong and your paid media budget (if you have one) is
going to need to keep the lights on. It’s the equivalent of building your shiny new house on a
beach without any foundations. So focusing on discoverability with your mobile solution is key.

Listen to your customers and work the data

Being flexible is a future strategy, being always-on with mobile experience optimisation and
analytics will serve you well. Identify key high penetration devices to optimise for and QA on.

Budgeting

Dedicate appropriate budget to mobile; this is not a trend that is going away. It is common for
brands to have between 25 and 55% of traffic from mobile devices. Dedicate at least that
percentage to your mobile marketing efforts, both in terms of time/resource and
production/media budget.

How Perricone MD approached mobile web design

“As a client-side ecommerce manager, responsive design for me is not a new one-size-fits-all front-end
framework or grid that reacts to a browser or viewport size; it’s simply the ability to format content to a device
type in order to provide the highest level of engagement possible. What that meant for Perricone MD, was the
choice to display a separate template to mobile devices that is both specifically tailored to mobile interactions
and the type of content that suits a mobile browsing context.
“Our decision to develop a mobile strategy was born out of a combination of trends and our own data. Mobile
traffic has been increasing at a rate of more than double year-on-year, with tablets also now overtaking desktop/
laptops for the first time in 2013. Whereas with tablet traffic, both micro and macro conversion rates were in
tandem with existing desktop data, mobile rates were very low. We knew that this was an area where we had to
make changes.
“Having only migrated to Magento nine months prior, we didn’t have budget to redevelop the existing front-end
framework to be fully responsive. Creating a duplicate mobile site to point to an m-dot sub-domain was also not
viable as we don’t have the staff to be able to manage dual code bases.
“Instead we took the option of running an HTML5 template off the same code base that switches based on being
viewed on a mobile device, instead of the viewport size.

Mobile Web Design and Development Best Practice Guide Page 192

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
How Perricone MD approached mobile web design (cont.)
“This provided us with the following benefits:
 Faster design time
 A faster and cheaper development process
 Simpler testing
 Easier iteration process
“This comes with some extra ongoing design resource – namely that on certain pages we need to create dual
imagery/content. However, this also means that we don’t have to compromise by making all media fully
responsive.
“With regards to custom content (all of our CMS landing pages for example) we can simply use media query
based HTML that will adapt within either the desktop or mobile templates, meaning that we don’t need to write
content twice.
“As we are learning more and more, we are able to add more and more responsive elements, in a more agile
manner. This really reduces the risk of damaging the existing desktop user experience.
“All in all, we launched the mobile website v1.0 in under four months at a cost of £8,000 in development/testing,
as we were able to wireframe and design in-house, with further iterations to come. SEO traffic, engagement and
revenue have all risen dramatically since.”
Jonny Stewart, Senior Ecommerce Manager Europe, Perricone MD

9.2. Key takeaways

Always consider the following when trying to decide the best development approach for your
business:

 Start with a ruthless business AND consumer focus.

 Think beyond screen size and think about the consumer context of use.
 Define the business context: operational workflows, stakeholder management, ownership etc.
 Understand resource availability and ongoing maintenance requirements.
 There is no silver bullet solution and there isn’t a right answer to this exam question.
 Ask great questions to see through the complexity.
 Consider the search implications of your mobile solution.
 Listen to the data.
 Get your budget right.
 Learn to compromise (and know when to do it).
 Don’t think it’s all or nothing – you can use a phased approach to get your mobile site where
you want it to be.

Mobile Web Design and Development Best Practice Guide Page 193

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
10. Useful Resources
You will find lots of useful resources listed in each section of the report. In addition, we
recommend the following general resources to help with your mobile project.

Econsultancy reports

 Econsultancy / BuyDesire Mobile Marketing and Commerce Report

https://econsultancy.com/reports/mobile-marketing-and-commerce-report

 Econsultancy / Kontagent Mobile Sophistication And Strategy Report

https://econsultancy.com/reports/mobile-sophistication-and-strategy

 Mobile Commerce Compendium

https://econsultancy.com/reports/mobile-commerce-compendium

 SEO Best Practice – Mobile, Local and International SEO

https://econsultancy.com/reports/seo-best-practice-mobile-local-and-international-seo

 Mobile Statistics
https://econsultancy.com/reports/mobile-statistics

Econsultancy blog posts

 75+ epic mobile case studies, blog posts, stats and reports
https://econsultancy.com/blog/63786-75-epic-mobile-case-studies-blog-posts-stats-and-
reports

 12 upwardly responsive websites designed for big screens

https://econsultancy.com/blog/64700-12-upwardly-responsive-websites-designed-for-big-
screens

 16 drop-dead gorgeous examples of mobile design inspiration

https://econsultancy.com/blog/63385-16-drop-dead-gorgeous-examples-of-mobile-design-
inspiration

 20 stunning examples of minimal mobile UI design

https://econsultancy.com/blog/64170-20-stunning-examples-of-minimal-mobile-ui-design

 Google’s five questions every business should address on mobile strategy

https://econsultancy.com/blog/63589-google-s-five-questions-every-business-should-
address-on-mobile-strategy

 Mobile strategy for small businesses in three easy steps

https://econsultancy.com/blog/63421-mobile-strategy-for-small-businesses-in-three-easy-
steps

Google resources
 https://developers.google.com/webmasters/smartphone-sites/details
 http://think.withgoogle.com/databoard/
 http://www.google.co.uk/think/
 https://developers.google.com/

Mobile Web Design and Development Best Practice Guide Page 194

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Statistics
 https://www.globalwebindex.net/products/chart_of_the_day
 http://blog.flurry.com/

RWD examples
 http://mediaqueri.es/

Test your existing (mobile) web presence

 http://mobiletest.me/
 http://mobitest.akamai.com/

Mobile Web Design and Development Best Practice Guide Page 195

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
11. Acknowledgements
11.1. Lead author
The lead author and reviewer of this best practice guide is James Gurd.

James is an experienced ecommerce consultant and owner

of Digital Juggler, an ecommerce and digital marketing
consultancy. He has more than 12 years’ B2C and B2B
experience client and agency side, providing ecommerce
advice and support.

He works with a wide range of ecommerce clients helping

digital teams to create, implement and evolve digital
strategy, of which team management is a core component.

James is a guest blogger at Econsultancy and can be found

on Twitter, LinkedIn and Google+. He is also co-host of
#EcomChat, a weekly industry chat on all things
ecommerce every Monday on Twitter.

11.2. Expert contributors

Econsultancy wishes to extend sincere thanks to the following respected ecommerce and web
development professionals and agencies. Between them, they have carefully contributed to and in
some cases entirely written the section content, adding current front-line best practice tips and
insight derived from their experience in delivering and helping other teams to manage growth.

Justin Taylor, Founder & MD, Graphitas

Section written:

 Section 7 – UX/UI Design

Justin’s path into digital design and marketing has been

anything but conventional. A random selection of career
decisions saw him doing everything from designing rave
flyers, t-shirts and (although refusing to divulge his stage
name) he allegedly did a summer stint in Gt Yarmouth as
a close-up magician before settling on a career path in
design and marketing and founding Graphitas in 1998.

Justin can regularly be seen speaking at industry events,

hosting webinars and writing blogs for the likes of Moz
and net magazine.

Feel free to look him up on Twitter, LinkedIn and

Google+.

Mobile Web Design and Development Best Practice Guide Page 196

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Maria Morais, Digital Commerce Consultant, Neoworks

Sections written:

 Section 3.5 – Measurement and optimisation

 Section 3.7 – Key technical considerations
 Section 4.7.2 – Ted Baker case study

A digital commerce consultant with a deep understanding of

enterprise alignment with the pace of change: from customer
insights to product and service development.

Maria regularly leads complex assignments involving research,

data analysis, team structures, communities and business
performance, to help brands and retailers make better-
informed decisions in all areas relating to digital commerce.

Maria is a regular contributor to various industry publications

and blogs. You can follow Maria on Twitter @CeuMorais.

For more information about Neoworks visit

http://www.neoworks.com.

David Skerrett, Managing Partner, Nimbletank

Sections contributed to:

 Section 5 – Adaptive Web Design

 Section 6 – Mobile-specific Website Development
 Section 9 – Summary and Recommendations

David is an experienced marketer and has worked in

mobile for 10 years and digital for 15 years. He describes
himself as T-shaped with depth of mobile knowledge
and breadth of cross-channel marketing experience. In
his career he has won over 70 creative awards and
specialises in mobile strategy.

As Managing Partner for Nimbletank, the UK’s most

awarded mobile agency, David leads client service,
strategy, analytics, media and innovation. In doing so he
works with clients such as ASOS, Universal and the BBC
to deliver ground-breaking thinking and creative mobile
solutions.

David has a wealth of experience in activating brands in

mobile, developing high performance solutions that are
loved and used by consumers.

He is a guest blogger at Econsultancy and can be found

on Twitter, LinkedIn and Google+. He is also the voice
of Nimbletank’s Twitter feed.

Mobile Web Design and Development Best Practice Guide Page 197

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Sohaib Siddique, Technical SEO Lead, Verve Search

Section written:

 Section 8 – Technical SEO for Mobile Development

Sohaib has been working in SEO for two years, having been
promoted several times; he is now working as the Technical
SEO Lead at Verve Search.

He has a keen interest in mobile SEO and has experience

working with international brands on their mobile strategy. He
also contributed to the Econsultancy SEO Best Practice Guide
(Technical SEO chapter), released in January 2014.

In 2013 he was shortlisted for “Young Search Professional of

the Year” at the UK Search Awards.

For more information about Verve Search visit

http://www.vervesearch.com/.

Stuart McMillan, Deputy Head of Ecommerce, Schuh

Sections written:

 Section 3.1 – Defining goals and objectives

 Section 4.1 – What does ‘responsive’ mean?
 Section 4.2 – Commercial implications and challenges
 Section 4.7.1 – Schuh case study
Stuart McMillan is Deputy Head of Ecommerce for
the footwear retailer Schuh. He puts his heart and
soul into ensuring they provide the very best of
digital experiences. Puns to excess.

His back-story includes traditional retail and a

long stint as a senior web developer. He is data-
driven and customer-centric, with an eye for detail
on the fine nuances that separate great websites
from good websites.

You can find him on Twitter @mcmillanstu.

Mobile Web Design and Development Best Practice Guide Page 198

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Mark Slocock, Managing Director, GPMD Ltd

Sections written:

 Section 4.3 – Technical challenges and considerations – development and maintenance

 Section 4.5 – Pros and cons of responsive web design

Mark has been building, running and optimising

ecommerce websites for over 15 years and is Managing
Director at GPMD, a specialist ecommerce and digital
strategy provider.

When not working Mark is usually found building Lego

with is son Max and attending toy tea parties with his
daughter Eliza.

Mark attempts to blog regularly on the GPMD website

and can be found occasionally on Twitter @mslocock,
LinkedIn and Google+.

Markus Karlsson, CEO & Founder, Affino

Sections written:

 Section 5.4 – Implementation considerations (adaptive web design)

 Section 5.7 – Creating an adaptive code base

Markus is a social commerce evangelist, building

profitable commercial communities and engaging stores.
He is also the chief architect of the Affino Social
Commerce SaaS platform.

Equally Markus is a big family man, doting father of

three gorgeous children and part-time labourer for his
hillside country garden.

He’s a regular tweeter @markuskarlsson and occasional

blogger on affino.com.

For more information about Affino visit

http://www.affino.com/.

Mobile Web Design and Development Best Practice Guide Page 199

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Matthew Curry, Head of Ecommerce, LH Group

Section written:

 Section 5.3 – Technical and commercial challenges (adaptive web design)

Matt Curry is Head of Ecommerce for Lovehoney. He’s

seen things you wouldn’t believe actually exist let alone
are bought online, is not easily embarrassed and has
worked in ecommerce for over 10 years.

Previous to perverting the nation, he sold frozen food to

the elderly. He’s a statistician by trade, a perfumer by
fancy and a constant delight at parties.

You can find him on Twitter @mattycurry or LinkedIn.

Matt Bailey, Creative Director, GPMD Ltd

Section written:

 Section 4.4 – Implementation challenges (responsive web design)

Matt is an experienced front-end designer and developer –

he’s older, but less good looking than his photo would have
you believe – who enjoys making ‘stuff’ for web and
occasionally writing blog posts. You won’t often find him
using words such as ‘multichannel’, or ‘strategic fit’, but he
may let the odd ‘responsive web design’ or ‘beautiful
typography’ slip out.

When he’s not geeking out over the latest ‘in’ icon font he
can usually be found reading graphic novels, watching scary
movies and doting over his gorgeous little daughter (not all
at the same time he hastens to add).

You can chat-him-up on Twitter @_mattbailey, rip off his

excellent LinkedIn profile, or laugh at his blog writing skills.

Mobile Web Design and Development Best Practice Guide Page 200

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015
Will Garbutt, Senior UX Manager, Summit

Sections written:

 Section 3.2 – Understanding audience needs

 Section 3.3 – Device-specific patterns and behaviours
 Section 3.6 – Marketing challenges and opportunities

Will’s career in online marketing and ecommerce started

in 2006 shortly after he graduated. The love affair with all
things digital, data and design has continued at Summit
for the past four years where he has led the Summit UX
department managing wireframing, design, prototyping
and usability testing for the likes of Carpetright, ASDA
and brands from the Home Retail Group. His passion for
analytics and customer behaviour forms the basis for
Summit’s approach to user experience ensuring intuitive
and effective websites are built.

Will regularly imparts snippets of his thoughts, opinions

and ideas on the latest in the UX world on the Summit
blog summit.co.uk/blog/ and YouTube Channel
https://www.youtube.com/user/summituk.

Tomas Honz, Director of Technology Strategy, Summit

Sections written:

 Section 6.1 – What does ‘mobile-specific’ mean?

 Section 6.2 – Commercial implications and challenges
 Section 6.3 – Technical challenges

Tomas has worked for Summit for over 12 years, initially

as part of the PPC and SEO teams, before moving to the
technology and ecommerce team in 2003. He was
responsible for the launch in 2004 of the first Summit
ecommerce platform that led him to create the dedicated
technology centre for Summit in Prague that now
employs 40 people.

His ecommerce specialist skills include a deep knowledge

of the Magento platform of which Summit are a Gold
Solution partner. Tomas has been responsible for all
technology operations, solution design and delivery as
well as the strategy. He is now focused on the
blueprinting of new client solutions and keeping Summit
ahead of the competition with the integration and
utilisation of new technologies as they become available.

Throughout his time at Summit, he has worked with clients including Adidas, John Lewis,
Carpetright, Argos, Comet and ASDA.

Mobile Web Design and Development Best Practice Guide Page 201

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage
and retrieval system, without prior permission in writing from the publisher. Copyright © Econsultancy.com Ltd 2015