February 1, 2011 | by Michael Heller
A few days ago, once people had a bit of time to dig through the newly released Honeycomb SDK, it was found that there was a rudimentary smartphone emulator built in when you crank the resolution down. The tech world was suddenly buzzing with the idea that Honeycomb would be coming to smartphones after all, and the OS wasn’t “built entirely for tablets” as Google had claimed. Let’s slow down a minute, because I’m not sure there’s really any reason to believe that Honeycomb will make its way to phones; and, more importantly, I’m not sure it should.
In the in-depth talks on Honeycomb from Andy Rubin and Matias Duarte, both men have been very careful not to say that Honeycomb would also run on phones. Matias Duarte said, “What you see in Honeycomb is absolutely the direction for Android.” But, he never said that Honeycomb would be running on every device. He was saying that there were certain design elements that would become ubiquitous in Android OS iterations, like the software buttons, the multitasking UI, and the context sensitive action bar. When Andy Rubin previewed Honeycomb at the D: Dive into Mobile conference, he also never said Honeycomb would be on smartphones. Andy only stressed the fact that apps would work across devices, regardless of the OS version.
Fragments will ease fragmentation fears
Most people seem to have forgotten the “fragments” system that Andy Rubin mentioned when he first showed off Honeycomb on the Xoom tablet. Fragments are Google’s way of making development easier by allowing devs to simultaneously create an app that will run on both a smartphone and a tablet. The idea is very similar to what we’ve seen in the Eden paneling system introduced by Notion Ink. With this system, devs can make separate “fragments” within an app which would be shown side-by-side on a tablet, but would be separate pages on a phone. For example, in a mail app on a tablet, you could have the folder/message list in one fragment and the viewed message in another displayed side-by-side on the screen, but on a phone you would only see one at a time.
Given that Honeycomb is touted as being “built entirely for tablets”, this seems like a much more logical reason for why there is a buggy and simple phone resolution emulator in the Honeycomb SDK. Keep in mind that the UI seen in the SDK is also missing many of the new styling changes that have been built into Gingerbread, let alone any Honeycomb UI elements. Google knows that the world of tablets and phones need to be connected, but that doesn’t mean that the OS you use on each device needs to be the same.
Tablets are a new interaction metaphor
The fundamental way that people will interact with a tablet is different from a phone. Andy said himself, “It’s fundamentally changing the model of computing interaction. It is much more physical. You touch it. You feel it.” What you need and want to do will be different, and how the apps behave will be different, but that doesn’t mean that the apps can’t still be ubiquitous. The use case is inherently different. A tablet is much more of a couch/commuter device, where phones are truly mobile and are much more likely to be with you at all times. Consider iOS on the iPhone vs the iPad – what’s the difference? Not much. It’s the same grid of icons, the differences only arise once you’re in the apps. The iPad is also a consumption device at heart. Google may not want that. Given the options for alternative keyboards and voice input, the potential for Android tablets to be viable content creation devices is more apparent than with the iPad. The power and versatility of Android combined with the screen real estate available in the coming group of tablets are going to change how apps and widgets function, and how you interact with them. Those uses won’t always translate to the smartphone.
Honestly, I don’t know if Google plans to have Honeycomb eventually make its way back to phones. In fact, I’m not sure Google knows the answer to that yet. I think they want to create the best tablet experience they can, then, as always, leave it in the hands of users and developers for a little bit. See how it evolves, see how people use it, or want to use it. Then, make the decision from there. As long as developers can easily make apps that work on all devices, it shouldn’t really matter whether we use the exact same OS on every device, and it may not even be a good idea. Windows 7 will not make a good experience on a tablet. iOS would be terrible on a laptop. So, why should the OS have to be the same on phones and tablets? Because that’s how Apple is doing it? No. Apple can get away with that because of the simplicity of their OS. But, Android can be different, and make the OS fit the use of the device. I don’t want my tablet to be an oversized phone, so the OS shouldn’t be the same on both devices. Let Ice Cream Sandwich bring Honeycomb features to phones, but don’t force Honeycomb to be everything.