June 03, 2011 - Comments Off on The many pointless arguments over Mobile development
The many pointless arguments over Mobile development
It seems like every day, someone tweets a link explaining what the ‘best’ method of implementing mobile content is. It’s an App. It’s a Progressively Enhancing, Gracefully Degrading standalone mobile website. It’s WAP. Ok, not WAP, but some combination or variation of the former.
If you tried to debate the relevant merits of one method vs another method amongst a group of developers, you could spawn a pretty enjoyable argument. But, as fun as dev-baiting might be, you’re very probably missing the point – context is KING, and that in reality there are arguments for and against each different approach depending on the development scenario.
Here comes the mandatory analogy. When you’re buying a car, there is no best option. There are only options that make sense. A giant 4×4 doesn’t make sense for the school run, unless you live in Kensington. Neither does a Ferrari, unless your kid goes to school in Monaco. Similarly, a Mini makes less sense if you live up a snow covered mountain, in a shack at the end of an un-surfaced dirt track, like I assume Bear Grylls does.
Here are some examples of different solutions, and why/when they work:
1. Do Nothing
Pros: Modern Smartphone browsers are pretty impressive at rendering full fat websites – and getting better all the time. If you have no money, or time, or inclination to build a mobile website, you can at least be pretty confident that your site will be viewable by the top two – iPhones and Android.
Pros: No matter how advanced mobile web technologies are these days, I doubt anyone would seriously argue against Apps for usability. Good Apps are developed from the ground up to take the fullest advantage of the smartphone’s interface. They’re small, quick (usually), simple to install, and they usually provide an extremely focused set of functionality. They usually provide at least some level of functionality when you’re offline –and they provide access to all the gadgets and functions of your phone. This is one reason why Apps have proved the most fruitful market for innovation – it’s easy to mash together different device features in an infinite number of ways. That, and the fact that you cancharge for them.
Cons: Does your mobile site really need that level of device integration? If not, you’re going to be stuck making 2 or 3 versions of the same functionality, all slightly different, and fighting to promote them amongst another 350k others. Even if you use a Hybrid App framework, your developer resource will need new skills. Users are also not going to be searching for your Apps on Google – unless you have a desktop or mobile website to promote them with. Apps, because of size and development constraints, usually don’t doeverything your desktop site does – but then users probably don’t expect then to.
3. Mobile Websites
Pros: If you already have a website, you’re on familiar ground – you probably have a hosting infrastructure you can use, plus your developer resource already has 95% applicable skills. You’ll likely only need 1 mobile website, plus customisations for any specific devices you want to target – a decision ideally based on real stats about what people use to access your existing site, not what a website tells you is most popular today (because they ALL disagree.) Your site can be promoted through Google, you can link to it… and if it’s built intelligently, every device including your Nan’s Sony Ericsson will be able to display something.
Cons: Mobile Websites have to be designed well from the ground up, to come close to the usability of Apps. Leading edge mobile sites like mobile.twitter.com show how much progress has been made in this area – at least on Android devices they are almost indistinguishable from TweetDeck. But unless you undertake that level of (re)design (see below), you’re unlikely to get that high quality an experience. You’re unlikely to be charging for access to your mobile website as the micro-payment model that works for Apps, generally horrifies mobile site users.
4. Which types of Mobile Website do you need?
If you’ve decided to build a mobile website, the decision process isn’t over. There are a number of different ways of doing this, all of which offer different levels of design and/or functional compromise – balanced with and increase or decrease in build and maintenance complexity:
One Site – you might choose to give your existing website a fluid layout makeover (or build one from scratch.) You can design the site to start off simple, and become more complicated based on which device is accessing it, and what it can support (progressive enhancement.) Or, you can design a ‘full fat’ website, that breaks back down to a simple one (in a managed way), for devices with less support (graceful degredation.) OR… you might choose to target a popular size of screen – iPhone 4 for example – targeting the best mobile experience for that screen size, and then enhancing/degrading for everyone else. Although it might sound like a lot of work (and it can be), you only end up maintaining one site at the end of it.
Downside is that although you have some design options for your desktop and mobile variations, there will be an inevitable compromise. You’re also almost certainly not going to be able to provide much difference in functionality between the two versions. Worst of all in some ways, you’re not driven to consider why and where a mobile user is accessing your site, which might be for totally different reasons – no consideration, no new user journeys. Plus – you’ll need to do some serious work to get this site to load as fast as a standalone mobile version.
One set of content, two templates – if you have a ‘slot based’ CMS, you can limit the need for design compromise by pushing the same content to two totally different templates. Your desktop version can look as sparkly as you want, or at least as sparkly as it ever did, while your mobile version can be as responsive and fluid as you fancy. You can still use progressive enhancement/graceful degradation to target a specific viewport, and you have more choice on where that target is (though as mentioned about, that should really be based on stats rather than blog preferences.) You also get the choice (if your CMS is clever enough) to have single OR double URL structure – though pushing the same content to two different pages has an SEO impact you need to handle. Finally, it’s likely to run much faster than a single site version, once the decision has been made on which template to serve.
What you’re doing in the scenario, is saving data entry time by only needing to add content once, and reducing design compromise – but it has a price. You’re going to need two sets of templates, which means double the design, development, support etc. Also, you’re still unlikely to be able to make the mobile site do something completely different to the desktop version – which means that even if you consider why and where your mobile using is accessing the site, you are restricted in your response to that, outside of slightly altering your user journeys.
Two sites – this is by far the approach with the least compromise, both in design and in functionality. You can literally design two sites that do completely different things, in entirely different ways. You can consider the mobile user journeys, the why’s and where’s of you mobile user, and design entirely for them. This is also the easiest route to a mobile website that looks something like an App. AND, you can still target a specific screen size or device using enhancement/degradation, or simply build from your preferred starting point – top down, bottom up, or some arbitrary middle point.
This approach really IS the most flexible, but it is double EVERYTHING. It’s two sites to design, build, support, populate, tweak etc. There’s no way you can avoid this approach being more expensive in either time or money.
So… that’s a cross section of some of the different approaches to the same requirement – getting content to mobile users. I’m certain that’s not ALL the possible approaches – I’m certain some people may argue with my arguments for and against the different approaches. If you do… great, the point I’m trying to make is that (like buying a car) there is no obvious ‘best’, only a best suited for a given scenario.
It should be noted that my previous cars include the salmon pink Fiat Seicento pictured, therefore I may not be qualified to use the car analogy above.