The mobile revolution
A rapidly increasing part of our work here at Box UK revolves around talking with clients and clients-to-be about their mobile strategy. In the last year alone, we’ve experienced a huge uplift in interest around the mobile design & application development consultancy services we provide.
First, some numbers
Statistics about the mobile revolution keep coming in thick and fast, and the business case for catering for mobile users grows more pertinent with each day, week and month. To pick out just a few juicy stats, here’s why your organisation should care about mobile:
In the UK:
- There were over 17 million mobile internet users (45% of all UK internet users) in 2011. Just 2 years earlier in 2009 there were 8.5 million users (23%)
- Mobile results in 10% of eBay’s UK sales.
In the USA:
- 35% of the population own smartphones.
- 11% of people in 2011 visited a retailer’s site from a mobile device.
- In October 2011, 9.6% of online sales were from mobile visitors.
- From Q2 2010 – Q2 2011, global mobile data traffic doubled.
- Mobile traffic is growing faster than fixed broadband traffic and grew 4.2 times faster in 2011.
- YouTube delivers over 400 million daily video views to mobile devices (15% of their traffic).
- eBay sells a product via mobile every second on average. They expected to generate $5bn in revenue from global mobile sales alone in 2011.
- PC users reached 600 million after 20 years. Smartphones users reached 600 million in just 8 years. This is set to increase to 788 million users by 2015.
Projecting forward is proving to be particularly tricky, as the pace of change and growth is outstripping many of the industry’s previous estimates. One thing is certain; mobile is vital to your organisation’s strategy. So, how can you best take advantage of the platform?
Mobile doesn’t always mean mobile
Historically, the scenario of the typical mobile user has often been framed as someone visiting a site on their mobile device in a rush with poor reception, and they’re distracted/ multi-tasking. But is this really true? Think about your own smartphone use; is it always on the go, or are you more often than not at home on the sofa/ in bed/ sitting at a desk, focused on the task in hand?
Certainly statistics from one of the industry’s leading voices (Luke Wroblewski) shows that mobile usage is:
- “84% at home
- 80% during miscellaneous downtime throughout the day
- 76% waiting in lines of waiting for appointments
- 69% while shopping
- 64% at work
- 62% while watching TV (alt. study claims 84%)”
As the ubiquity of mobile devices & users increases, so does the variety of usage patterns, to such an extent that these devices can often be people’s favoured means of going online. If more and more people are going online via a mobile device, rather than with a traditional desktop/ laptop, then they certainly won’t tolerate a sub-standard browsing experience. Your users will expect the same quality experience (or better). How can you provide them with this?
Delivering the mobile experience your customers deserve
So what are the options for your organisation if you’re looking at developing a web site or web app that needs to cater for a mobile user base? Here’s a broad overview of the approaches, which I’ve kept purposefully succinct, and avoided getting into the technicalities ‘under the hood’.
1) Building a mobile-optimised site on a sub-domain (ie; m.yourdomain.com)
This can be very effective, and there are some high profile examples, notably m.twitter.com which accounts for 14% of their total unique users and m.facebook.com which provides 18% of new posts. In both cases, the “m.domain” site generates more traffic than any other ‘native’ app (ie; the iPhone Facebook app etc).
Some reasons to consider a mobile-optimised site:
- If you want to sell goods via the mobile site, you don’t have to pay a % to an app store vendor as you would with a native app.
- You don’t have to get approval and publish via an app store (ie; Apple’s App Store, Google Play).
- You can be confident the mobile-optimised version will perform quickly on a mobile device.
- If designed properly, the mobile-optimised site will be built around the unique contexts of your mobile users and should make task completion fast and intuitive.
- They make use of standard web technologies so your current development team (if you have one) can implement it.
- You don’t have to push updates out to users when you make changes (as you would with a ‘native’ app).
- You don’t suffer if a particular hardware of software manufacturer performs poorly and loses market penetration.
Some drawbacks with building a mobile-optimised site:
- You can’t access all of the smartphone’s features (ie; you can’t make use of the GPS, phone contact list, video & audio capabilities etc).
- You’d have to manage two lots of content, for the desktop and mobile versions of the site.
- Your developers & designers would have to manage two lots of code & assets.
- It’s relatively expensive & time consuming to maintain both sets of content & code.
2) Building a native mobile app (ie; an iPhone app)
For most smartphone users, native apps are well understood, and one of the first things that many new users do is start to download and play with the native apps on their smartphone (research shows that 51% of users use a few apps once a week, whilst only 17% don’t use apps regularly).
From your organisation’s point of view, are they worth investing in? Certainly a native app enjoys some unique benefits currently:
- You can charge for the app and for any in-app purchases. Indeed, 72% of Apple’s app store revenue in summer 2011 was from in-app purchases, not from the initial app purchases (of these in-app purchases, 48% were made from freemium apps that are free of charge initially, with a premium charged for advanced features).
- You can make use of the smartphone’s hardware features such as GPS, camera, microphone, compass, gyroscope etc…
- The native app would be built specifically for that platform, resulting in optimal speed and performance (which is vital for game-based apps).
- You can build different apps that serve very specific tasks for your users (ie; eBay have a suite of apps: http://mobile.ebay.com/iphone/ebay)
The downsides of choosing native apps for your organisation include:
- Each different platform (ie: iOS, Android, Windows Phone 7 etc) requires bespoke development, which could get costly.
- Third-party approval is required before the app is available in each of the app stores.
- App store vendors can take a cut on any app store purchases (ie; Apple takes 30% of in-app purchase revenue).
Even with a native app, your users might try to visit your organisation’s site on their mobile device, so its mobile usability may still need to be considered.
3) Build the app/ site responsively to be accessible for all devices
One approach that is steadily increasing in popularity, viability and visibility is building sites and apps to be device-agnostic. Rather than maintaining separate versions on the site (as in option 1) or building for a specific vendor using their native technologies (as in option 2), this option works on the premise that the site adapts responsively based on the user’s browsing context.
This means that if a user visits your organisation’s site on a large desktop browser, then looks at home on their tablet, or shows it to a colleague on their smartphone, your site would respond accordingly. One of the more recent high-profile examples of this has been the The Boston Globe newspaper. The site adapts responsively to the dimensions of the browser, ensuring the user is presented with a consistent user experience. (Try it with this great little tool that allows you to mimic common device types: http://responsive.is/bostonglobe.com).
So what are the benefits of taking this device-agnostic/ responsive approach?
- You only have to manage a single content repository.
- The content is tailored to a user’s device (mobile or otherwise)
- It provides a consistent user experience for your users.
- It future-proofs your organisation.
On the downside:
- It can take longer to develop with this approach, as it can be a more complex process.
- Some of the technologies involved are relatively new, so some older mobile and desktop browsers (ie; IE8) don’t fully support the new approach.
For a more detailed look at how we tackle responsive projects, you can read this blog post on our first responsive project built on top of Amaxus.
4) All or some of the above
An important addition to the 3 listed approaches above is that it doesn’t have to be option 1, 2 or 3. You can mix your approaches dependent upon your organisation’s needs. Maybe you want a responsive site to provide a consistent user experience for browsers, but you also want a native app as you need to make use of the phone’s video and microphone for a specific task. Maybe you want a responsive site, but from your analytics data you know 60% of your traffic is coming from mobiles. Therefore you need to build the site using a ‘mobile first’ approach, which caters for mobile users first, with desktop users of secondary concern.
Deciding what’s right for your organisation
As is always the case, context drives everything. Only you know who your users are, what times of day they browse your site and what devices they browse from. You probably also know which are the most popular areas of your site, what the most frequent tasks are, and where the bottlenecks occur.
Armed with this user data and your organisational insights, we can advise you on the most effective mobile strategy for your company. Whether you need a mobile optimised site, a native app, or a responsively designed site, one fact is known: mobile users are growing quickly and sooner than we can predict, they’ll become the predominant user type. The question is: how prepared is your organisation?
Get in touch
Find out more about our User Experience Consultancy and Mobile Development offering on our Products & Services page, or get in touch so that we can help you identify the best solution for your organisation.
We’ve also just launched our first responsive site on our Amaxus CMS. You can view it here: