Yesterday, I wrote about what's special about the web. Today, I'm exploring what mobile and desktop operating systems do better - leading up to how the two platforms complement, and can mutually reinforce, each other.
So, what are the strengths of native application platforms? Which makes them valuable and compelling?
- Native applications are enhancers of your device - people who have been working with computers all their life forget how magical this is. You have a gadget (laptop, phone, whatever) that you've already bought -- then you put this application on it, and suddenly it does something completely new. This can feel GREAT - and that emotional satisfaction is part of the experience.
- Native applications are fully-installed, and more or less guaranteed to work, regardless of your network situation. Unless the app is completely dependent on a network service, of course. The manual-update cycle imposed by iOS is a pain and one that will probably be addressed in a future release.
- Native applications use your device to its fullest. A good application quietly maximizes its use of your CPU, GPU, storage, network, camera, GPS, accelerometer... the list goes on. You feel clever for having a device that has all these capabilities, and clever for finding an application that makes elegant, useful, or fun use of them.
- Native applications have access to a richer set of interactions with you. They can push notifications, present dialog boxes, run background services, read your contacts, and more. The why of this one is subtle -- there is no direct technical impediment to these APIs being displayed from the web, but there is a very practical reason why they are only available to native apps: the implementors of web browser runtimes haven't agreed on them, and haven't become comfortable with making them available.
- This touches on an important point of difference between the web and native: native apps live, almost entirely, in a world of vendor-controlled distribution. This means, among other things, that vendors can be more comfortable with exposing APIs to apps, because they have more ways to be confident that the app hasn't been changed maliciously out from under them (see my earlier post about apps and signed code). When web apps are under the control of a vendor (see Chrome, Mozilla add-ons, Firefox OS) this problem tends to disappear.
- Native applications live in a world of brand-, category- and keyword-based distribution. To find an app on The iTunes store, Google Play, or Windows Marketplace, you either browse a category, look for a specific title or brand, or investigate a keyword that leads to your app. This is great if the user knows to look for your app - but it can be a real problem if the user has no idea that your app exists. Native apps are weak at content-based discovery -- there's no way to find a great medical-and-personal-health app by searching for "post-ACL-surgery recovery". And, outside of the work that Facebook is doing with App Center, they have weak social discovery.
And - as an aside - I'll note that all of these advantages apply to HTML5 apps that are installed in Firefox OS. Not an accident, that.
So, what do these differences mean, for those of us who are in the business of providing compelling user experiences and services?
1. You want an installed app, because it gives you consistent organic interactions and permission to engage with the user's device.
If you are installed on the user's device, you have permission to do great stuff. So do it. Earn that place on their home screen.
You have access to notification APIs - so when there is high quality new stuff, let them know. You have the in-app payment API - think about how you can make the user's life easier, and change your business model, with it. You know what time it is, where the user is, and what they did the last five times they ran your app. On some platforms you can read the ambient light sensor, detect facial proximity, orientation, and acceleration. You can download assets in the background, save whatever you want to local storage, save screenshots to the photo stream, sync data through iCloud or gDrive, register as a document-type handler... get creative.
Remember, too, that when the user touches your icon, you are being handed user intent. The user wants to interact with your app - they have a specific goal in mind, and probably a very short time in which they want to achieve it. Maximize your understanding of that user intent, and shorten the distance from intent-to-satisfaction.
2. You need a web app, because new users will encounter you there.
Do not assume that this means you need a feature-complete app that runs in every browser!
Instead, design your web app to address three groups of users:
- People on a device you support, who don't have your app installed yet. If they want to see content, show it to them, beautifully. Then you have a brief window in which to try to convince them to install.
- People on an unsupported device. If you don't care about them, let them down gently and let them get on with their lives. If you have content they'd like to see, present it beautifully in their browser.
- Current users on a device you support, who ended up on the web somehow. Help them figure out what just happened, and get them back to engagement with your app.
What this does not mean is putting a giant interstitial ad for your app in front of your web content! If the value of your application is largely in content (rather than device interactions), then there is a very, very good chance that the user came to your web site out of explicit desire to see the content. Putting anything in front of that content will only cause user rage.
Rather, make use of intention cues that are present in the web interaction to make the user happy, and then pitch your installed app. This doesn't have to be complicated - you can use the Referrer header to tell if the user just arrived from a search engine, for example. And if the user arrived from a search - satisfy the search first!
If the user is landing on a user-generated content page, especially if they're landing from a social referral, make the author look great. That's why they shared this content - they want to amuse, impress, or affect the viewer. Make it happen. Then explain to the viewer that they can make an artifact that's just like this, too. Instagram executed this strategy brilliantly - but it is relevant across all forms of user-generated content.
If the user is arriving because of a directed engagement push - an email reminder, for example - remind them of the value of your installed application. If you have something new in your app, let them know right away. If their content has been popular, or triggered interactions, let them know about that right away too!
If your app is about an experience - a game, a camera, a contact list manager - use modern web features to show them how great it is. Embed a taste of your experience in the web, streamed directly into their browser, so they can try it out.
3. When users engage with your app - especially organically - you should generate artifacts that will drive engagement, and re-engagement
When the user interacts with your app, he or she is making something. It could be posts, reviews, and recommendations - or maybe just high scores and best times. But there is data there, which you should use to improve your experience, and help new users find you.
The single most obvious thing to do is to help users share their experiences in a way that leads new users to discover and install your app. This sounds simple, but it is amazing how few apps really get it right. Adam Nash's great posts on user acquisition are hugely helpful for understanding this - if you haven't read them already, you must: The Five Sources of Traffic, Viral Factor Basics, and Mobile Applications and the Mobile Web.
Remember, too, that you have an opportunity to re-engage the user, not just attract new users. Did they make it halfway through your content and then disappear? Post obsessively for a week and then fade away? You have a small window - maybe two interactions, maximum - to re-engage with them and try to win them back. If you can't win them back, maybe you can get them to tell you why. Timing is critical for this; you don't want to annoy them or remind them of why they hated your app. Do NOT hit them with an email or notification push at 9:00 in the morning on a Monday. If the user launches your app after a pause of weeks or months, you have a chance to re-explain your value, or let them know what's new.
4. Embedding the web into your app lets you keep the user engaged while seeing the world
Most social applications have this figured out by now: embedding a browser element into your application lets users enjoy sharing and curating the web, while keeping users engaged in the flow of the app. Before handing off control to the system browser or Safari, ask yourself if you can do a better job managing the user's web experience yourself. (Often, the answer is no - but in some specific cases, like a Twitter feed, you really can do it better). Stay alert to how the browser landscape is evolving - as read-it-later platforms evolve and system intents get better at handling web content, you may need to add features to keep up.
5. Embedding your app into the web gives you flexibility and reach
Give some thought to how your web application could be embedded or repurposed. Does it make sense for you to offer a content plugin for blog platforms? Are you serving good Open Graph metadata so you render well when linked on Facebook and Twitter? How do you look when shared on Pinterest? Should you have an API or a per-user RSS feed?
Make sure your web content looks good when viewed in the native apps from the big social networks, and that your engagement strategy works there, too.
Too often, analysis of the application landscape falls into a simple narrative of installed vs. web. The truth is that we will use both, and our products will need to understand them both to keep our users happy and engaged.