Now that I’ve had a few weeks to play with my Nexus One, I’m starting to grok the gut-level experience of living with a smart phone. I understand why people download apps, how it feels to have the Internet with me everywhere, and what it’s like to experience the web by touch on a screen that’s only a few centimetres square.
Device-specific apps are sweet and shiny at first, but after a couple of weeks, it becomes obvious that many of them are the encore of the floppy-based PC shareware world of the 1980s and early 1990s (SEND $5 TO GET RID OF THE ANNOYING ADS! ONLY $10 FOR THE FULL VERSION!).
Discovering an interesting app through Apple’s or Android’s market (or taking a picture of a barcode on your computer screen) is surprisingly awkward compared to just following a link from one web site to another, and as we’ve learned from the postal service, the telegraph, the telephone, email, and the web, connectivity always wins in the end.
Web apps run everywhere and connect to each-other seamlessly, and HTML5 allows a well-written web app to do almost everything a closed, device-specific app can do on a smart phone — many of the mobile web sites I’ve used (hello, Google!) are as good as or better than the corresponding device-specific apps. There are some things, though, that make mobile web apps stand apart:
- The built-in buttons on your smartphone are tied to the browser, not to the app, so the Android menu or search button (for example) brings up a browser menu or search box, not an app one.
- For good security reasons, a web app will probably never have as much access to the filesystem and device hardware as a closed device-specific app (do you want a malicious web app to be able to turn on your video camera when you’re browsing in bed? do you ever consider that when you give a downloaded app access to your camera?).
- While HTML5 supports notifications, you have to actually be on the web page to receive them. That can be fixed by allowing the browser to launch web pages automatically on start/restart, but it’s still more awkward than an autostart app.
- Web app processes need to be managed from inside the browser, not from a device-wide process manager.
- As far as I know, there’s no way for a web app to install its own icon on the device home screen — the user has to install it manually (though it’s pretty easy).
I don’t consider most of these to be a big deal, but they do point to the fact that no matter how much extra functionality HTML5 provides, web apps have a different world view: they’re nodes in a huge network, not standalone silos.
I’ll probably have to continue to use a device-specific app for anything related to playing music or capturing photos/video for a while longer, and I’ll hang onto the Android WiFi analyzer I’m running on my phone. Android has a lot of the same apps that show up in iPhone commercials (like Urban Spoon), but while they’re pretty, they’re limited in the end — there’s way more out there on the web than there will ever be an an app store.
If you’re an person or organization that wants to interact with people on mobile devices, you have two choices:
- You can develop and maintain separate apps for iPhone, Android, Blackberry, Palm, and any other smart-phone OS’s that may come along, and let the phone vendors be gatekeepers between you and your users.
- You can run a single mobile web app on your own server, one that’s only a click away from any other web site that links to it.
The first option lets you force an icon onto the users desktop, but the direct development costs and opportunity costs of losing inbound links and search-engine love just seem too high.