Apr 16 2012
On Jack & Colin's "Consumerization Nation" podcast last week, there was an interesting conversation (beginning at 36:30) when the guys (Jack Madden, Colin Steele, Gabe Knuth, and Brian Katz) discussed HTML versus native apps, tablets versus keyboards, and many-featured versus focused apps.
They fell into the rathole of things like "will an iOS version of Office kill Windows versions?" and "do platform native apps have more features than HTML apps?" etc.
As I listened to them talk, I realized that they'd never be able to resolve anything because they were grouping characteristics of multiple issues and then presenting those as an option versus other sets of grouped characteristics. In other words, you've all heard the phrase "it was like comparing apples to oranges"—in this case it was like comparing apples to oranges to pineapples to bananas. When you get into conversations about the future of applications and which are better, you have to break down the "application" into its core characteristics and look at each one separately:
- App platform: Native versus platform independent
- User interface: Touch versus keyboard/mouse
- App feature set: Many features versus "focused" apps
- Focus: Create versus consume (or interactive versus passive, etc.)
(I thought I could create cool graph to illustrate this, but that's going to be difficult.)
These four sets of app characteristics have been present for years, but most people don't think in this way because traditionally the focus has simply been full-featured, keyboard-based, geared-for-creating desktop applications versus touch-based, focused apps for content consumption.
But these traits not mutually exclusive. You can have HTML apps that are made for touch. You can have simple focused apps that are made for a mouse and keyboard.
The key is to thinking about future apps is you'll be able to combine the traits to deliver the right app for the right use case. Mark Templeton said this best in his keynote at Citrix Synergy 2010. "We'll all have use for a small screen, a medium screen, and a large screen device. So we each need to figure out which screens are needed for which types of access."
To illustrate this point, let's go through each of the characteristics listed above.
App platform: Native versus platform-independent (HTML)
Platform native (Windows EXE, iOS app, etc.) versus platform independent (Flash, HTML) is something we discussed quite a bit in our recent book, and there's a lot that goes into that conversation. But for the purposes of this blog, I'll highlight a few key points.
First, a lot of people make a big deal out of HTML apps having fewer features than platform native apps, citing Google Docs versus Microsoft Word as the example. While it's true that Google Docs has fewer features than Word, it's not because Google Docs is an HTML app. It's simply that Google Docs is much newer than Word (so they haven't had as much time to add as many features) and Google's stated design goal is to create a simple-to-use Word processor without a lot of unnecessary features. So while it's a true statement to say that Google Docs has fewer features than Word and that Google Docs is an HTML app, there's no causality between those two. HTML apps don't have fewer features just because they're HTML apps.
That said, there are certainly limitations to what HTML apps can do since they have to access a device's hardware via the APIs exposed by the browser vendor instead of APIs exposed by the OS. But this "limitation" is widely overblown. Whenever people talk about this limitation they cite examples like the GPS or the camera. Well guess what? HTML apps can access both of those nowadays. They can also access client-side audio, client GPUs, print preview, full screen… etc.
Another supposed negative trait of HTML apps that people like to throw out there is that "because the same HTML app has to work on a phone, tablet, and desktop, web apps are always going to have a worse experience than native." This is half true. It's true that the a single app UI isn't great for all these different form factors, but that doesn't mean a single HTML app can't work for them all. Use Gmail as an example. If you visit mail.google.com from your iPhone, iPad, or laptop, you get a very different UI, even though it's all the same initial URL. So it's possible to design apps that feel right regardless of the form factor.
User interface: Touch versus keyboard/mouse
This is another contentious issue, but it can be summarized like this: use the right UI and input method for the right app on the right device. If you're sitting at a desk, a physical keyboard makes more sense than a virtual keyboard. If you have more than a few sentences to write, you probably want a physical keyboard.
While we've debated the "will tablets kill PCs?" question ad nauseam, I still hear people sharing anecdotes about how they took their iPad on a trip instead of their laptop. But that doesn't "prove" anything other than that person had been taking the wrong device after all these years.
This questions of the proper UI, coupled with the previous conversation around app platform, are often confused and interchanged. So I'll be clear here: there is a difference between "device native" and "form factor native."
We discussed device native above. "Form factor" is about how the user interacts with the device. How big is the screen? Is there a physical keyboard or a virtual on-screen keyboard? Is there a mouse or trackpad or does the user touch the screen? It's pretty obvious that applications written for the proper form factor work better than applications that are translated and presented for the wrong form factor. We all know how awful the experience of using Windows desktops applications with your fingers can be. The same also works in reverse. (Have you used Windows 8 Metro with a mouse? Pretty lame.)
So while the argument of "platform versus form factor" is a common one, you can see that the two are sides of the argument are not speaking in the same language. The platform an app is written for doesn't generally have anything to do with the form factor the app is written for.
App feature set: Many features versus "focused" apps
One of the things that most people celebrate about these new mobile apps is how "beautiful" they are. It's amazing how we associate beauty with the removal choices. But when it comes to getting done what you need to get done, would you rather have the beautiful app or the one that gives you all the options you need?
Which of these cockpits is more beautiful? Now which would you be most comfortable flying in?
Of course people want to use beautiful things. But when beauty comes at the expense of removing features, now we get into a complex scenario. Which features do you remove? It's like lawmakers trying to create a budget. Everything is important to somebody.
For example, in the podcast Brian Katz mentioned something about an iOS version of Microsoft Word being useful for 90% of users—before quickly adding, "Well, assuming it had track changes." So now we know that Brian considers track changes to be a critical feature. But there are other users who've never heard of track changes and don't care about that feature. For me personally, the biggest thing I don't like about iOS-based word processors is that they don't have a Document Map View.
So who's right?
Of course the answer is that "it depends," and app developers have to prioritize features and try to include the ones that will be the most useful to most people. The key is that the conversation about which features are important and having "too many features" versus "focused apps" is NOT the same conversation as delivery technology, application platform, or form factor.
(There was a funny moment in the show when someone said, "Maybe that could be a button you click, to switch back-and-forth...Like a one-click to convert between simple focus mode that looks like mobile and full feature mode." And Jack said, "Yeah, they're doing that. It's called Metro." :)
Focus: Create versus consume (or interactive versus passive, etc.)
The final characteristic of applications we have to consider is about what type of interaction the user has with the app. Is it an app they sit down in front of for hours at a time in a very interactive way, or is it something they passively watch? Does the user use the app once an hour for ten minutes at a time, or 45 times an hour for ten seconds at a time?
When Mark Templeton talks about users having multiple devices with different form factors and screen sizes, he uses words like "dining" and "snacking" to describe what the user wants to do with the device. This is a great way to think about it. Sometimes we sit down for a formal dinner. Sometimes it's a quick lunch. Sometimes it's a candy bar on the go. It's all eating though, and while one of them is not better than the other, we need different tools, different types of food, and different locations for each.
When it comes to application use, there are times when we want to sit down and have our primary focus be on the computer. This is a scenario where it makes sense to have a big screen (or multiple big screens) and the ability to have many multitasking applications. Take PowerPoint, for example. Creating a presentation is something that requires focus. You might to start with a text-based document which as your outline. Then you open a bunch of emails to read and incorporate other peoples' responses. You have a bunch of web browser tabs open as you do research, collect URLs, and download images. You have image editor software open to adjust everything. Your focus is 100% on the creation process, and many people even close their email clients and put on headphones to shut out the distractions and work. This is something that wants to happen with a lot of screen real estate, a keyboard, and a mouse. (Because your hands would get tired if you had to reach for the screen for hours on end, and it's hard to precisely edit and place your slide elements with your fingers.)
Once you've created your presentation and want to get feedback from people, that's a "snacking" activity for them. They can easily view the slides on an iPhone and insert a few comments here and there.
Then when it comes to incorporating their comments, you're back to your fully immersive creation mode.
And finally when you deliver your presentation, you can do so from an iPad or iPhone. Or if it's a self-driving presentation or video, users can watch it on their iPads.
PowerPoint is just one example of one application, but the same general idea exists everywhere (This is also why Windows desktop applications don't work well on mobile devices. It's not about the performance or even the UI—it's because mobile devices are designed for snacking, while Windows desktop applications are designed for dining.)
So what's the point of all this? It's that when you're thinking/planning/arguing about the future of applications, remember that there are many dimensions involved. Just because many HTML apps don't have as many features as desktop apps doesn't mean that all HTML apps can never have the features of desktop apps. Just because people like to use their tablets for writing emails doesn't mean there's no more need for a mouse and keyboard and multiple huge displays. Just because people like the simplicity of apps on their iPads doesn't mean that all future apps will not have too many features. Just because you can deliver an app made for one form factor to another doesn't mean you should. (Remote Windows desktop applications suck on an iPad, but remote Windows Metro apps will be fine.)
(Note: You must be logged in to post a comment.)
If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.