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

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

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.

Tap anywhere

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

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

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. 

Additional Information

“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) now available for pre-order at http://AndroidDesignBook.com.