Author Archives: Craig

Introduction to responsive Vs mobile specific


Website owners are seeing a dramatic increase in mobile traffic to their websites. This traffic is fragmented amongst hundreds of devices, each with varying capabilities and constraints. Considering this trend, diversity and fragmentation will increase exponentially.

To cater for this increase in traffic and fragmentation, website owners should be looking to establish an approach to deal with mobile and multi device users.

The concept of fragmentation, capabilities and constraints is important when considering mobile traffic. Mobile is not just a few extra OS (eg Apple and Android) on your stats; you are likely to see hundreds if not thousands of devices each with varying capabilities and constraints.

Two approaches tend to be shortlisted; responsive design and mobile specific design.

Here are some of my thoughts on why responsive is often the better choice over a separate mobile website. It’s not nearly exhaustive enough, just easier to post here than a forum reply. There are many awesome resources online about mobile design and development. I’ll signpost to some throughout this blog, so you can make up your own mind.

What is responsive design

Responsive design is the process of building one website, with one set of content, that adapts to whichever viewport (browser window) displays it. The building blocks of responsive are fluid dimensions (allowing presentations to stretch in width), CSS media queries (allowing adaptive layouts at set breakpoints) and optimised content.

The primary focus is the content, not the device. Responsive web design supports the idea of One Web.

What is mobile specific (.mobi / m.)

Mobile specific design is the concept of building an additional website often with trimmed down content, designed specifically for mobile devices. The building blocks of mobile specific are device detection (allowing the server to redirect to a different site), different URL structure (commonly m. or .mobi) and trimmed down content specifically for “small” screen.

The primary focus is the device, not the content. Mobile specific contradicts one web.


The content problem

User testing consistently highlights a common problem on websites to be either too much or irrelevant content. This problem must be tackled at the root. Regardless which device accesses the website, the content should be succinct and potent. Creating a stripped down, mobile version of a journey does not solve the problem.

Why would we deliver an optimised experience to a mobile device and an un-optimised experience to the desktop user? Too often, marketing departments fill an empty space with rubbish. By letting go of 1024 fixed layouts and “canvas”, website owners are forced to look at the real architecture of content and how it all hangs together. Website owners must think about how to design the content, not how to design for specific devices.

Mobile specific design would be like sticking a plaster over the problem by by not addressing it directly.

Responsive design would tackle the problem at the root, forcing the website owner to look at their content regardless of style or layout.


There’s been an increase in the number of users who use only a mobile to access the web. To them, web is not “mobile”; web is one place for information.

It is technically impossible to ascertain the context in which a mobile device is being used. Surveys show 93% of mobiles are used in the home. This disproves the myth that small devices are always on the move.

Any decision we make to send location based content or “light touch” information would be based on outdated and dangerous assumptions. Users accessing the website on mobile or desktop could want the same content.

Mobile specific would restrict the content experience to the users.

Responsive design would grant users the full content experience, regardless of context.


The maintenance of one codebase is easier to manage than two. Development time and costs are lower with one codebase than two. There is little benefit of running two codebases on separate URL structures. Website owners who own a relationship with a third party supplier may find themselves managing many relationships across many platforms and skillsets.

Responsive design forces designers, developers and managers to rethink the way they plan and consider content. This may require learning and education work at kickoff, but once that corner is turned the design workflow almost normalises to that of maintaining a single website.

Mobile specific has two codebases.

Responsive design allows for one codebase.

URL Structure

A clean, tidy and logical URL structure is important to a website not just for SEO and maintenance, but also for sharing.

If a two tier URL structure is in place it’s possible that a desktop, tablet or TV user could click on a mobile specific URL on a larger device and be trapped in an un-optimised experience. Take Twitter for example; on a mobile device, a mobile specific website would be shared as rather than Remember, assuming context is dangerous.

Responsive allows for one URL structure, encouraging the concept of one web and net neutrality.


Google recommends responsive design as its preferred approach to mobile.

Bing recommends responsive design as its preferred approach to mobile.

Future Proof and scalability

The future is unknown. Website owners should expect lots of diversity in the fragmentation of devices that access their website. With an increase in the number of devices, it is important to choose a flexible and future proof approach to these devices.

With more and more devices (and possibly more platforms), website owners have to let go of the idea that we once built for 5 browsers. Testing on every device is impossible, so practicing good web standards, semantic markup and basic progressive enhancement is more important than ever.

It is much more efficient to build one flexible, adaptable website than try to manage redirections for new channels as they appear. This approach should be device agnostic, and focus on semantic flexible content easily accessed on one web.

Responsive design is an obvious candidate for future proofing.

Although it’s often spoken about in the context of mobile and tablet, responsive web design and CSS media queries can be used at larger breakpoints as well as small. This allows for layout changes on new internet media such as television and large screen.


In the long run, anticipating and planning a responsive piece of work is no more resource intense than supporting the same two tier mobile / desktop system. In the short term, there is a learning curve as people start to embrace the technique.

It could be argued that it’s quicker to implement a separate mobile site, as the work can happen on a separate track to the main site development, but considering the long term goals and two tier implications this is a short term benefit.

What about page weight? Isn’t responsive inefficient?

Nine times out of ten page weight is likely to be lighter on a mobile specific build. Less content means less page weight. Assuming the device is a mobile means you can send down optimised assets such as JavaScript and images.

By default, that doesn’t mean responsive a a lot heavier. Website owners implementing a responsive build should do so with a content / mobile first approach with careful consideration of file sizes. The vast majority of responsive sites that are heavy in page weight are simply done wrong. Careful consideration has to be made around optimising the assets, content, http requests… By following this practice (as should be done with any website build) you make the responsive site as light and quick as it can be on mobile, and on desktop it just performs even faster.

Can responsive and device detection live in harmony?

Kind of. Responsive and server side components (RESS) is a model being adopted by many advocates of responsive which is a hybrid of responsive techniques and server side detection. It’s more about capabilities and constraints and catering for what that device can handle, based on what you know about that device. For example the templates and content would remain the same, but we could switch out an image path to deliver hi-res, heavier images if we’re certain the device is capable of comfortably handling it.

In my opinion, RESS offers the most hope for a solid universal multi device solution for the future.


The landscape has changed very quickly in the past year, and looks set to continue into the fragmented unknown for the foreseeable future. By choosing responsive, website owners are building a flexible foundation which is the most logical for scaling and building on for months and years to come.

Responsive is future proof, saves time and resource in the long run, is favoured by Google and Bing, provides a multi device solution (both small and large screen) and allows us to focus on the single most important element of the site that converses with users: the content.

So that’s my brain dump, which I’d like to tidy up some day to make it more joined up. Particularly around the key considerations for any good website:

A responsive process is a responsible process

Introduction: the responsive design process

Notes from Steve Fishers talk on responsive design process, at the Future of Web Design 2012 conference. Four key takeaways:

  • the web is not fixed width
  • mobile is not a rushed context
  • clarify the why
  • discover, design, develop, deploy.

The web is not fixed width

The web is not fixed width. That's not to say don't use fixed sizes, just remember that the medium isn't fixed. Even the iPhone for example; you may think you're working with 320px, but change the orientation and you've just changed width.

Mobile is not a rushed context

Mobile is not a rushed context. Assumptions can't be made about user intentions or location. There's no denying we see less on a smaller screen. So what? Everyone still needs to access all the information.

Clarify the why

The golden circle is an approach that will drive a designer or developer to deliver higher quality, robust and innovative solutions over and over. The golden circle has three parts:

  • How
  • What
  • Why

It doesn't matter what you do, it matters why you do it. Everyone knows the what. Most people know the how1. Not a lot of people know the why…

If you can concentrate on working out the why, you'll be a lot more successful in the what and how. The why is the question. The design is the answer.

Apple are a classic example of this. People are so absorbed in why they do what they do, they are happy to pay Apple prices.

1I love this way of thinking but it got me thinking… Do most people attempting responsive know the why, but not the how or what? AKA, they acknowledge the multi device issue but struggle with optimised implimentations?

The responsive design process

Steve went into some detail about the 4 stages of his responsive design process:

  1. Discover
  2. Design
  3. Develop
  4. Deploy


Kickoff and project charter

Get to know your client and let them get to know you. Be fully informed. It's so important to understand who you are working with. If someone's not been involved at the kickoff, question their right to chime in with input at a later stage.

Project analysis

What are the business needs, personas, audience profiles? Get to know them.

IA and content strategy

Audit existing content for quality and quantity. Does your content do what it needs to do? Set about gathering content, use sitemaps to ensure you've got everything accounted for.

Search strategy

Look at page structures, URL naming conventions, meta data requirements, hierarchy. Everything you need to consider when building for an SEO'd site.

Strategic direction

All the info found in the discovery phase should now be brought together in one document, to be thought of like a project map. This should cover search, content, technical and creative strategies. This is the point when the full budget and scope should be set. This moment helps define the project. It prevents people coming in with a solution first; telling you what needs built, then constantly changing the requirements on the fly. Stakeholders shouldn't be coming in suggesting solutions. Problems should be discussed together.


Note: it is only now that we look at the design phase. Look at all that planning that came first. Remember that, next time someone asks you for a mockup. It should also be noted don't worry about your toolkit (the actual quote was more like tools are bullshit). Use whatever tools suit you.

UX Sketches

Iterative process to create rough wireframes. It's fine to use paper sketches, but get into the browser quickly.

Page tables

Key to keeping content separate from presentation, page tables identify each content area in order of importance, with the most important messages to be conveyed in each content area. Content should never be dependant on layout to work effectively.

This is the why. This message is what informs the design. Stories are data with a soul. Data should be well structured, in manageable chunks.

Interaction design

In-browser prototyping. This stage allows for easy demonstration of what happens at set breakpoints.

Visual design

Branding, colour, typography, everything that's required for look and feel. Up to you if you choose PSDs or browser prototypes.

Styleguide and documentation

Styleguide that documents the design system as a reference, so the elements can be correctly implemented. Could take the form of a live, annotated prototype, even with code snippets if necessary.



It's down to business. You've got all the strategy, content, design and assets together, now you have to build it on HTML pages ready for testing. This is where your web standards come into play. Steve actually had this section down as "theme build" but I thought templating was a more appropriate heading.

CMS build

Your theme / template has to be ported onto a CMS, probably including the creation of lots of mini page modules.

Browser and device testing

Cross-browser / cross-device testing to check you're providing a coherent experience to many devices. Remember, not all browsers render HTML and CSS the same. This is OK. It's not about making it look near identical in every browser, it's about creating accessible journeys on all devices.


Content migration

A website without content is a black hole of sadness. Define the scope of the content migration phase depending on the discovery / audit phases.

User acceptance testing

UAT helps confirm the objectives and requirements defined early in the project. It's like moving into a new house; this is the learning how everything works and getting comfortable with living here.

Documentation and training

Document things. Share processes. Understand how things will live in the system and write it down. Essentially a potential handover. Document all markup as well as admin functions.

Launch plan and release

Archive current website. Prepare new website for release. One last quality checklist. Go through a publication checklist, check meta data and title tags etc. Set up all analytics.

Start of operational plan

For many people the website would be alive in some form for a while now, but only now does the website really come to life on its own.

A responsive process is a responsible process

Responsive techniques can be tricky, but if we approach it content first the whole design can be simpler than what we're used to. Responsive is all about the content. It's about rethinking content creation, and getting unification from fragmentation.

The first website ever built is fluid, because the web has always been fluid. Make things easy for future devices, and accessible to all. Create once, publish everywhere. A responsive process is a responsible process.

Developing government web accessibility guidelines

How User Vision built a web accessibility culture in Abu Dhabi

Last night I attended the Scottish Usability Professionals Association monthly seminar for a keynote by Chris Rourke of User Vision, on "Developing government web accessibility guidelines and a web accessibility culture." Having recently authored a web standards document which focused on web accessibility, I was keen to learn of their process and identify parallels and pitfalls in both our approaches.

The presentation centred around a project undertaken by User Vision for the Abu Dhabi government in the Middle East, who were keen to improve the accessibility standards of government websites across the estate. Accessibility standards were identified as poor to average at best, with varying levels of understanding of what web accessibility is.

Part of the increase in awareness and interest in accessibility could be attributed to the UN Convention on the Rights of Persons with Disabilities which Chris cited as a driver for the Abu Dhabi government to take action.

Six phased approach

User Vision split the project into six phases to establish the accessibility guidelines:

  1. kickoff and background info
  2. develop the guidelines blueprint – high level outline based on proven better practice, existing international standards and needs of major disability groups
  3. identify the baseline of current landscape
  4. development of guidelines
  5. implementation and support materials
  6. evaluation of sites and development plan.

During the development of the guidelines blueprint, it was noted that existing international standards (eg WCAG2) would be difficult to understand in their natural form. Whilst these guidelines are excellent in their own way, the concept and explanations around "Perceivable Operable Understandable and Robust" are tricky enough for English speaking accessibility consultants in the West, nevermind translated to Arabic for an audience new to accessibility. It was decided to develop an easy to understand guide at two conformance levels: mandatory and optional. These guidelines would be ordered by element type (images, colour, navigation, forms, tables, audio, video etc) and more aligned to the technical reference of WCAG1.

For implementation and support two key documents were delivered: a Technical Implementation Guide and How to Assess Accessibility Guide. The former would detail the hows and whys of implementing HTML, CSS, JS and related front end presentations whilst the latter explained how to measure how accessible a website is.

As well as the government website estate, supplier agency skills were also evaluated though a series of site audits (were their sites accessible? did they have an accessibility policy?), questionnaires, and face to face interviews. The approach and attitude to accessibility were recorded and reported back to the government with ratings that would eventually make up an approved supplier list for future developments.

With the hows explained, we took a look at why a whole region should have such a poor history of accessibility.

Understanding the accessibility ecosystem: East and West

The accessibility ecosystem is made up of 3 parts:

  • people with disabilities
  • companies, service providers and government bodies
  • suppliers.

Each part brings it's own difficulties in understanding the market. For example, because many families take care of their disabled relatives in some extent of secrecy, it is very difficult to obtain accurate stats on numbers of disabled members in society. Perceptions of disabled people have only been changing in recent years.

…people with disabilities in this region still face obstacles in being included in society alongside people without disabilities.

World Bank on disability in the Middle East and North Africa

This is in stark contrast to the West where you have a tradition of activism amongst the disabled communities. It's been over 20 years since the ADA was passed in the USA.

Companies and service providers may be ill equipped to cope with new requirements due to a lack of exposure in an accessible culture with local legislation. In a region with no laws to govern the accessibility of a website, what consequences are there to not following requirements? Contrast this with the West, where suppliers may face scrutiny from pressure groups such as the RNIB or legal action such as that taken against the Sydney Olympics website in July 2000 (A Cautionary Tale of Inaccessibility: Sydney Olympics Website).

In the West government bodies would come under pressure if particular groups were discriminated against. In a democracy, you'd be voted out. If there's no democracy, not much is going to come of not complying.


It's fantastic news that the Abu Dhabi government are taking steps to improve accessibility in the region through its own websites. The realisation that a lot of sites in the East are inaccessible is just an observation, not a criticism. Having a plan in place to tackle the issues is the first step to creating an accessible culture.

Financial services on the RNIB radar


The RNIB are a charity who give advice and support to blind and partially sighted population in the UK. They’re vocal campaigners of equal rights for everyone regardless of visual ability and have launched numerous legal actions against companies with non compliant websites in terms of the Equality Act 2010. The most recent example of this was serving legal proceedings on bmibaby in January.

Financial services

They’ve had a keen interest in financial services for years, but in late 2011 reported banks were failing blind customers, and more recently launched the Talking Cash Machine campaign aimed at making ATMs accessible to the blind.

Their interest in banks looks to be stepping up, with the launch of The Banking Experience this Monday 23rd April. This event will launch the attached document which is a best practice guide for building a more inclusive experience for all customers.

Why is this relevant to our interests?

Aside from the obvious moral responsibilities (corporate social responsibility), there are legal implications of not complying with the Equality Act, which the RNIB are happy to point out very publicly via the press and legal challenges.

Number one in the RNIB ten point checklist is “train your staff.” We all need to be aware about the impact of inaccessible solutions, first to the customer and second to our reputation.