Me and my Droid: The Honeymoon is Over

Back in January I got my very first smartphone: the Droid Eris. Manufactured by HTC, this appeared to be everything I was looking for in a device: no physical keyboard (replaced instead by a best-in-class virtual keyboard), a large, clear capitative touch-screen, support for Verizon's network, and a platform that supports multitasking. What could possibly go wrong?

I’ve been using the device as my primary phone for three months now, and it turns out, many things can go wrong. Android continually feels like an 80% solution, with many features being implemented, but their ramifications not being fully explored, and their functionality left unpolished. To get the most out of Android, you generally have to be interested in tinkering with the device, you must be patient enough to figure out exactly which versions of applications are compatible with the build of your operating system, and you better be ready for a learning curve because it doesn't always come cheap.

Hidden Functionality

One of the strengths of Apple's iPhone OS is that all the functionality of an application are on screen at all times. There's a back button in the top-left corner, there is a low-profile tab bar at the bottom highlighting which functionality the app is currently expressing, controls in the top right allow for editing, etc. Their design team has gone to great lengths to ensure that despite this, the user interface remains generally streamlined and uncluttered. Android, on the other hand, generally prefers to bury its functionality in contextual menus. There are generally two ways to apply context to a dialog or menu: either by long-pressing on the area you wish to manipulate, or by finding the appropriate option in the application's menu (revealed by pressing the hardware menu button).

The problem lies in the general lack of direction a user is given regarding which functionality is in which of these hidden context menus. HTC prefers to do multi-select table cell deletion via a context switch prompted by a menu item. Google apps generally prefer you delete or edit cells by bringing up the long-press context menus. Market apps? It’s anyone’s guess, really. Twidroid deals almost solely in context menus, but Seesmic will drill you into a deep hierarchy to get to the functionality you want.

The claim could be made that inconsistency is the father of innovation, as developers are now free to explore novel solutions to established problems. As a developer I am sympathetic to the claim, but this power must be wielded carefully, and with an eye cocked towards users at all times. Perhaps Google should have been more strict in their UI guidelines regarding what happens where, prompting more developers to follow them, which would prompt even more developers to follow suit, providing for a more consistent user experience. The fact of the matter is the opportunity has come and gone, and we’re left with an inconsistent experience that changes greatly between applications.

Android's Copy-Paste Problem

When the Windows Mobile 7 team announced that their platform would not initially support copy-paste, there was nothing short of an internet riot. After all, even Apple has conquered this problem, and Android had it solved since version 1.0, right? Well, not exactly.

Copy-paste is automatically enabled for editable text areas: simply long-press on the text area, and pick from one of a few options (copy all/cut all/select text). It is in the non-editable text regions that the inconsistency of Android once again rears its head. The application developer must explicitly enable it for non-editable regions, but it is not a simple matter of flipping a switch and enabling consistent behavior. The developer must choose how they wish to initiate the selection, then determine what actions should be taken when it is complete. This means that while certain apps will allow you to long-press on a text region and select text, others require you to dig through the menu to find the select text option (in the browser this is actually two levels deep in the "More" sub-menu.)

This also means that certain applications are missing this functionality altogether, the most flagrant omission being Google's own GMail app. Despite being the perfect place for this functionality, this app offers you no way to copy text from an email, not even while replying to an email.

You might argue that some implementation is better than no implementation, and I may have agreed with you two months ago, but now I'm not sure. What is worse: an inconsistently implemented feature that sometimes doesn't appear, or knowing that a feature is not yet ready, but when it is ready it'll work the same way everywhere? At this point, I have to side with the latter, as when Apple did enable this functionality it worked consistently and quite well!

Google's Own Services Are Broken

Google Voice stands to be Android’s most important contribution to the mobile space. The ability to decouple yourself from a carrier completely, and deal with SMS and voice through a third party number that will forward this data to you is an amazing development. When Apple rejected the Google Voice application I felt like the decision of which platform to embrace had been made for me. It would have been great if only it functioned properly.

Google Voice 0.3.2 (the most recent version) is not currently compatible with Android 2.1, and in fact has not been since the release of 0.3.0 in early January. While many of the features work as expected, you are no longer able to place calls with your Google Voice number, with all calls now appearing from your normal cell number. This bug makes the application useless, as what good is telling your friends to call your GV number if every time you call them your real number appears?

The only solution is to install an antiquated version of Google Voice: 0.2.0. This version conspicuously lacks the push notification that made GV 0.3.2 such an important update, instead relying on 15-20 minute polling to fetch your texts. This too is crippling, as it forces you to enable SMS forwarding to your number, ensuring that you still incur text charges from your real carrier.

First-Party Failure

First-party apps act as the gold standard for third-party apps. They are the template by which other apps are judged and based, and should generally be considered the reference for developers new to a platform. Many times I’ve consulted the Photo or Mail apps on the iPhone to determine how my application should function. Have a user interface question? Consult a first-party app. Need to know which stepping of an OS to target? Find out what Google supports and make an informed decision.

Between Google’s failure to implement Copy-Paste in GMail and their lack of testing of Google Voice for Android 2.1, it would appear that Google is sending the message that it’s okay to leave critical functionality out, or to not test on the most recent versions of the operating system. Even more damming is their tendency to roll out features that appeal to a small subset of users, like Buzz integration for Google Maps. From an outside perspective, it would appear that Google is placing emphasis on the creation of new functionality without addressing the shortcomings of the existing functionality.

Google should refocus itself on setting the standard for third-party developers, creating the highest-quality apps available for the platform and letting that quality trickle down as Apple has.

Multi-Tasking Done Wrong

The much-touted feature of the Android is its ability to multitask, but yet this feature more often ends up being a curse rather than a blessing. Let’s say you wanted to play a CPU intensive game, or you wanted to run your device for more than six contiguous hours without having to charge it. I'm sure it would continue to work fine, until that background process you have scheduled started running. Then get ready for intense lag, slow-downs, dismal battery life and general unresponsiveness from your device (which is especially damming for us who prefer virtual keyboards.)

All of this would be easily mitigated by a reasonable task management metaphor like Palm's WebOS. WebOS allows you to quickly preview all running applications in the form of cards, and manage which apps are running when. Want to play a game? You can close your news reader, your chat client, and your twitter client in a few simple flicks and get onto playing.

This same action in Android would require you to drill into every application you wanted to stop, find the "quit" option (which might be in the menu, or somewhere in the "settings" list within that menu, if it exists at all), then finally open your game. I would venture to guess this action would take you ten to fifteen times longer on Android than it would on WebOS.

Oh but I can hear you now, jumping up and down shouting "Taskiller!" and in doing so you have come to the core of my problem with the Android platform: such a basic feature was left unimplemented, leaving it up to an advert-laden task manager that actively warns users that clicking the wrong icon or menu setting can leave their phone unbootable.

You see, Taskiller comes with an option that causes the application to slay all but a few applications immediately after boot, "solving" the problem of being unable to choose which apps launch at boot time and which don't. This raises two important questions. First: why am I unable to control something as basic as "which apps launch at boot"? Secondly: you've created an option that you know might render a phone unbootable and touted it as a solution?

The amount of micromanagement that this feature introduces into day-to-day use is completely unacceptable. I understand that Google wanted multitasking to be transparent to users, and as such hid many of the details from the front end, but in failing to implement it properly it has actually ended up making it more opaque to the user than would otherwise be necessary.

Platform Fragmentation

I've long said that the best part about using Android is reading about all the apps you can't run.

This topic has been debated ad nauseam, but it bears repeating in this forum due to the nature of the device: the Droid Eris runs Android 1.5. Android 1.5 fails to support many features which we might consider to be essential to a device with a capitative multi-touch screen, like multi-touch. This feature was not enabled in the Android API until Android 2.0, which released in October 2009. That means the very first device (HTC's Dream/G1, released in October 2008) was unable to use multi-touch gestures for a year due simply to limitations in Google's API. In fact, this device is officially still at version 1.6, making them unusable in any official build, forcing users to rely on custom ROMs to enable this basic, hardware-supported functionality.

Android 2.0+ is also required to run all the fancy-pants new applications that keep making the news, like Google Goggles, Google Earth Mobile, the new Google Maps with turn-by-turn navigation support, and the new image gallery app. You would anticipate that Google would have an interest in seeing these devices upgraded, and yet I can count on one hand the number of devices in the US that officially support Android 2.0+: Motorola Droid, Motorola Devour, and Google/HTC's Nexus One. [ED: Actually, this was wrong. At the time it was only the Droid and the Nexus One, as the Devour is still on 1.6 to this day. The Hero line has recently received an update to 2.1, however, so the playing field is leveling.]

Once again, the community will appear to remind us that Android 2.0+ support is a few simple hacks and custom ROMs away. I understand that there will always be a scene for customization and configuration of a platform, and in many ways I believe it is healthy. It provides people an outlet for their tinkering and hacking, and hey, that’s how learning gets done, right?

Having installed a buggy 2.1 pre-release for my Eris, however, I can assure you that it is unacceptable to erect this barrier for the everyday user. As someone who needs his phone for business as much as pleasure, I absolutely don't care about recovery images, "L33tHAx0r-Alpha13-RC2" custom ROMs or NANDroid backup routines. I simply want a device that does what its supposed to when I need it to.

Picking Up the Pieces

Despite the negative slant this post has taken, I do believe there is hope for the platform. As a developer, I will probably be unable to shake my excitement for the Android platform, I will probably continue to support it and, despite my better judgement, use it. The ability for anyone to hop in and start hacking not only on the OS core but their own applications is huge and should not be downplayed, especially given how their competitors have handled third-party development.

I do think there is hope for the platform from a user perspective as well. We’ve already seen Google scaling back the relentless pace at which their API is being modified, perhaps because it is now (finally) of sufficient quality to be called “production ready.” From here, Google needs to aggressively pursue homogeneity of the ecosystem, pressuring handset manufacturers to upgrade their current solutions to Android 2.1. They also need to provide a simple, clear upgrade path to Android 3.0, and establish rollout dates that handset manufacturers must adhere to if they wish to stay relevant in the Android Market.

Android 3.0 absolutely must include some kind of task management metaphor, allowing users to easily control which apps are running both at boot time and during normal usage. Google’s applications should be tested and working on all versions of the platform until such time that they have managed to homogenize the ecosystem, and should maintain a baseline of functionality (copy-paste in all relevant apps, for example.)

The battle for mobile supremacy is far from over, and with Windows Mobile 7 and iPhone OS 4 on the horizon, it would appear that it is just starting. Google would do well to take its licks now and refocus before its user base starts to flee the scene for other, more consistent offerings.

Stop complaining and start refining!

Increasingly, I feel the long-lived desktop model is a poorly implemented one. Anyone who has relatives with computers should attest as much. My grandmother called me once because she couldn't find her files ... it turns out she had simply saved everything she had ever done to the desktop, until the desktop had run out of space, stacking files on top of files and rendering them un-clickable.

Now, in my Gentoo days, I would have (and probably did) rail on her. How does lack of user training somehow reflect on a system's performance? "Gosh," I would say, "how can someone not understand something as simple as a hierarchical filesystem?!" One of the more transformative things that has happened to me is overcoming this attitude. Nobody worries about using their microwave because they're "going to break it", and yet this is a common concern we hear about the desktop. I feel we as developers and HCI experts have failed users every step of the way for over thirty years. We should be literally ashamed of what we have allowed computing to become.

Gizmodo would go on to put it in more concrete terms for me, describing what an HCI expert from the 70's named Jef Raskin called an "Information Appliance." I thought the description brilliant: a device that could immediately transform itself to be purpose-built to any task. Gone was the stress of being surrounded by ten attention-demanding windows floating on top of a hierarchical filesystem; what we were left with was a device that was good at everything, just when it needed to be. In retrospect, it was this power that initially attracted me to the iPhone. While my interest piqued only after I could develop for it, I immediately understood the potential of the decision.

So too was I pleasantly surprised when Apple announced the iPad, but the potential this time seems greater. Instead of challenging meek opponents* in an underdeveloped market like smartphones, Apple now has laptops and netbooks in its crosshairs. They intend to expand this brilliant metaphor to increasingly robust devices. Yet off of it hangs one terrible caveat: the App Store.

As an iPhone developer I've been there: the ludicrous provisioning profiles, the vague app store rejections, the $100 per year fee just for the privilege of riding the new wave ... it was enough to make Joe Hewitt leave the development scene, a terrible loss for the community. Despite its shortcomings, however, I cannot bemoan this decision too much. I understand the desire to provide a user with a cohesive, consistent user experience. Apple has done it best for years and it continues to do so now, with the App Store acting as a very public way to muscle developers into thinking like Apple wants them to. "Most people" will benefit from this decision, and for that I can't fault it.

However, claims of a dystopian future where Steve Jobs beams Apple-approved software into our heads are knee-jerk reactions at best and deceptive FUD at worst. I'm not saying that the app store is necessarily the most healthy decision ever made in computing history, but diversity will never disappear. Open source projects like Google's Android, companies like Dell, Asus, and HTC ... they are making the same strides as Apple, but in a significantly more transparent manner. Nokia's N900 is probably the most "open" device you can buy, and from what I understand it is doing quite well with the Linux/hobbyist crowd. Palm's WebOS has its own application portal, and brings with it one of the best user interfaces available on an embedded device. This market space is literally booming right now, and we have focused our attention solely on one device and declared it the devil.

This sort of vilification is, in short, wrong. We should be applauding their innovative approach, attempting to learn from it and refining it. It is my opinion that Android has done exactly this from the get-go. Many parts of the interface feel pleasantly reminiscent of my time with the iPhone, and yet the notification bar and multitasking bring back important elements of a powerful user interface. I'm extremely excited about the future of embedded computing with Android at the helm, just as I'm excited about the iPad and its potential transformative effects.

Rather than being afraid of new technologies, or dismissing them outright, we need to look at the bigger picture of what these devices bring to the table and how it could potentially impact how we interact with computers. The iPad is a great start, but we need to keep pushing, refining, tuning, and enhancing the user experience for everyone, "end users" and "power users" alike.

* If you honestly believe that RIM/Blackberry was moving in the right direction, you and I need to have a long discussion so I can ascertain exactly what people see in those devices. My experience with them has been so lackluster I can barely remember using them.