The One Web: don't write for devices, write for people
By on | 2 comments
At yesterday's UpdateConf, Jeremy Keith noted that his favourite application on iOS was the browser. He's a proponant of an idea called the 'One Web', which Addy Osmani discusses in further detail here
When it comes to mobile application development, the debate surrounding native vs web is divisive to say the very least. On one side of the battlefield there are those who believe there's an adherent benefit to developing native applications optimised to fully take advantage of the capabilities specific devices and platforms (such as iOS) have to offer. On the other side we have those who believe in the One Web.
The One Web is a rather broad concept, but it has one important principle at heart - the web should be open. Regardless of who you are, what device you're using and what browser you're accessing content from, no user should be left behind. Open access to all is one of the defining principles behind the web but it can feel like we're ignoring this fundamental concept in mobile sometimes. What the One Web suggests is that rather than companies focusing on creating native applications, they should instead focus on creating experiences everyone is able to get to.
This extends to veering away what open-web evangelists call the big walled gardens - namely the Apple App Store ecosphere, Windows Phone 7 and other such platform or device-specific mobile applications that limit themselves from being available to all of the web by their locked native nature. Some designers involved with native application development may claim that users feel more comfortable with experiences that look and act like they're more integrated with a particular OS, but in my opinion this can be achieved with a web application just as easily.
Why do we believe it's the future?
I'd like to explain why I, like Jeremy Keith, support this crazy notion of the One Web.
At the moment, there's a limited set of capabilities that differentiate what is currently possible when creating a web app and a native app. In my opinion, this boils down to the ability to interact with a device's hardware (the camera, microphone, etc) and the filesystem. The reason I believe that mobile web applications are the future is because in time (give it a year or two), the gap between what's possible with native apps and in-browser apps will narrow and eventually close.
Almost all of the mobile panel discussing this topic at UpdateConf agreed with me on this point.
If you happen to also agree with it, you may enjoy Jeremy's framing of where the future of native applications stand in yesterday's discussion.
Jeremy Keith: Writing a (native) app is like coding for LaserDisc.
Aral Balkan: That's not a fair analogy!
Jeremy Keith: Give it time.
You don't, however, have to take anyone's word for it. There is already progress being made towards bridging the gap between mobile and native - draft specifications exist for device/media APIs as well as one for the filesystem API. Those heavily vested in game development will have access to hardware-accelerated canvas and WebGL across multiple devices. Audio APIs are also being worked on and I have no doubt that once these specs have been implemented in more mobile browsers the appeal of opting for native development will slowly start to fade.
Would you really want to lock your content into one platform when you could expose it to millions of other users?
Did we forget anything?
One important topic missing from the above discussion so far is monetisation. Businesses like the closed ecosystem around the App Store because it offers a simple, one-click path to actually making a profit from your creations. This is crucial to the success of applications that don't rely on in-app advertising revenue, so we can't simply ignore it.
Some would argue one-click payments are a lot more difficult to get right with web applications. Right now, I tend to agree. Sure, we currently have PayPal, Google Checkout and other such solutions, but there's nothing that's perceived as being as reliable or as flexible as what you get out of the box when you're using the App Store.
I believe that a time will come when a solution we can all trust (within reason) will make itself known, but for now all we can do is research and continue evaluating and innovating in this area. It's a hard problem to solve, but someone will get it right.
What about the here and now?
It's time to come back to the present. I want to discuss compromise between native and the web, as this isn't always explicitly stated when having this discussion. We of course need to be realistic about what is feasible in mobile development right now. A few of the attendees at yesterday's event were looking for a solid answer to this, so I hope the rest of this post provides a little more clarity.
Yes, One Web is a brilliant idea in theory and one that's inevitable, but what if you want to start creating apps that use all of those extra pieces of device hardware today? Should you wait until all of these APIs have been finalised? Should you wait until a better payment solution for mobile is available? The answer is, of course, no.
I believe that native application development is only a temporary stop-gap solution, but both Jeremy and I agree that progress towards the One Web shouldn't prevent you from building native applications for the time being. If you absolutely need access to capabilities that aren't currently possible with the browser, you shouldn't let anything stop you.
Just be open to the idea of us moving towards the One Web in the future. It's just a matter of time, but some day we'll all be able to access applications regardless of device or platform and it will be glorious.
As Jeremy poignantly put it himself, 'I don't write for devices. I write for people.'
2 comments
Comment: 1
Coming back to this issue an idea it feels that native apps feel more like products to consumers than an open web app would. A native app is like an object. In fact, a native app replicates what objects do in many cases (I'm a synth junky and I've discovered all sorts of iPad synth emulation apps).
While I do think most native apps would be better suited as open web apps I wonder about these more robust 'traditional' apps. The experience of the object/device seems much more difficult to replicate on the open web than the content experience while native apps excel at this.
In that essay I wrote my solution to this problem was an end of ownership in favor of a subscription to apps. This is already being implemented in music/streaming services to some extent. Rdio being the best example because you can access the full scope of your subscription in different ways in both the browser and in native apps.
Comment: 2
I have been in the game for a few years now, and in this short time i have definitely seen this happening. The gap between native and open web is closing and in some cases, the web has already won!
Take for example the two social networking sites, Facebook and Twitter. If you have ever used the native mobile versions of these you would have surely face-palmed yourself more than a few times. Facebook comments are never updated instantaneously even after a refresh, and notifications are buggy. Twitter never shows the correct amount of followers, and only displays up to a certain amount, disregarding the rest of them as if they never existed.
Now the mobile versions of these social networks are actually more feature rich than the natives, not to mention all data is updated directly from the source, instead of jumping through hoops to get to and from a native client.
The downside to the web comprises of:
1) Devices not having enough resources allocated to the browser, which in turns results in fragmented touch scrolling with a slight jerking motion. and,
2) No access to the devices technology such as camera, file system, GPS, contacts etc...
All that said, there are already javascript API's for accessing device hardware already being pushed to be standard as we speak, and when this is more wide spread, the "one web" will replace the new "HTML5 and CSS3" fad!
Peace!