Material Design On The Web: A Well Funded Research Project

The new Material Design announced at Google I/O is supposedly an ambitious cross-platform design language that spans not only Android devices, but also the web.

Anything that is this ambitious should be treated with a healthy grain of salt. Let’s verify what Google means by cross-platform.

Android version compatibility

Given the severe OS version fragmentation of the Android platform, it is important to understand the entirety of version compatibility for Material Design.

Unfortunately, I could not find resources on the web that gave me a good comprehensive idea. I think Material Design will only be supported on Android L. There appear to be some support libraries that will make it easier to support older versions and a Material Design version with the same code, but it looks like that will be it.

Browser compatibility

Google does provide details of browser compatibility for Material Design on the web (the Polymer project). Unfortunately, it doesn’t look too good. According to this discussion on the web, Google is not taking browser compatibility very seriously.

In terms of compatibility, it is simply not up to the standards that most web developers would regard as sufficient.


The lack of Android version compatibility is understandable and will not present an issue. It will be adopted over time.

The issue is with Browser compatibility. Although impressive, there are many similar projects to bring a nice UI to web apps, and none are as restrictive in compatibility as Material Design. Web developers can simply chose one of these. There is little reason to believe that web developers will slowly adopt Material Design.

It’s still very much a research project.

Non-Game Apps: iOS App Store vs. Android Google Play

Since games are such a large part of both iOS App Store and Android Google Play revenue, it makes sense to treat the other categories separately. Furthermore, whenever people are discussing how mobile devices enrich our lives, they are seldom thinking about games. Instead of lumping games and all other apps into a single number, we should be separating them.

In my opinion, it is the non-game segment that really matters. It is where the innovation lies. I say this because we’ve had games, even mobile games, for ages.

For the following table, I used numbers in App Annie’s 2014Q1 report.

スクリーンショット 2014 06 27 15 18 33

What we can clearly see is that in non-Game revenue, iOS is totally dominant. iOS has 4.63 times the revenue of Android in non-games.

Non-game Apps Growth in the Google Play Store

In a previous post, I took a look at the recent report from App Annie, “Google Play’s Phenomenal Growth” and mentioned that the growth wasn’t actually as phenomenal as App Annie’s blog title suggests.

Here, I would like to draw attention to the fact that if you look at non-game app revenue, the situation is actually quite bad. That is to say, we are definitely seeing a leveling off.

App Annie tells us;

  1. 14Q1 Google Play app revenue was 2.4x year on year.
  2. Game’s share of Google Play revenue grew from 80% to 90% year on year.

Putting this data into a simple table, we get the following (units are Indexed Revenue);

スクリーンショット 2014 06 27 8 33 28

Surprisingly, the growth of the non-Game category is only 20%.

Now that’s far from phenomenal.

Google I/O Keynote

Yesterday, before Google I/O kicked off, I wrote a piece about my worry that Google is winding down Android development. Well today, after reading people talk about the keynote (I haven’t yet taken time to watch the 3 hours), I’m still not sure.

True, Google previewed Android “L”, of which the most impressive part is the user interface (Material Design). This is a significant improvement over the previous UI theme “Holo” which was introduced in ICS (Android 4.0) back in 2011. Most significant are the animations and effects that are obviously powered by GPUs. The user interface concept using “depth” and animations is very similar to iOS 7. The problem is, what versions of Android will be able to run this user interface? To what extent will there be support libraries that enable older Android versions to use it? Given the reliance on GPUs, only a small subset of the animations may make it to older devices.

As always, this is in stark contrast to the situation in iOS. iOS7 supports iPhone 4 which was introduced in 2010, even before ICS was introduced. Although iPhone 4 struggles with some of the animations, it does work rather OK. It is highly unlikely that Material Design will go back that far.

Although Google has succeeded in nullifying the fragmentation issue in many respect through their Google Play Service strategy, and by also providing support libraries which help apps provide backwards compatibility, there are limits to what you can do without renewing the whole OS. Furthermore, solving the software fragmentation issue independently of hardware can actually make the hardware fragmentation issue worse. Also keep in mind that new OS releases can actually help cut off old devices and reduce hardware fragmentation.

In the case of Material Design, the question that developers will face is whether or not to update their apps to support the new look-and-feel. This depends largely on how many users will migrate to the new OS (KitKat is now on 13.6% of devices after being introduced about 8 months ago, iOS7 hit 87% after 7 months), and how difficult it will be to support users on older versions.

In the case of iOS7, supporting both iOS6 and iOS7 was not easy. At the same time, iOS7 adoption was very fast. Hence it made a lot of sense for developers to fully transition to iOS7 only.

For Material Design, the decision will be more complex. The option to fully transition to Material Design and to abandon the Holo UI will not be an option unless Google prepares support libraries that allow Material Design to work on old devices and old OSs. As I said, since Material Design probably makes full use of the GPU, this will be complicated. It could almost be Vista-like.

If Google’s support libraries do not work on a significant number of old devices, then developers will have to support both the Holo UI and the Material Design UI simultaneously. Instead, I expect most developers to simply stick with the Holo UI for a while.

In summary, I think Android has tried hard to move forward and that is confirmation that they are still eager to provide a user experience that is comparable to iOS. They are not slowing down in this regard. The problem is that Android “L” needs a lot of developer support for Material Design to succeed, and the fragmentation issue is likely to be a hinderance.

Personally, as an occasional Android Developer, I wholeheartedly welcome Material Design. I’ve only skimmed through the docs, but in addition to providing a better look, a lot of the nagging issues in the Holo UI have been addressed. I’m particularly happy that small things like overflow indicators have been added to scrollable tabs. Bottom sheets (much like action sheets in iOS) are also a very nice way of handling overflowing controls. I’d be happy if developers could get a support library that may not have fancy animations, but has the same widgets as Material Desgin.

As for the other announcements in the keynote, they actually confirms my concern that Google is trying a bit too hard to find success in other markets. It’s interesting how things like Android Auto have morphed into a CarPlay look-alike. This once again suggests that Google is better off quickly copying Apple rather then trying to pry open markets by themselves. As such, Android Wear is probably a waste of time.

What we really need right now is some feedback from Android developers. Are they excited about Material Design, or are they concerned about the extra effort?


I’ve skimmed through the Google I/O videos, and it looks like the vast majority of Material Design will be exclusive to “L”. Creating a UI that is optimized on both “L” and previous versions of Android does not look like it will be much of a problem as long as you aren’t using the new “L” UI controls.

Is this a good thing or a bad thing?

It’s hard to say. It looks like the transition to Material Design will be slow, primarily because it will take time till the majority of devices will be able to run it. Hence most developers will also be slow to adopt it. They may be especially slow to adopt the new UI controls because that would break compatibility with older devices.

For the high-end, this isn’t good.

For the low-end, this means that there will be minimal hardware fragmentation issues due to lack of GPU power for example. For this segment, it’s probably good.

Android Design Guideline Nonsense Revisited

A short while ago, I wrote a blog post “Android Design Guideline Nonsense” where I simply brought up the issue that, unlike the historically respected Apple Human Interface Guidelines, the Android Design Guidelines were very new and that they still haven’t earned credibility. At the same time, there were some items in the Android Guidelines that were questionable, which simply means that it will take further effort from Google to establish the Android Guidelines as a definitive resource.

However, Google actually moved in the opposite direction. On May 20th, 2014, Google updated its Google+ Android app, which significantly diverges from their own guidelines. This naturally brings into question whether Google’s internal App development teams are respecting the guidelines or not. On the surface, it looks like they are not.

First, let’s look at what the new Google+ app looks like. Unfortunately, I hardly ever use Google+ so I’ll use screenshots that I’ve found on the web.

From ComputerWorld.


Here, JR Raphael tries to reassure Android developers that the Hamburger Navigation (Navigation Drawer) is not going away despite it disappearing from the Google+ application. He shows the above comparison between the old app (on the left, with the Navigation Drawer showing) and the new one. The Action Bar on the new Google+ app (the red bar on the top) is the one that is very different from Google’s Guidelines.

First of all, the use of the “▼” to indicate a pull-down menu (as seen on the “JR” and “Everything” elements in the screenshot) is not standard on Android. The standard is to use what Android calls a “spinner” which is denoted by a triangle on the bottom right corner as in the following image (taken from the guidelines).


Spinners are quite used quite flexibly with Android and serve multiple purposes. However, they are never denoted by a “▼” symbol.

If fact, the menu with the “▼” symbol in the new Google+ app is not a spinner. It is a completely new element that is not described in the Android Guidelines. In the following image from ArsTechnica, you can see how it transitions to a full-screen page which by all accounts is a replacement for the Navigation Drawer. It is completely new in the sense that it is not a part of the global navigation, because unlike the Navigation Drawer, it is not accessible from deeper down in the hierarchy; you need to navigate back to the root level to be able to access this menu. Furthermore, it is visually separate from the Action Bar and is closer to the page content in appearance. Whereas the Navigation Drawer was a component of the Action Bar, this new UI does not seem to be.


I do not claim to know whether this new “▼” menu is a good idea or not from a usability point of view. Looking at the comments on the blog entries, it looks like opinion is divided.

What is clear is that this is confusing Android UI designers. It is confusing those designers that vowed to adhere to the Android guidelines. It is causing legitimate concern over whether the Navigation Drawer is going to be de-emphasized in the future. The Navigation Drawer has always been a controversial UI control due to it not being well recognized by many users. The hope was that as the Navigation Drawer becomes popular, more users will easily recognize it and even expect it. If Google decides that they are not going to use the Navigation Drawer anymore in their apps, users will not less educated on it and will recognize it less when it appears on third-party developer’s apps. If this is the case in the future, then developers should try not to use the Navigation Bar at all.

A further concern is that instead of using a UI control already present in the Android SDK, Google+ created their own custom control. They could have used Action Tabs, which are supported in the Android SDK, but they didn’t. The question is why? Why didn’t Google+ use Android SDK controls. Did they think that the current controls were insufficient for their needs? More specifically, did they think that the previous Navigation Drawer didn’t cut it, which is apparently what Facebook thought when they ditched it? It would be very disheartening if this was the case.

Now compare this to iOS. The applications from Apple all use standard controls available in X-code, and none use custom elements that significantly deviate from the standards. Apple truly eats its own dog food. What’s more significant is that these controls have been largely unchanged in functionality since the original iPhone (although they were given a visual redesign in iOS7) so iOS users are extremely familiar with them. The contrast between Google’s and Apple’s approach could not be stronger.

A while ago, Cennydd Bowles, design manager at Twitter wrote a post “Why don’t designers take Android seriously?”. My feeling towards Google is “Why doesn’t Google take Android Guidelines seriously?”.

As such, it seems unlikely that Android Design Guidelines will ever earn the respect that Apple’s guidelines receives. As a result, Android apps will never be as consistent as iOS apps.

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.

Android spinner ios segmentcontrol

The difference here is;

  1. 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.
  2. iOS’s segmented control approach exposes each option before the user interacts with the screen.
  3. 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.

  1. 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.
  2. 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

Android spinner ios picker

Selection of actions from a list

Androind spinner ios actionsheet

Switching views on a set of data

Android spinner ios segmentcontrol 1

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

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.


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;

  1. 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.
  2. 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.
  3. 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.



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


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


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.


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.


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;

  1. 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.
  2. 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.
  3. 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.