The Next Application Platform? All of them...
The Next Application Platform? All of them...
UPDATED: Added comments on backend story.
I’ve been knee deep in my book and a super secret project I can’t talk about yet but that project and some conversations i’ve been having (on Twitter and with the Atlanta Pros User Group when we discussed HTML5). It started with the exaggerated death of Silverlight. I was asked at length to comment on what how HTML5 and Silvelright compete and other topics. But after looking at a lot of different things, I came up with a different idea…
While we as technologists (or, if you prefer, geeks) are concerned with finding a winner in this fight, users don’t care. What users do care about it access to your application. In the enterprise space this is easy. We can dictate how users access our applcations typically. We can specify the operating system and browser and build for a static platform. So that means building with Silvelright, Flex, .NET or Java; it doesn’t matter. There are reasons to pick all these different platform choices (and I won’t belabor them here). But that’s where you’re building a single experience for a well-known set of users. This is a lot of you out there.
The problem is that applying this same logic to the broader reach of users doesn’t work. All it takes is one CIO with an iPad or Android phone to really screw it up. When you’re building truly reaching experiences (ones that need to reach the maximum number of users; whether they be consumer or business users) the common strategy has been to find the platform that reaches as many of these users as possible. HTML has been a common approach here. Build the website and they will come. Even extending the website with other facilities like Silverlight or Flash has been a useful. But things are changing.
The environment is changing. It used to be that the experiences we had were on a computer: desktop or laptop. That what the nature of how we interacted with computing devices. Uber geeks and others were hot on smart phones, but they didn’t attract much traction outside of corporate America until Apple changed the game. The iPhone was crucial to bringing the masses to other devices. Both the iPhone and the iPad have gotten the general public to use computing devices in many more ways that before. For the Apple-phobic, Google filled in some of this need first with Android smart phones and recently with tablets.
None of this is news to most of my readers. You know this; you have the phone; you have the t-shirt. The problem is how to extend your reach to the mindshare of these users? Because plug-in development (e.g. Flash and Silvelright) don’t extend to iOS devices (e.g. iPhone and iPad), the common expectation was that you should go to HTML5. It would fix everything. I like HTML5, but I think you’re duct taping a horn on a horse and hoping it will become a unicorn. While the browser on iOS devices support HTML5, will that be the way users want to experience your product? Nope…
Let’s look back at the history of what happened with the iPhone. When the iPhone launched in June 2007, they didn’t have an AppStore. In fact, they didn’t want them (im my opinion). The early advice was to write apps for the iPhone, you should write applicaitons for the Safari browser. That would be the app model for the phone. The important quote was:
But it didn’t work. Why? Apps are a better idea. This rings true for me today with building experiences for users. The experience of the application (while more work) it better. And more importantly, can take advantage of the platform. Building a single experience for all users, no matter the device is a challenge. Even mobile pages are a hack at best IMHO.
Look at the Facebook example. They’ve built a great web site (ok, let’s not debate that) that allows users a lot of different types of functionality and helps them gain a ton of users. But guess what, the Facebook website isn’t the way many users interact with it. Facebook apps (through their APIs) are an incredibly common way to make this work. Facebook has the sticky-ness because they’re everywhere.
There are two approaches here (probably more though): build it or build the community. You can decide because of your particular product that you need to build the application yourself because you want to reach all your users. You may take the Twitter/Facebook strategy of building great API’s for a community to build applications on top of. Neither of these approaches are exclusive either,
“But what technology should we be using to get this reach?” This may be the question you’re asking yourself now. The unfortunately (but oddly fortunate) answer is all. I think for a number of products out there you will be building:
- An HTML5 solution for the web.
- Using Plugins to extend HTML5 as necessary (though less important these days).
- Building Desktop/Browser apps for in-house/well known customers (e.g. Silverlight, Flex, .NET, Java, etc.)
- Building Apps for mobile/tablets in Objective-C, Java and Silverlight.
This means as a developer you’ll need to expand what you know and learn more platforms. Is that bad or good? Both. It means more work for all of us, but it does mean you’ll need to less focus on silo’s of platforms and use your knowledge across these platforms.
So a quick note about that last bulletpoint. Why not build for the ‘winner’ of the smartphone/tablet space? Because there will not be one IMHO. Three years ago, the idea that iPhone could get the kind of penetration it has could not have been predicted. Could iPhone kick out Blackberry? But wait, they didn’t. iPhone primarily ate into candy-bar phones. They brought the smart phone to the masses. And their strategy of a single carrier has backfired I think somewhat. In fact, Android has a bigger market share right now. So why didn’t I mention Blackberry there? Because they’ve been sitting on their hands for too long IMHO. Look at this chart that shows how Android has taken Blackberry’s marketshare on Verizon (largest US carrier) from 90% to less than 20%:
And you might take exception to my inclusion of WP7 in my suggestion. I have a bias and I think the phone will make big in-roads in the next year, but it takes time to get there. Probably the v2 that supports enterprises more will really be the tipping point. But I think its here for real.
There is good news though. Because you’re primarily looking at user interface platforms. The back-end is likely going to be ubiquitous. You can build the hard part of the platform using a single platform and only focus on the change in UI based on the device. This also means that you can use your current (or favorite) skills to build the bulk of the applications. (added 12/12/2010 8pm)
What do you think? Excited or scared to learn these different platforms?
