Dear Google: Give Android A Bloody Roadmap Already

I want to start this off by saying that I’m the biggest Android fan around. I owned the G1. I currently own an Evo and a Xoom. When I get a new baked good-themed update, I check every menu in every app to see what’s new. I get excited about new market share stats because I love to see the growth of the platform. To take what I’m about to say as anything other than a fan criticizing a problem with an otherwise satisfactory platform would be inappropriate. That being said:

For crying out loud, Google, can you develop a friggin’ roadmap? And then stick to it?!

Software updates in general tend to be finicky beasts. Windows updates whatever year it feels like. Facebook will inform you when their site changes two days after the change occurs. The dozens of apps on your phones will pop in with new updates at bizarre and unpredictable intervals, some with 4 or 5 seemingly pointless updates a week, others with one substantial update every couple of months. In fact, there’s only two pieces of software I know of that release on fairly regular schedules: the Mac OS and Ubuntu. I’m sure there are others, but not many that are so predictable.

Google, however, has a release schedule that boggles the mind. Ignoring, for a second, that almost all Google apps on Android update on a release schedule independent of the platform itself (we’ll get to that in a minute), Android itself has seen 7 major platform updates in the two and a half years since the platform’s inception. Due to the fragmentation argument, this almost sounds like a bad thing, but it’s not. The platform has progressed faster than any other smartphone platform.

The problem, however, is that no one, it seems, has any clue where that platform is heading. The most pronounced, and thus must infuriating, example of this can be found in Android Honeycomb. Earlier this year, Google unveiled their gambit for the tablet space. And frankly, it looked exciting. Instead of merely scaling up the interface to fit a larger screen, Google developed new methods of displaying information and features that made more sense on larger screens. It was great! Notifications now came in the bottom corner! App switching was easier! App functions were displayed in a large bar, not hidden in a menu. Awesome! But this drastic change in interface design understandably raised quite a few questions. What’s this going to look like on a phone? Will it ever come to phones at all? Is Android forking into two projects? How is this going to integrate with the Gingerbread update one month before?

So far, none of these questions have been definitively answered. We’ve heard vague rumblings about the two becoming united in the form of Android Ice Cream, but nothing solid. In the mean time, Google is withholding Honeycomb source code “until it’s ready”. Whether this is a good decision is debatable. Some say it undercuts Android’s claim at being open source. Others say it’s better that Google wait than release code that’s not ready. No matter what, though, it leaves consumers (and likely many manufacturers) entirely in the dark in regards to Android’s future. We’re left to hope that maybe Google will answer these questions next month at Google I/O

Speaking of Google I/O, however, the problems with Android’s unpredictability can, at the very least, be traced back to last year’s I/O conference. Last year, Vic Gundotra got up on a stage in front of a crowd of eager Google developers. This is the closest thing that Google has to the WWDC where iPhone announcements are usually made. Many major Android announcements are made alongside other companies’ announcements. Both Honeycomb and Android 2.0 (the first of two updates called Eclair) were announced alongside a Motorola device with a Verizon executive not far away. But Google I/O is just about Google. Last year’s conference is where we heard about such wonderful new features like Froyo, which would bring a ton of new speed improvements, Flash, and portable hotspot powers. There were also demos of new Voice Search commands, Chrome-to-Phone, and even a Google music service that allows you to stream your library from your desktop to your phone. Fantastic, huh?

Froyo was released fairly quickly after that announcement…..and that’s about it. Now, I watched the entire video and while perhaps I’m just oblivious, I somehow missed that the Voice Actions, Chrome-to-Phone, and improved music apps were not part of Froyo. Support for the apps was, but not the apps themselves. Voice Actions and Chrome-to-Phone were not officially released to the public until August of 2010. Chrome-to-Phone had been available as a beta prior to that, but Voice Actions was a complete surprise. It wasn’t until I’d actually downloaded the app itself that I realized “Hey, wait. Didn’t I hear about this three months ago?”

This was, of course, part of Google’s bid to combat fragmentation. Last year, Google began uncoupling major Google applications from the OS itself. Gmail, YouTube, and yes, Voice Actions and Chrome-to-Phone are all now separate from the Android platform as a whole. This provides the added benefit of not requiring that manufacturers and carriers push updates to consumers in order to get the latest YouTube upgrades. This can now be done directly via the Market. However, this also makes the release schedule even more confusing. Are Voice Actions going to be release with Froyo? Or are they just a cool thing you’re demoing? When phones eventually have Android 3.0, will they get the video editor that’s coupled with the Xoom now, or will that come three months later? It’s a double-edged sword. App updates are not reliant on system updates to make it to consumers (those that don’t require newer firmware, that is), but it also means that Google can announce three different releases on a single stage and there may be up to three different release dates.

Oh yeah, and the music streaming? Well, according to the rumor mill, Google just purchased a company called PushLife that might just be able to bring us music streaming. This rumor comes a month before the one-year anniversary of Google demonstrating this capability (though using your own desktop instead of a server) on a stage in front of thousands of Google software developers. One. year.

One could perhaps concoct some speculative theories about why this hasn’t been made available yet. Perhaps it’s too difficult to develop. Then again, this is the company that can coordinate navigation for millions of users. Perhaps it’s the record labels holding the feature back? Well, Amazon pushed ahead with their cloud player. They may be in some legal hot water, and we’re still waiting to see on that, but one way or another, they beat Google to the punch almost eleven months after Google demonstrated they had the thing working on stage. And, sadly, it’s not  the only time Android fans have experienced disappointment, or been told “Just wait a little longer.”

Now. To address what is no doubt going through many minds: does this make Android a fragmented platform? Of course not. In fact, the Honeycomb debacle actually kind of proves that, despite Google’s entirely unpredictable nature, they’re managing the diverse platform fairly well. Google introduced an API called “fragments” (fitting, huh?). The idea being that an app developer can divide interface elements into “fragments” that will be displayed in different layouts depending on what type of device you’re on. The Movies app is a perfect example of this in action. Tap on a movie on a phone, the entire screen will be taken up by a description and other information about the movie. Tap that same movie on a tablet, that panel of information will be displayed next to the column you’re currently looking at. App developers need only develop one app that works on all devices. Compare this to requiring an “HD” version of apps and it sounds downright unified. Additionally, Google made it possible to include the Fragments functionality in the app itself so that supporting this new method would not mean app developers have to require 3.0 or above for their apps. In fact, this feature is backwards-compatible to Android 1.6.

If the fear in fragmentation is that app developers won’t be able to keep up with which version of the Android platform their apps can run on, then Google is managing that fairly well. There’s difficulties that come from supporting a wide range of hardware (as many high-grossing game developers can attest), but this is largely part of the cost of servicing everyone, instead of only one type of hardware. And if gaming on a Windows machine is any indication, it can still be highly profitable.

What is unacceptable, and largely the underlying reason behind a lot of frustration with Google, is that users, developers, and manufacturers have very little idea of where the platform is headed. The Gingerbread update that came out in December is one of the slowest to make it to existing consumers’ handsets. It was also followed one month later by Honeycomb, which raised more questions about the future of the platform as a whole than any update before it. And if developers or manufacturers have gotten the answers to those questions, they’re not sharing with the rest of us.

Google, I understand why you did it. You’re in the center of a fierce smartphone platform battle while trying to maintain what you no doubt see as the moral high ground of openness. It’s a difficult balance, to be sure. But here’s the thing: people can get over the Honeycomb source code being withheld for a while. Few people even remember that you did the same thing for a couple weeks when the Droid came out. We’re fickle people and we’ll get over it. What we won’t get over, though, is the inconsistent and seemingly random schedule for updates, new releases, and features for the platform. And honestly, it’s really simple:

Don’t demo three products with different release dates and neglect to distinguish between or even mention any of them.

Don’t demo a feature you don’t know you can deliver.

Don’t release multiple, large-scale software updates within a month or two of each other.

Most of all: when someone asks where the platform is headed, have an answer. It doesn’t have to be specific. You don’t have to tell us what features the next update is going to have if you want to maintain a competitive edge. But let us know when it’s coming. If you want to be on a six-month release schedule, awesome. Just tell us. Then stick to it. Mmkay?


1 thought on “Dear Google: Give Android A Bloody Roadmap Already”

  1. Pingback: Noisecast Roundup 04-12-2011: If it bleeds we can kill it

Comments are closed.

Scroll to Top