Why MG Siegler Hates Android
Why do I hate Android? It’s definitely one of the questions I get asked most often these days. And most of those that don’t ask probably assume it’s because I’m an iPhone guy. People see negative take after negative take about the operating system and label me as “unreasonable” or “biased” or worse.
I should probably explain.
Believe it or not, I actually don’t hate Android. That is to say, I don’t hate the concept of Android — in fact, at one point, I loved it. What I hate is what Android has become. And more specifically, what Google has done with Android.
Phoning it in: Why Google Wants Out of the Phone OS Race
This post, as a piece written for this personal blog, is designed to be sensationalist. As with all of my posts here, opinions expressed here are my own, not my employer (or friends, for that matter). The posts are designed to stir discussion and start a conversation; this post is no different.
If you haven’t had a chance to glance at the title of this, please take a moment to do so. Notice that the post isn’t that they do in fact want out of the race, but that they seem to provide a list of reasons as to why that conclusion may not be entirely fantasy. I’d like to list these as a pseudo-editorial, as both an argument and therapeutic exercise.
Before I delve into this flame-bait further, allow me to preface this with a secondary disclaimer: I’m an Android fan through and through. I’ve been experimenting, using and developing on the platform since it was initially released. I’ve used the emulator in all its stages (beta to 4.0), owned and loved two kinds of Android handsets—and gone through four Android phones in the process. The platform has novel concepts to develop within and experience as a user, and many of the new changes in Ice Cream Sandwich are exciting. I like Android.
With that said, the ball was dropped months ago, and no one seems to have noticed.
Unpolished Press Releases: I first formed this opinion after the ICS / Galaxy Nexus press conference in Hong Kong, on October 18th, 2011. The lackluster presentation, demurred excitement and horrible video quality led me to believe that Google was happy to take a backseat for Samsung. This is the legacy of the Nexus One, after all, the phone that was to change everything about buying and owning phones. That phone was designed from the ground up by both HTC and Google, too. I can’t feel the same way about the Galaxy Nexus. I mean, Nexus even takes a backseat to Samsung’s over-used Galaxy branding, and seems to reuse many components of the Galaxy S line.
Embarrassing Support: Combined with the atrocious number of orphans Google allowing to be left behind, is leaving me concerned about future purchases as a user, and confused as a developer. I’ve built AOSP. I’ve run my own compilations of CyanogenMod with custom modifications. I’ve done these things as a coping strategy when it was unclear if the Nexus One would be granted official support for Gingerbread. This was without a clear or adequate explanation, mind you, as Android 2.3 contains no technologically advanced changes to bar any 2.2-capable handset. It isn’t clear to me why phones aren’t being updated the moment the AOSP tree is updated. Oh wait, it’s due to carrier and manufacturer modifications that no one likes, or simply just a shirking of duties.
Google, as a customer and maintainer of its own Android OS, ought to be in control of how Google-loved devices (that is, those that receive the Android Market officially) are supported. News about a minimum support program came at Google I/O 2011, nearly three years after the first Android handset was released (October 2008). I’ve heard nothing about this program since I/O. It’s interesting to see that CyanogenMod, at the time of this writing, supports fifty devices.
Clandestine Releases: Google, in its infinite wisdom, has often released products with only questionable scoops on blogs or other news outlets, without building the serious fanfare one other company is capable of. The leaks before the final release of the Nexus One were ridiculous, and also surreptitiously stole the limelight from the Motorola Droid/Milestone, released only three months prior, totally alienating early adopters. The same thing is about to happen with the Motorola (Droid) Razr and the Galaxy Nexus. Why didn’t Motorola, soon to become part of the Google fold, not get a peek at ICS for their new flagship? Why is HTC determining their upgrade plans after the ICS press release? These giant manufacturers—pillars of the Open Handset Alliance—are kept in the dark about a product that is being built by the organization they’re a part of.
Late or Missing Source Code Releases: Honeycomb will never appear in the AOSP source tree. It was initially assumed that it was merely late, like Froyo or Gingerbread. After no official response from Google for so long, we now have answers such as from Matias Duarte’s interview with This Is My Next:
On Honeycomb we cheated, we cut the corner of all that smaller device support. That’s the sole reason we haven’t open sourced it.
I’ve heard from other comments from Google staff that the code is just too messy to be released, as APIs are unclear or whatever. How did Honeycomb get released to consumers at all then? Was it really the knee-jerk reaction to the iPad we all suspect it is? Six million in Android tablet sales says “yes” to me. I’m not holding my breath for ICS to appear in the AOSP tree.
Another interesting point here involves the downtime of kernel.org. AOSP’s most well-known location was unaccessible for weeks. Google obviously had a backup, as the development process is closed, but chose to do nothing in terms of providing a mirror until much later. Now that kernel.org is coming back up, there is talk of providing an alternative to that canonical hosting.
In summary: I’m not pleased with the Android legacy Google is creating. These problems, however large they may seem, can be mitigated if Google feels like taking point. Rather than the silent observer (whether that’s true or merely the appearance they make), they can dive into maintaining a line of truly Google-blessed handsets, ones without heavy manufacturer modifications and with clear support cycles. The Nexus line is too young to cite as an instance of this, as it should be more than just one manufacturer favourite at a time. I must say that as a consumer, all of the court cases of Apple v. Samsung decidedly cheapen their products.
The good news is that most of the “wow” factors of Android are the (closed-source) Google apps, such as Books, Docs, Gmail, Goggles , Google+, Maps, Market, Reader, Talk, Translate, Voice, and Youtube. For a platform where “all applications are created equal,” there sure are a lot of first-party apps, but these are well-designed and work on just about every device very well.
It remains to be seen if Google knows about / cares about / is already fixing the problems described above. As a developer and “expert” user, I’m awaiting their decision, but it feels like we’re in for a tough winter of growing pains.
Making the Best Use of Your Tools
I’m a huge fan of video games. The other day, I finally got a chance to sit down with the demo for The Gunstringer. I’ve been looking forward to this title since it was first announced, and downloaded it when it was released but never tried it. First off, I was able to sit down with the game rather than stand, which is unique to the title! That was a pleasant change, as most of the other Kinect titles I’ve played involve some form of mild gymnastics, and aren’t designed to be played for long periods of time. The uniqueness of this Wild Western game doesn’t stop here.
The game makes use of your left hand to manipulate an onscreen puppet, moving him left and right, and firing his gun with your right hand. The puppeteer aspect suits the Kinect platform particularly well, and in my opinion much better than moving an onscreen figure with your whole body—the Kinect sensor just isn’t slick enough to grasp complicated movements (such as when limbs cross). The illusion is broken the moment the avatar does not act as you do. In The Gunstringer, however, the movements are simple enough—and each hand moves differently enough—that it’s a fluid and consistent experience to what you’re doing with your body.
How can this argument apply to other platforms and experiences? In the smartphone space, we’ve all seen the trivial accelerometer-and-compass games: replicating labyrinth tilt puzzles, fake spirit levels and tilt-to-steer racing games are a dime a dozen. Can we do better? Yes: augmented reality apps like Layar are pushing the boundaries of what you can do with a sum of precise and powerful sensors like accelerometers and compasses. What else can an always-on Internet connection, Bluetooth, NFC, state-of-the-art GPS, ad-hoc Wi-Fi, accurate gyroscopes and multi-megapixel cameras do? More like, what can’t they do.
Returning to The Gunstringer, it brings a simplified puppeteering concept to the Kinect but does not limit gameplay to what’s possible with a puppet on a string. Your right hand, remember, controls the avatar’s gun. This is done by mimicking the firing of a pistol with heavy recoil. I even found myself making a gun shape with my hand while I did this, and thus the game had won me over. I’m not alone in that feeling. The Gunstringer’s puppeteer mechanic was streamlined such that it did not limit the game as it was adapted for the platform.
Now that the gimmick of the Kinect hardware has worn off, I’m looking forward to titles that make use of the platform in unique ways, as The Gunstringer has. I know they can do better than the sports games and dance games, and create an experience full of intuitive gestures and unique experiences.
Many times, the adaptation of a physical concept to digital ruins the experience. The perennial example is the calculator: why click buttons that resemble a real calculator with a mouse? Why not allow direct text entry, and skip the buttons? Why limit the number of digits visible, as the old liquid crystal displays of old did? When picking an experience to model your digital creation from, take only the experience, and leave behind the limitations of the medium. When designing, try winnowing the chaff that weighs down your experience.
Attitude and Tone Are King
With the explosion of applications and brands, I, like all humans in commercial society, have gravitated towards preferring some over others. In other news, the sky is blue and water is wet. I’ve found myself really enjoying using and discussing these applications with my peers, trading information about how to better use a product, or which one to switch to, even defending one over another.
Why do I like talking about them? Why should I bother giving them the free publicity and advertising? It’s not always a conscious decision. Websites I do this with seem to share the following in common:
Informal language: The language used in the applications reflect the informality and anticipated use. Groupon, for example, uses informal, sometimes silly lingo, filling in what I would expect to be boring legal gobbledygook with humorous jokes and quips. This works in a positive way to support the fun environment the site is trying to create. Look, they just got another bit of free advertising because of it.
Not using formal, complex or highly technical wording lends personality—and even credibility—to the site. It feels like there are humans on the other side of the application, and they seem more honest.
Encouraging commentary: If a site or application has a lot of features, users can’t be expected to read a manual. Coaching users to do the right thing, or providing simplified instructions at the tricky parts can solve the problem. Being silly or extra helpful in a playful tone is less serious, but sometimes that’s ok, depending on the intended users.
After submitting a post on Google+, the service offers an encouraging “Nice post!” message, along with some tips for editing typos or changing sharing options. They could have offered the same functionality via terse links before posting, but instead offer the information like a friend sitting next to you. It also encourages uses to amend information after submission, meaning mistakes are ok. Their target audience—at least during the open preview—are technically savvy Internet users, so this sort of post-action coaching works great.
In summary: if the target audience isn’t policy writers, lawyers or super-serious engineers, deliberately lending humanity—and readability—to the site’s copy text in the form of informality is a great way to befriend users, and also get the point across without causing users’ eyes to roll back into their skulls.
Selecting the Right Input Method for Mobile Users
As applications move to mobile, the context and intended usage change. You can’t expect a swiss-army knife of a desktop app to provide the same functionality on an iPhone or Android device. This is already well known, and there are many blog posts and books and courses on this topic. It’s great for users, because well made mobile apps are tailored well to the mobile lifecycle they need to survive in.
When it comes to input methods on handheld devices, the same rules apply. You can’t expect a standard desktop date-picker to perform well on a touch-only screen. That’s why controls like the iOS UIDatePicker are so wonderful: they translate the desktop task to mobile. Some of the functionality is lost, however; in the date picker, showing which days are weekends doesn’t translate to the iPhone at all. These reductions streamline the process on a device dealing with a far lower attention span.
If you have the benefit of selecting the input methods for the app you’re designing, take to heart exactly what the intention of the input method is for. This includes your target users, attention span and amount of user effort. An expert user might be willing to use a hard to use but accurate input method some of the time, but if the usage scenario includes using the app while rock climbing, you’ll need to select an easier to use method, at the cost of precision.
In the Winter 2011 term of my PhD program, I took Robert Biddle’s course on Human-Computer Interaction for User Interface Design. I ran a preliminary user study comparing different touch-screen input methods for numerical input. I compared the two commonly found input methods of increment/decrement buttons and seek bar with thumb against the more whimsical method of a rotary dial—like a volume knob. The seek bar was the only absolute-scale input method, so values that users selected fell within the entire range of the seek bar used. Users “spun” the dial clockwise or counter-clockwise to increase or decrease the value for selection.
The study actually ended up revealing an interesting result: the timing to select a value with rotary dial wasn’t statically significant from the buttons or seek bar. Anecdotally, users preferred the dial as an input mechanism due to it’s perceived ease of use. While very common, especially on Android, dragging a thumb across a seek bar requires more concentration. Personally, I feel that buttons are simply tiresome and dated.
Think carefully about what emotions your input method of choice evoke. If you want a fun or highly interactive application, losing some precision might be okay. More serious or rigorous applications have different design constraints too. Simply going with the default input method for your platform of choice is not always the best idea.
The dial lives on, if you’re interested. A good friend of mine, David Underwood, has adapted my simple testing dial in his Magic: The Gathering life counter, Life Dial. Eventually, we’ll get around to releasing source so you can add it to your own Android apps.
