Originally published in Econsultancy on January 25th, 2013 â‡’
For many years since its release, the Android OS has been behaving like a teenager in the grip of raging hormones. Growth has been nothing short of explosive and the changes have been sweeping and profound.
With the release of Ice-Cream Sandwich OS, the UI standards and design elements have changed dramatically and the platform has really matured and even stabilized somewhat.
Nevertheless, the OS has retained itâ€™s rebellious hacker DNA with unique features that are authentically Android.
Welcome to Flatland
The first thing you might notice when comparing the Android OS apps with the other mobile OS is that the world of Android apps is flat. Flat are the buttons. Flat are the content areas, and flat are all the toolbars and controls.
As the Flatland people in the Rudy Rucker story of the same name, Android does not â€œseeâ€ anything outside of two dimensions. Nor does it pretend to be anything other than a pure digital artifact: a thing imagined and created, not real in any physical sense.
A piece of software that runs the hardware, not the other way around. And that, as far as I am concerned, a very good thing. Why? Because dispensing with the need to make things â€œrealâ€ and â€œprettyâ€ allows the content to shine and sets a stage for the authentic minimalist digital experience for your customers.
Compare for example the Android Messaging app with the iOS counterpart.
Figure 1: Messaging apps: iOS vs. Android 4.0.
The first thing to notice is the information density: there is a great deal more content crammed on screen in the Android app. Part of the reason is that the iOS is using the â€œspeech bubbleâ€ representation of the message, whereas the Android app is simply listing messages in the table.
Boring? For some folks, perhaps. However, Android makes no excuses, no decorations, the app is a straightforward, flat, and highly functional SMS machine. The overall visual scheme is very reserved, almost corporate.
Notice also the toolbars: iOS dictates that the toolbar elements have a three dimensional quality that makes the elements seem to pop off the page. This is achieved with the gradients that help digital objects like toolbars visually approximate the physical world.
In contrast, the Android toolbars, and indeed the entire page is decidedly one dimensional and completely free from having to look like a physical object. Unabashed embrace of flatland and â€œfreedom from three-dimensionsâ€ opens the door to creating menus that are semi-transparent, and commit fully to the â€œcontent-firstâ€ directive.
Figure 2: Semi-transparent menus of Android 4.0 (Google Earth) vs. the physicality of iOS menus (iPhone).
The entire Android screen is built with gray-scale, using just enough color to make the toolbars a bit darker, while the content areas mostly remain light.
Color is one area where many other mobile OS, such as Windows Mobile contrasts strongly with the Android Ice-Cream Sandwich OS. Even though both have flat gradients, Windows Mobile veritably explodes with both color and interactivity, homescreen literally â€œpoppingâ€ with movement, as each element vibrates, flips and slides with clever transitions and contrasting color combinations.
In contrast, a typical Android screen looks very compact, serious, business-like, providing only the essentials: exactly like a typical wireframe. Even more interestingly, this â€œflat worldâ€ scenario applies to buttons and tap-targets. Android â€œbuttonsâ€ also have no gradients â€“ which is the subject of the next section.
In the early days of using the mainframe workstations (that was a very long time ago) I remember being stumped when first seeing the message â€œTap any key to continueâ€¦â€.
Programming was such a precise discipline (especially for me, because typing was always such a challenge) that it seemed inconceivable to me that any key would work.
Besides, I was stumped: I understand that I can tap any key, but which is the best key? Is one better than the other? Of course the confusion quickly passed, and I learned to enjoy the freedom to just jam anywhere on the keyboard without having to think very hard, most of the time just hitting the space bar with my thumb.
Android takes buttons to a whole new level. Whereas the iOS painstakingly identifies any tap-worthy element with the three dimensional beveled button, Android simply assumes that any element on the screen is a tap target, often providing no additional clues.
Compare for example an individual message row in the messaging app: the iOS implementation provides the beveled round circular â€œright caretâ€ button, (>) whereas Android in contrast providesâ€¦ Absolutely nothing.
Figure 3: Android 4.0 vs. iOS table rows.
The customer has to figure out that they can simply tap anywhere on the element itself (that is anywhere in the row) to get more information.
If you may possibly want more information about something, than you should be able to tap it. In other words, Android trains the customers to simply â€œtap any key to continueâ€.
That same â€œtap anywhereâ€ visual design principle finds its ultimate expression in the typical Android â€œbuttonsâ€, which are implemented instead as â€œtap-worthy areasâ€ (to borrow a favorite catch phrase from the mobile design expert and book author, Josh Clark).
Notice that the iOS takes the time to make sure the buttons look and â€œfeelâ€ tap-able with an elaborate combination of a prominent bevel, inner drop-shadow and gradient.
Figure 4: Android â€œTap-worthy Areasâ€ vs. iOS beveled buttons.
In contrast, Android commits whole-heartedly to the â€œTap anywhereâ€ approach, using areas instead of buttons with just a hint of a vertical separator.
This underscores the Android theme of not defining rigid border areas for tap targets. This theme is profound, because in itâ€™s purest expression this means that everything on the touch screen is a touch target.
For designers, this is both a challenge and an opportunity. A challenge because without a primary or secondary tap targets, a consumer might be justifiably confused about the â€œtap any buttonâ€ scenario: â€œif you can tap anywhere, which area is the best one?â€ The â€œTap anywhereâ€ scenario also presents a hefty challenge for designers and developers: everything that the customer would conceivably want to touch, should be responsive and do something intuitive.
â€œTap anywhereâ€ is also a tremendous under-exploited opportunity to introduce accelerometer gestures, multi-touch and â€œhiddenâ€ menus that promulgate the â€œcontent-forwardâ€ design and promote immersive digital experiences. This is an extract from my new book, Android Design Patterns: Interaction Design Solutions for Developers (Wiley, 2013).