Ranting and raving about anything I feel like complaining about.

The Next Application Platform? All of them...

by

Compass

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:

no software development kit is required for the iPhone

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?

 

 
 

Comments

Gravatar Though I would want a full-reach option that isn't a lowest-common-denominator, my guess is that you are probably right. As for me, I love learning new technologies so I'm looking forward to the mental stretch. I'm just not looking forward to spending a lot of money on a Mac so I can do iPhone/iPad dev :)
Eric Sowell (Posted Monday, December 13, 2010)
Gravatar I don't totally agree with you about the Enterprise. While the actual users don't care about what technology the app uses, the IT departments do. Our application used a smaller, somewhat unknown database. Users loved the functionality, but because the IT department didn't know anything about it, we had a hard time selling it. We were told we had to use SQL Server or Oracle. The real answer is to use mainstream technologies, not niche ones.
Craig Berntson (Posted Monday, December 13, 2010)
Gravatar Eric,

Becareful of what you wish for ;)
Shawn Wildermuth (Posted Monday, December 13, 2010)
Gravatar Craig,

The benefit (which I failed to discuss in the article) was that a common backend infrastructure should be accessible for all of them. Adding it now.
Shawn Wildermuth (Posted Monday, December 13, 2010)
Gravatar Interesting article. I do hope you're right about Silverlight; that technology is too nice to give up.

One observation, though: where's WPF? Although you do mention ".NET" w.r.t the desktop, no WPF. Maybe there's an attempt to stick with strictly cross platform?
HybridWeb (Posted Monday, December 13, 2010)
Gravatar The greatest quote in the whole article:

"I like HTML5, but I think you're duct taping a horn on a horse and hoping it will become a unicorn."

Can I quote you on that? You nailed it.

I think that people are in search of the "one" platform to save the world. I think this will not ever happen and if it does I think it will kill innovation in various ways. Love or hate Apple, they have brought a new level of expectations to our users. In the business world this means you are expected to do more than slap some datagrids with detail screens for your typical business app. And the quality of software that Apple does put out has brought the standards up for this type of development.

In my mind this is a great thing, competition drives innovation. I think if one platform one out to be the swiss army knife of platforms, then we as geeks have stopped being creative and it will lose that magic that keeps us all involved.

Great article as always Shawn!

Jonathan Marbutt (Posted Monday, December 13, 2010)
Gravatar HybridWeb,

I didn't mention WPF because I think WPF starts as a Silverlight app, then is matures if necessary to WPF. And yeah...you can quote me.
Shawn Wildermuth (Posted Monday, December 13, 2010)
Gravatar Good Read.

Have you looked at MonoTouch and MonoDroid? The promise of common code is really appealing.


doobiaus (Posted Monday, December 13, 2010)
Gravatar doobiaus,

I don't see how much common code you'd have. Remember its just a UI framework and the APIs are different on the different OSs.
Shawn Wildermuth (Posted Monday, December 13, 2010)
Gravatar I totally agree, and it's good news, if it's news at all.

Nothing has changed for me, we have a strong, solid, tested backend that is capable of delivering information to ANY client.

We'll use HTML where it's needed, and it's needed in a lot of cases. We supplement those sites with Silverlight administrative apps, and specialized apps, working deeper into the data.

Unfortunately, HTML is just universal, and most user facing sites need to be there.

I would still like to see Silverlight have a more cross platform focus as well, but due to the nature of competition, it's not in the cards for it to be on iPhone, Android, or Blackberry.

Even so, I'm still a happy camper!
samcov (Posted Monday, December 13, 2010)
Gravatar Interesting article Shawn.
Did you have a look at Adobe Air?
It does iPhone and Android.
Karel Vandenhove (Posted Monday, December 13, 2010)
Gravatar Karel,

Yes I have, it lets you create a single UI for several places, but I don't think users will like a single UI if it doesn't match the phone...it has to look like the rest of the platform which you can't do with a wrapper like Air or MonoXXXX.
Shawn Wildermuth (Posted Monday, December 13, 2010)
Gravatar Shawn,

Please do not go around saying that MonoXXXX is a single UI across platforms. MonoTouch and MonoDroid applications will look identical in terms of UI to the platform, unlike Air as you mentioned.

ChrisNTR
Chris Hardy (Posted Monday, December 13, 2010)
Gravatar Chris,

The intent was that if you build one UI (regardless of language) that it is one UI on multiple platforms. I think this is the same for the Mono-based technologies, no?
Shawn Wildermuth (Posted Monday, December 13, 2010)
Gravatar Your point of view is developer focused. From a business perspective, while one can learn how to develop on all three platforms, it makes more sense to be strong in one platform and hire help for others if your app is succesful on the silo platform.

It's never been the shiny interface that makes an app succesful - it's always the business concept.

Justin (Posted Monday, December 13, 2010)
Gravatar Hi Shawn,

Good article. I'm currently using MonoTouch/droid and while it's true you still have the unique API per platform, I find that way more ideal than having to become an Obj-C expert. Also, if you have a MVVM design (more like a MVC pattern I'm finding) 2/3 of your code is essentially write once; add all the features of .net 3.5 (LINQ etc) and you have a very compelling development environment.

sham (Posted Monday, December 13, 2010)
Gravatar The Mono-based technologies on mobile devices are about bringing the .net framework to the device in their native architecture (such ARM code) whilst enabling the programmer to still be able to use the native UI bindings to develop a user experience which is familiar on the device they are using.

For example, in the iPhone SDK, you have the UIKit library which allows you to use native UIViews, UILabels, UIButtons etc. In MonoTouch, you can access these using the namespace MonoTouch.UIKit.UIView etc, etc but since you also have access to System.*, so you don't have to figure out how to do web requests, XML parsing on each platform. This is the re-useable part throughout the cross-platform applications.

I hope that clears it up for you, feel free to contact me if you want to chat further.

Cheers,

ChrisNTR
Chris Hardy (Posted Tuesday, December 14, 2010)
Gravatar Well said Shawn.

But I think part of the very challenge itself is the various platforms and the knowledge gaps it presents. Even vendors like Microsoft don't have a clear answer, and they have a rich history of providing great tools that allowed even armchair developers to cobble together a functioning application. Adobe is covering some parts of the puzzle but they don't even come close to a write-once-run-everywhere scenario. But maybe the promise of a clean abstraction allowing a developer code ubiquity without API considerations should go the way of the flying car and robots to do housework.

I'm hopeful your answer is the "Framework Forever" that is coming soon will solve these development issues. And tooling too please, and maybe even a debugger so I can peek into the magic.
Cliff Jacobson (Posted Wednesday, December 15, 2010)
Gravatar Thanks for the article Shawn.

While our users might not care about what technology we choose - the people paying our salaries typically do. One of the most compelling reasons to choose one technology over another is whether you have the staff on board to support it. Having to build applications in a multitude of languages may give the best user experience but comes at a cost, in salaries and code bases (shared back-end code helps somewhat but there's still a lot of other code to write).

Tokes (Posted Monday, December 20, 2010)

Add a Comment

*
*
*