Just 4 ways to approach Going Mobile – simpler than you think

You can’t fail to have noticed to big hoo-ha about mobile websites; from 1% adoption in 2011 to being on 95% of organisations’ radar in Q2 of 2013. It seems the business world has suddenly woken up to need to go mobile, but how many marketers really understand whats involved and how to go mobile?

What are your choices?

The great thing about this question is there are only 4 options in total and, in reality, only 1 way to do it correctly:

  • Responsive framework;
  • Dynamically serving content;
  • Separate mobile site or;
  • Do nothing

I’m going to ignore the “do nothing” option in this post, although there is an argument that doing nothing now is better than doing it badly now. If you implement mobile badly then you’ll get poor performance and run the risk of a self-fulfilling loop whereby crummy performance is viewed by the budget-holders as not worthy of investment.

The first 3 approaches are commonly used to deal with multiple device support and each of them, typically, allows the delivery of custom content and layout based on the user’s device. You must consider the user in each of the scenarios and deliver a great user experience otherwise you’ll run foul of Google’s guidelines and, worse still, have sub-optimal performance.

Responsive Framework:

Implementing a Responsive Framework around responsive design enables you to tailor your website experience across different screen sizes without creating multiple websites. This is the dream solution as the single entity solution has a number of major benefits over the alternatives:

  • Easier to maintain: All content is in a single repository so changes only get made once and roll-out across all devices.
  • Consistent journey across devices: 90% of people move between devices to accomplish a goal. A single entity ensures the messaging, content, calls to action and the like are consistent across all devices, whether that’s on smartphones, PCs, tablets or TV
  • Better search positions: Google and the other search engines find it easier to trawl a site that has a single URL for a given piece of content.
  • Sharing that works: when URL links on a responsive site are shared between folks, the content at the URL is rendered in the style of the recipient and not constrained to the type of device used by the sharer.
  • No website redirection is needed for users to get to the device-optimised view, which can reduce load time

Responsive works by using flexible templates, simple CSS media queries, and some JavaScript elements so that the website can respond to the size and orientation of a device. Images, layout and content are automatically adjusted on the fly so the user always gets the best experience available. Furthermore, newer capabilities such as touch, dragging, swiping and other gestures can be baked-in to the design.

There is not much in the way of downsides for using responsive frameworks, but worthy of mention is load-time. The very essence of responsive is for each device to load all the code required for all devices and configurations and if not carefully managed this could place a greater burden on the communication speed than some other solutions, most notably a dedicated mobile site.

Dynamically serving content

When a user hits your website, its possible for the webserver to detect what kind of device is visiting and present custom content. These custom pages can and need to be designed for all kinds of device. The solution is a little trickier to deliver and you have to be careful of not running foul of Google’s best practices with regards the content served.

This solution requires you to maintain multiple content repositories, typically one repository per device. This has some upsides as you could have greater control over the content served to a specific mobile device (i.e. an iPhone) and then present device-specific content, such as “download our App at the app store”. Multiple repositories have a number of challenges; keeping the content in sync, slower delivery of changes and greater resource required to host, deliver and administer.

Separate mobile URLs

This is how the mobile world started, back in 2007. The browser detects if the user is on a mobile device and redirects them to the mobile-optimised version of your site. You will recognise these as m.xxxx.com websites and allows you to tailor the site specifically for mobile users. Frequently the mobile site is completely independent of the main site, looks and feels very different and is normally a good deal simpler.

The benefit over dynamically-serving content is that all mobile devices get to see a single version so you only have to manage two repositories rather than many. The downside is that the experience is rarely as rich and often looks so different that it’s difficult to move between devices with any kind of flow.

This is often the easiest route as a number of SaaS suppliers (try Dudamobile or GinWiz) provide services off the shelf for a few pounds to achieve this. Don’t expect miracles but it may be worse than nothing and has the benefit of being low cost in the short-term.

What does the industry say?

Most folks agree that responsive is the preferred way to go; in fact it’s the only framework that was created for this end, the others are simply non-standard solutions to an ordinary problem. Most folks look to Google to lead the way and when they went mobile-first back in 2010 they led the charge, set the standards and, largely, dictated the pace. Google states quite categorically that responsive web design is its recommended mobile solution, and even goes so far as to refer to responsive web design as the industry best practice. We agree.

You can ignore us … but it would be a brave call to decide against Google. Contact me if you want anymore information or help on the subject. We went mobile-first in May 2010 and since then we’ve published quite a few articles that you can see here. Deciding to go responsive is only the first step, there will be challenges along the way and we can help; this is our specialist space.

By Martin Dower