I am currently designing an Android application for our Ponzu Conference system. I have already outlined the design for an iOS app, and I am doing the same for Android.
This has actually been quite challenging. I understand that native applications should adhere to the guidelines for each respective platform, and that we should not try to force iOS UI conventions towards Android users. For example, I intend to follow the Pure Android guidelines. However, there are times where the Android guidelines completely collide head-on with my web-design experience and it hurts. In the following, I will describe my struggles with “discoverability” philosophies.
Jared Comis wrote a blog post “When designing for Android, forget iOS” where he displays design conventions for iOS and Android side-by-side. It is a great post for understanding how to convert a design to Android, but it also illustrates how Android and iOS approach the same problem. I’ll give a few examples pertinent to the issue of discoverability.
Spinners to switch views
Jared writes;
Yet another usage for Spinners is to switch views on a set of data. A spinner being used for this purpose is in the calendar app where a spinner allows for easy switching between day, week, and monthly views. This behavior of spinners is more closely related to segmented control element on iOS.
The difference here is;
- Android’s spinner approach hides each option until the user clicks on the control. The options are only available after the menu has dropped down.
- iOS’s segmented control approach exposes each option before the user interacts with the screen.
- Android’s spinner approach allows more items to fit with more descriptive titles. On the other hand, iOS’s segmented control requires that the developer uses short titles and restricts the number of options.
Tab navigation
Jared writes;
A second unique quality of Android tabs is the ability to use scrollable tabs. This modified version of the standard tab bar enables for 4 or more tabs to be comfortably used in an app. iOS guidelines recommend up to 5 tabs, or when 5+ are required 4 plus a “more” tab to see the remaining options. An example of scrollable tabs in action can be seen in the Play store app.
The difference here is how each platform indicates to the user that more items are available.
- Android users would notice that there are more items if one of the tabs was clipped on the right edge of the screen. Otherwise, they could try to scroll the tab bar; if it moves, then there are more tabs.
- iOS users immediately know whether there are more items available thanks to the “more” tab. This adheres to “progressive disclosure” principles. Note that this tab does not have to be implemented by the developer. It is automatically added by iOS when there are more than 5 tabs.
Overloading of the spinner
In Android, the spinner can be used for a variety of tasks, each of which is satisfied by separate controls in iOS.
Data selection in forms
Selection of actions from a list
Switching views on a set of data
Jared writes;
Spinners are a versatile and can be used in many different situations.
The other side of the coin is that users will not understand what spinners will actually do. Even after the menu drops-down, they will not know whether clicking on an item will invoke data selection, an action, or a view switch. They have to read and understand the item labels to understand what will happen.
Navigation Drawers
Android has also introduced a relatively new UI control called “Navigation Drawers” (“side-navigation”, “hamburger menu”).
According to Google’s documentation;
The navigation drawer is a reflection of your app’s structure and displays its major navigation hubs. Think of navigation hubs as those places in your app that a user will want to visit frequently or use as a jumping-off point to other parts of the app. At a minimum, the navigation hubs are the top-level views, since they correspond to your app’s major functional areas.
Hence their counterpart in iOS would be the tab bar at the bottom of the screen.
The navigation drawer UI control has been criticized for lack of discoverability. In fact, Google’s documentation itself recommends customizing the first launch of your app so that users will be forced to discover the contents that you have hidden in the drawer before they can interact with the application. It’s a pretty drastic remedy for the discoverability issue, and as such, the logic for when to show the drawer or not is rather complex.
Upon first launch of your app, introduce the user to the navigation drawer by automatically opening it. This ensures that users know about the navigation drawer and prompts them to learn about the structure of your app by exploring its content. Continue showing the drawer upon subsequent launches until the user actively expands the navigation drawer manually. Once you know that the user understands how to open the drawer, launch the app with the navigation drawer closed.
Fortunately, this behavior is provided in the templates in the SDK so developers don’t have to implement this logic themselves.
Discoverability is not a priority for the Android UI
From these comparisons, it is extremely clear that the Android UI does not place discoverability as a priority. Many controls hide their options behind in menus, page boundaries and drawers that are only revealed when a user interacts with them.
In comparison, iOS does prioritize discoverability. In doing so, they put the burden on the developer to come up with short descriptive labels and to cut down the number of options. When the developer cannot reduce his options to 5 or less, then iOS demands that the developer choose the 4 most important ones and confine the rest to the “more” tab.
I am not sure why Android decided to de-emphasize discoverability. Maybe they wanted to make it easier for developers, so that they don’t have to make the hard choices that are required on iOS. Concealing options in menus and drawers has the effect of making the small screen of smartphone matter less; you can still have as many options as you had on your desktop website.
My hunch is that it is a philosophical issue. Apple values the care and consideration made into crafting a product. This is not only about software but also about the editorial and copywriting efforts that you put into it. The iOS-way demands that you think very deeply about your content and are authorized to restructure it. On the other hand, Google is more single-minded into technical aspects. Hence they try to allow you to create software without having to rethink how content is organized and categorized; that job is for the non-techies whom Google is reluctant to rely on. The Android-way allows you to create satisfactory software with the techies alone.
Coming from a web development background, exposing users to the structure of your site and ensuring that users immediately understand what your site can do was always a priority. Discoverability was always a priority. Therefore, it was very difficult to accept the Android UI way. It conflicted with my understanding of what a good user interface was. It hurt.
I now think that in order to understand the concepts of Android UI design and to accept the Android way of thinking, you have to let go of discoverability. Forget about it. Don’t let it drive you design decisions because if you do, you’ll face the dilemma of either it or pure Android.
Don’t worry about articles like this that make the obvious conclusion that “out of sight is out of mind”.
Naofumi Kagami 