Jun 2014 – Page 2 – Naofumi Kagami

iOS and Android Design Philosophies

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.

Tabs

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”).

NewImage

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.

NewImage

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”.

Android SDK Evolution and Confusion

While studying the Android SDK, I learnt that Android provides two separate methods to switch screens. You can either switch using Activities or by using Fragments. The problem is, it is not very clear which method you should use.

For example, you get this question on Stack Overflow, “Dilemma: when to use Fragments vs Activities”, and it gets closed because it is considered to be entirely based on opinion.

Another Stack Overflow question “android – need some clarifications of fragments vs activities and views” was not closed, but still illustrates the complexity of this issue.

It’s truly annoying that programmers new to Android have to go through this early on.

Fragments were introduced when Android started to support tablets with Android 3.0. In my opinion, the co-existence of Activities and Fragments with overlapping functionality is a result of the rather ad-hoc way the platform has evolved.

Android Design Guideline Nonsense

Apple’s Human Interface Guidelines have historically been held in high regard, and they are considered to be required reading for anybody in mobile development, regardless of platform (iOS, Android or even the mobile web).

Google also has some guidelines for Android. They question is, are they any good? Are they good enough so that we should try to adhere to them whenever possible, or are they actually so confusing that we should actively steer away? Without a proven track record, this is a pertinent question to ask.

Which brings me to this blog post “Do Android UI guidelines really make sense ?”. I recommend that you read this. I have also noticed this awkwardness in Android’s UI, almost from the very first time I touched one. I had not idea that this was not just a mistake, but something that was strongly advocated for.

Problems Using Tabs Instead of Navigation Drawers in Android

A few days ago, I wrote about how the Navigation Drawer (side-navigation or hamburger menu) was removed from the Facebook app and was seemingly going out of vogue. In the case of Facebook, they used a Tab Bar in an implementation that was almost identical to how iOS has been using it (in the clock app for example) since the very first iPhone. This implementation is the default behavior of the TabBarController in the iOS SDK and is ridiculously easy to set up.

For the Android app, Facebook used the Tabs UI element in the Android SDK in a way that mimicked the TabBarController. This is not the way Google has been using it in their Google Play app for example, but it isn’t much effort to get it to work. Their result is the following screen shot.

However, there is one important deviation from the implementation in iOS. That is the icons do not have any descriptive text associated with them, so you have to understand what each button does from the icon alone.

NewImage

Compare this to the iOS app (below). In the iOS app, each icon has a descriptive text label which makes it easier to understand the function of each button.

Although I cannot claim to have a good understanding of why this is the case, I have observed the following which is likely relevant to some degree;

The iOS SDK makes it very easy to add miniature text below the icon to aid users who are unfamiliar with the icons. You simply write the text in a field in the graphical UI design software. It is important to note that this was available since the original iPhone with its 3.5-inch non-retina display, which suggests that Apple viewed the text as a necessity for users unfamiliar with the icons.
The Android SDK makes it similarly easy to add text. However, instead of placing miniature text below the icon, the Android SDK simply adds regular sized text to the right of the icon. This makes the button much wider, and in the case of the Facebook app, you would no longer be able to fit the five buttons.
This is of course quite easy to fix. For example, you could simply add the miniature text to the icon graphic file. It is unclear why Facebook decided not to do this since Facebook generally adds text whenever possible to their icons to clarify their functions. It is unfortunate though that this issue discourages developers from adding text.

NewImage

Summary

The Android SDK has provided Tabs which allow applications to mimic the behavior of iOS TabBarControllers. However, they have omitted an important feature that would have made it easier for users to understand and explore new features.

In my own development, I doubt that I would ever use my own custom icons without explanatory text. On the other hand, I would also never let a tab bar overflow so that the user has to scroll to see all the tabs. I’m also very hesitant to use a Navigation Drawer because this creates an “out of sight, out of mind” situation and is very bad for discoverability.

Wither Navigation Drawer?

I’ve been thinking about mobile app design for our new Ponzu iOS app.

I’ve noticed that the Navigation Drawer has been removed from the new Facebook app, and instead, they are using either the native Tab Bar Controller in iOS, or Tabs in the Action Bar for Android. Let me explain.

Facebook changes

I’m using images I got from the web instead of my own devices, because I’ve already updated them to the newer versions of the Facebook app.

Previous Android Version

NewImage

The hallmark of the previous Android version is the “Navigation Drawer“. This is summoned by clicking the button on the upper left of the screen with causes the top view to slide to the right, revealing a menu list (right image).

On the left image, you also see use of drop-down menus from the Action Bar (the top bar). Interestingly, these items on the Action Bars are also included in the Navigation Drawer, creating redundancy.

The Navigation Drawer pattern was invented by Loren Brichter and was popularized by Facebook. Since then, it has been included into the Android SDK so any Android developer can easily use it, and it has been used extensively in mobile optimized web sites.

To see why Google thinks that this is a good navigation pattern, see their documentation. They basically use it at the root-level in the app’s navigation hierarchy.

New Android Version

NewImage

In the new Android version, we can see that Facebook has totally ditched the Navigation Bar, and instead are using Navigation Tabs within the Action Bar (a more graphical example).

This navigation scheme is very similar to Tab Bars in iOS. Tab Bars have been supported in iOS since the very beginning (iOS 2.0). Android used to have them as in iOS but they don’t seem to be actively supported in the SDK any more.

NewImage

In fact, Facebook is using Android Navigation Tabs within the Action Bar in a manner that is much closer to the iOS Tab Bars in comparison to how Google is using them in their own apps. In Google’s apps, Navigation Tabs are typically present only at a high-level of the navigation hierarchy. They disappear as you move deeper into the application hierarchy. On the other hand, iOS Tab Bars are always present, providing the user with a global navigation element. In Facebook for Android, they put Navigation Tabs on every page, much like how iOS works.

Summary

In a nutshell, Facebook has ditched the Navigation Drawer pattern that it popularized. Instead it has migrated to the Tab Bar navigation pattern that was present since the very first iPhone.

This really shows how much thought went into the original iPhone UI, and how much they got right the first time.

As for reasons why the Navigation Drawer was not a good idea for Facebook, let me give my thoughts;

To serve as a global Navigation Element, the Navigation Drawer has to be present at all times. However, the position of the Navigation Drawer button is the same as the “Back button” (or the “Up button” in Google’s weird terminology) and hence the two cannot coexist. If you want to display a “Back button”, you can’t display a Navigation Drawer. Hence the Navigation Drawer is relegated to the root-levels of the app navigation hierarchy and cannot be used in deeper levels. Essentially, the Navigation Drawer cannot be used for global navigation.
The contents of the Navigation Drawer are hidden. Therefore, features that are only accessible from it will tend not to be noticed by many users. That is why in the previous design, Facebook put the more important menu items in the Action Bar (top bar) as well. Naturally this causes confusion because the same buttons are present in multiple locations but it’s better than losing large amounts of user enagagement.
Since the Navigation Drawer is used mostly at the root-level pages, you could easily use a root page instead. Instead of sliding the Navigation Drawer from the left, you could simply provide a Back Button and show the list of menu items as a separate page. Since everybody is familiar with the Back Button, it becomes very natural for users.

Items 1. and 2. are closely related and have very much to do with the feeling of being “lost” within an app’s hierarchy. Regarding 1., having a global navigation visible at all times makes it easy to get back “out of the woods” so you always feel safe. Without one, you would have to tap the back button many times, and you probably have no idea how may taps you need. Unless your app hierarchy is shallow, you need global navigation at all times. As for 2., if the contents are hidden, users are not going to quickly learn what features your app provides. You should help users learn as quickly as possible by showing the list of important features often.

Credit Where Credit Due

Following WWDC 2014, there has been a lot of positive commentary about how Apple seems to have opened up and was listening to the requests from developers. There was also a lot of discussion on how wonderful the new “Continuity” focus was as compared to efforts from Microsoft and Google.

Given that Craig Federighi was on stage most of the time to explain these new features, Craig and his personality is getting a lot of attention. However, we have to remind ourselves how and when Craig was promoted to his current position.

It was on the occasion when Scott Forstall was ejected from the head of iOS development. Craig was given control of both OS X and iOS development, and was given the task of improving collaboration. And there is no doubt now that he has done a wonderful job.

But it is also true that this was Tim Cook’s vision all along. Tim Cook valued collaboration over the genius of Scott Forstall. He was the one that made the decision between choosing Craig and Scott. And his wisdom has paid dividends.

As much as WWDC2014 was about the new Apple, it also showed that Tim Cook was spot on in his strategy for the company as a whole. We can expect more fruits as the second half of 2014 unfolds.

Thoughts from WWDC 2014

Some of my random thoughts from the WWDC2014 announcements.

Spotlight search moving away from Google

There has been quite a bit of discussion that Apple may be gradually moving away from Google, even on Search. This is evidenced by Spotlight using Bing for searches instead of Google.

I actually take a different view. I am starting to think that Google search has overshot mainstream demands and is actually vulnerable to low-end disruption. What I mean is that for most of the time, when people are doing Google searches, they don’t really require the full power of Google. Instead, what they want to do is to find the meaning of a word from Wikipedia, a location from Maps, something in the news, restaurant information or information about a song or an application. They don’t really need a search engine that knows everything that is on the net, including random blogs. What they need is information from a handful of distinct services.

Google itself acknowledges this. Search for “sushi” on Google and they will give you a map of sushi restaurants nearby and an entry from Wikipedia. Search for “Masahiro Tanaka” and Google will give you an entry from Wikipedia and a link to news searches. Google realizes that people are not looking for random sushi information, no matter how relevant it may be to the “sushi” keyword. Instead the majority of users are using Google as a gateway to Wikipedia, maps and news.

For these users, a search engine that simply listed Wikipedia entries or directly looked up maps would be more convenient than using the full Google search engine.

Hence my position is that Spotlight is less about replacing Google with Bing, and is much more about directly showing Wikipedia entries, etc. Google is facing the possibility of low-end disruption on search.

iCloud Drive

It is becoming increasingly obvious that some elements of the Cloud are starting to be commoditized. iCloud Drive is a prime example of this. We have DropBox, Box, Google Drive, Microsoft One Drive. We even have open-sourced clones like ownDrive. DropBox, which used to be a prime example of how the cloud is becoming so convenient and important, is now almost completely commoditized. It will be very difficult for even DropBox to differentiate itself from the rest.

Windows compatibility

iCloud Drive will be available for Windows but not for Android. This clearly show what Apple thinks of Android. Apple views Windows as a necessary evil. They realize they cannot ignore Windows because it is so dominant in both the consumer and corporate spaces.

On the other hand, Apple considers Android users as people who made the wrong choice by mistake. Apple thinks that if Android users regain their sanity, they will move towards iPhone.

Seriously, if you consider the few most likely multi-OS situations and think through how Apple would like each consumer to behave in the future, you can see the rationale behind Apple’s decision.

For example, Windows PC and iPhone/iPad users are completely covered by Apple’s commitment to iTunes on Windows and iCloud Drive. There is clear multi-device support there, although limited because Apple can not directly modify Windows.

Also, you won’t find many Mac users who decided to use Android smartphones, so it’s meaningless to cater to these users.

There will be many Windows PC users who also have Android phones. Apple isn’t able to target these users with iCloud until they buy at least one Apple device, but that’s another strategy.

Now the main issue is with Windows PC users who own an iPad and an Android phone. Given the market share of each device category, there are quite a lot of users in this segment. Now iPad and Windows will work well together, at least as well as how Windows and Android will work. Given the rapid replacement cycle of smartphones and the dominance of Windows, it makes sense for Apple to try to convert the Android phone to iPhone rather than to convert the Windows PC to a Mac. To achieve this, Apple should work on getting the iPad to work better with Windows, at least better how Android. They should try to make Android the odd-man-out. This isn’t a difficult task given how Google doesn’t like collaborating with Microsoft.

So my view is that Apple is being very sensible in supporting Windows in their multi-device strategy and not supporting Android.