This is the third cross-post this week from a few articles we’ve written this year for a tech column in Marketing magazine. This one from the June issue looks at designing for mobile web versus native apps: as mobile moves to centre stage, should marketers design for every operating system and every device, or opt instead for the mobile web?
Last month’s column covered how wearable tech is likely to succeed for no other reason than it makes intuitive sense once you try it. Just as mankind ditched pocket watches en masse in the first half of the 20th century (albeit reluctantly at first: apparently your average British male stated they’d “rather wear a skirt than a wrist watch” until after WW1), it follows that we won’t carry around a smartphone when we can wear one instead and stay handsfree.
When it comes to designing for mobile however, wearable tech throws up additional demands in an already quite complex space. Designing for different operating systems on a bunch of different handsets and tablets is going to look like child’s play when wearable tech fully enters the arena. It’s going to get harder before it gets easier.
Enter the mobile web. I usually subscribe to the view that the more complex a task, the simpler the solution needs to be. Native apps increasingly dominate mobile traffic, currently delivering four times the volume of the mobile web and yet… why design separate solutions for different OS when you can have the broader applicability and lower costs of designing for the mobile web instead?
In truth, there is no one mobile solution to rule them all. So how best to navigate development choices now, with one eye on the future?
Here’s a dead simple guide to ‘what to choose, when’:
1. Native apps
If you’re designing a service or utility (task-based) app that requires real speed and you want to use the native features of the OS running on a given device, then for now your best bet is to code a native app, think Instagram.
2. Web apps
In other words, apps that live entirely online and run in a web browser tab. If you don’t need the native features associated with iOS or Android, say, and the purpose of your app is primarily information-based – to the extent it needs constant communication with the server – then you’re better off building a web app. An example of this would be Forecast http://forecast.io/, the weather app built using HTML5. No need to go to the app store, just search, download to your home screen and you’re good to go. Forecast also puts to bed any assumptions that a native app interface is de facto better. As Forecast themselves say, it’s more a question of users getting familiar with the progress that’s been made:
“It’s 2013, and mobile browser technology has advanced tremendously in the past few years: hardware accelerated transforms and animations have made it easy to create perfectly smooth, jitter-free, interfaces..”
3. Hybrid apps
In short, each of the approaches here have a role, it depends on what we’re trying to achieve. For marketers, I’d wager we default to a native app too quickly. The question to ask is “will this app provide genuine utility or entertainment that users will want to return to of their own accord in future?” If the answer is closer to “no, this is a short term campaign to promote a product launch” then let’s do everyone, including our CFOs, a favour and build a light, responsively designed web page instead.
Love this related post on cards as a design approach that solves many of the perennial issues around mobile – it’s must-read: Why Cards Are The Future of The Web, by Paul Adams @ Intercom.