What I Hate About Android

Jon Bell observes the major issues with capacitive touch buttons on his blog Designdare. TL;DR you can press them when you don’t want to press them and that sucks.

Android phones feature a set of hardware buttons across the bottom: Back, Menu, Home, and Search (not necessarily in that order). Home functions like the iPhone button of the same name, ripping you back to the “desktop” screen. Search gives you a global search which grabs at contacts, apps, emails, and other data functioning like a (slow) double click of the iPhone Home button. Menu is actually rather clever, it functions as a neat way to hide a set of contextual commands offscreen. The problem I have is with the Back button, not so much its existence but its implementation.

The issue is inconsistent function, that is, when I press the Back button more than once it’s hard to know where it will take me. The reason for this is rooted in the philosophy behind Android’s app management and multitasking. On Android you can open an app and then open another app while the first remains open. This creates the possibility of going back to the first app. But Android doesn’t actually see apps, rather it sees parts of apps called activities. An activity is a small part of an app, for example message composition might be an activity in a twitter client app. The Back button takes you back not to your last app but your last activity. As you move from app to app your chain of activities flows behind you like the light off a Tron motor bike. The Back button can take you back through those screens. Sometimes however I want to go back in an application’s local sequence (from compose message to contacts list for example) and end up instead moving back globally and out of my application altogether.

Our reader Roger does real work and so people send attachments to his email. Sometimes he wants to save those attachments to his phone. When he had Windows Mobile this wasn’t a problem. Enter Android.

Working with attachments requires third party tools. Be careful which you use though, Roger’s file manager allowed you to delete the file extension leaving files unusable and inaccessible.

Occasionally, Roger even wants to send an attachment (for example a word processing document) but that functionality isn’t in the default email and Gmail apps. Luckily, according to Android Community user RoidRage, “there’s an app for that.” I can only hope that all basic usability problems are fixable with $3 investments. I may run out of screens though.

Digging further, attachments get quite the cold shoulder on Android:

• .Wav attachments won’t play (again solved by a $3 app)
•  Forwarded emails are stripped of attachments (blackberry handles it better)
• Attachments of 1Mb won’t send
• Sometimes Android even botches the attachments it can send

Droid Does. That’s the slogan right. It’s supposed to mean Android is more like a computer than the dinky iPhone. It doesn’t limit what you can do.

Well, I noticed something interesting while fidgeting with a mail reply in the GMail app. The message which I was responding to would get stuck into a static label and present me with a input field to respond.

What’s this? I often break a quoted email apart so I can reply point by point. If it’s a long thread I simply delete all but the most relevant bit. These things become impossible when the text is trapped in it’s un-editable prison.

Now I know that a lot of people see Flash support as a feature, and in a world where code was clean and plugins were written like sonnets it would be, but we live in an imperfect world. I’d prefer a more stable browser that isn’t graced with the ability to render shoot the duck advertisements.

“Good thing I didn’t get an iPad; ‘Cause this one does Flash.”

Update: The delivered Flash Player is not acceptable and doesn’t deliver the promise of “the full internet”

Android should be focused on user experience not technical implementation details. Nothing shows that this isn’t true better than the developer documentation.

iPhone has big screenshots illustrating interaction patterns and proper application design. My favorite section is “Application Controls” in which each control description is illustrated by not only a screenshot but a screenshot of it being used in an application context. When one looks up a widget on Android you’re more likely to get a chunk of xml than a screenshot.

Only one section of the Android developer site uses images to good effect. That is Resources, a strangely named (isn’t the whole developer site a resource?) but very helpful set of illustrated introduction articles.

http://www.droiddraw.org/widgetguide.html is down the line of my thinking but it’s outdated and poorly laid out.

Why does HTC ship phones with a trackball when they look so dinky and outdated? Why does the Droid have a directional pad? These phones have touch screens so what’s with the analogue input? The only reason I can see is that Android doesn’t have a good method for refining text selection. On iPhone a tap and hold brings up a loupe that lets you carefully tailor your selection. On Android you just have to tap again, carefully this time. That or use a trackball.

The secret to good open source software, developers say, is fast iteration. Android, in this sense has been a very good project, reaching 2.1 almost within 2 years of it’s public launch. The issue is that phone manufacturers and carriers haven’t kept up and over the air (OTA) updates seem to be a thing of fairy tales. They’re working on a solution but it won’t do much for those stuck with stale versions on otherwise new phones.

To update an app on Android you have to open the market app, switch to the list of available updates, click through to the app you want to update, and tap update. The App Store has an easy solution to this repetition: an update all button. Judging by the stars and “me too” comments on Issue 4817 this is a point of friction.

Fixed in 2.2 (FroYo) When this will ship to devices is yet to be seen but the functionality exists.