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 during the first half of the 20th century (albeit reluctantly at first: apparently the average British man stated that he would "rather wear a skirt than a wristwatch" until after World War I), it follows that we won't continue to carry around a smartphone when we can wear one instead and stay hands-free.
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 will 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 each 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 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 that it needs constant communication with the server - you're better off building a web app. An example is Forecast, 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 says, it's more a question of users getting familiar with the progress that's been made: "Mobile browser technology has advanced tremendously: hardware-accelerated transforms and animations have made it easy to create smooth, jitter-free, interfaces."
3. Hybrid apps
A native app, but built using HTML, CSS and Javascript. This speeds up the development process and makes it easier to publish across platforms, but there can be compromises in styling and performance. Netflix is a good example: using the same code base for its user interface on all devices allows it to change the interface or conduct testing at will (while video streaming is done within the native layer, so it feels fast and "native-like").
Each of these approaches has 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 in future?" If the answer is closer to "No, this is a short-term campaign to promote a launch", then let's do everyone, including our CFOs, a favour and build a light, responsively designed web page instead.
Mel Exon is managing partner and co-founder of BBH Labs