Android – Page 5 – Naofumi Kagami

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.

Summary

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.

The Law of Conservation of Attractive Profits And Personal Computing

In a previous post, I wrote about my concerns on how the law of conservation of attractive profits might apply to the next stage of mobile computing, especially in emerging nations.

Here, I would like to describe how the law of conservation of attractive profits helps us to understand the history of personal computing. This is particularly instructive because it strongly suggests that this law will continue to be applicable in the future.

The law of conservation of attractive profits

I quoted a brief description of the law of conservation of attractive profits from Clayton Christensen’s book “Seeing What’s Next” in my previous post.

What it tells us is;

When commoditization occurs at a certain stage in the value chain, an adjacent stage will gain the opportunity to earn attractive profits.
Attractive profits emerge at the stage which solves the most difficult problems in the industry, typically with an integrated approach.
This integration may happen at the product component level, customer interaction level or supplier interface level.

Hence to identify which stage will earn attractive profits, we have to understand what the most difficult problem in the industry is. This is not necessarily a technical problem, but can be any stage in the value chain.

Obviously, different countries, different regions may have different problems in their value chains. In particular, the average spending power is very variable between regions and this will necessitate different approaches to the market. Hence different stages will earn the attractive profits, depending on region.

Application to personal computing history

From the late 1970s to early 1980, Apple and IBM were the powers in personal computing. They took components and assembled them into their respective proprietary personal computer platforms. During this age, the attractive profits were in designing the platform and assembling the computer.
As technology improved however, this shifted. Compaq reverse-engineered the IBM-PC, creating a clean room implementation in the 1980s. This effectively commoditized the platform design of the IBM-PC. Assembling a PC suddenly became very easy to do. When this happened, the power in the industry shifted to adjacent stages, namely Microsoft (in software) and Intel (in CPUs).
In the 2000s, the Internet came and created another layer in the value chain. At the same time, innovation in PCs started to falter partially due to the fact that PCs had become “good enough” for office productivity. The absolute processing power that Intel provided through its new CPUs no longer became important because the old ones or the cheaper ones from AMD were “good enough”. Similarly, the new operating systems that Microsoft released no longer became essential because the old ones had “good enough” features. This created an opportunity for the attractive profits to shift towards Internet service companies (which were in their infancy and not yet “good enough”), and bore behemoths like Google.
Apple then came along in 2007, bringing a totally revolutionary product, the iPhone. This caused the whole evolution cycle to go back to the beginning and once again, the company that assembled the final product commanded the most attractive profits (Apple). The most difficult problem in computing was designing and creating smartphones that were small and light, yet powerful. They also had to contend with the dilemma of very limited battery capacity and full-day battery-life expectations. This was the responsibility of the hardware manufacturers.
Hence similarly in the Android ecosystem, the most profitable company became Samsung, also the company that assembled the device.
As technology progresses and solves the most pressing problems in smartphones, the profits move away from the hardware assemblers to adjacent stages. Hence the predicament that Samsung now finds itself in. At this point however, it is not yet clear which adjacent stages will reap the profits. In particular, it should stress that is no by no means obvious whether Google services will become this stage or not.

Which layer could reap future smartphone profits?

I won’t try to reach a conclusion here, but simply point out a few things that I think are important.

Things to consider;

A huge problem in the smartphone industry is how to expand customers and how to expand usage in various countries and various market segments. It is increasingly apparent that a one-size-fits-all approach is not going to work.
The problems in the industry will significantly differ according to which market segment we are looking at. For example, high-end smartphone users may have issues with sharing links, customizing the user interface, pure Google-ness, continuity with other devices, notifications, maps, etc. On the other hand, low-end users will have issues with ease-of-use and prices. Similarly, price is much more of an issue for users in emerging countries (regardless of tech literacy) than developed countries.
Whereas hardware and low-level software affect the experience of every user, the service layer is more specialized. For example, not everyone uses a complex social networking service like Facebook and may be content with SMS. Similarly, people who often visit unfamiliar places will make constant use of maps, but there are also many people who simply go to-and-fro from the same few locations most of the time. The same thing can be said for Google Now. People don’t need to be constantly reminded of things that they do every day of the week.
Google actually doesn’t control a lot of the services that are suited to people in emerging nations. For example, their most visited property on mobile devices is YouTube. However, YouTube takes up hideous amounts of bandwidth which will be a problem in these countries. Facebook and WhatsApp either don’t have this issue or have worked hard to fix this.
Because emerging countries do not have too many people on credit cards, billing for software and services is a large issue. Carrier billing is seen as a solution for this. Carriers will be able to extract the attractive profits proportionally to the importance of carrier billing in that country.
The layer that can customize the solutions to match the different markets is in a good position to gain the attractive profits. For hardware, this would be the local vendors who can now easily create custom hardware with the help of the Shenzen ecosystem in China. For the software and services, carriers traditionally have been the gateway.

Google and the Law of Conservation of Attractive Profits

In this blog, I have touched on Clayton Christensen’s “law of conservation of attractive profits” a few times (in Japanese: 1, 2)

The law of conservation of attractive profits is briefly described in Christensen’s book “Seeing What’s Next”. Below is a passage from the book;

We have also called the law of conservation of integration the “law of conservation of attractive profits,” because companies make attractive money when they solve the hardest problems. The hardest technical problems mandate solutions that are tightly coupled integrated systems. When modularity and commoditization cause attractive profits to disappear at one stage in the value chain, conservation of integration means the opportunity to earn attractive profits with propriety products will emerge at an adjacent stage.

Conservation of integration explains why it is not accurate to characterize and industry as integrated or disintegrated. There are numerous types of integration in any given industry. Specialists are integrated, just in different ways. Whereas integrated firms might span an entire industry’s value chain, specialist firms might be integrated to produce a single component that itself is not good enough. Or they could be integrated across whatever interfaces drive customization and convenience, which could be the point of customer interaction or the interface with suppliers.

I find that the law of conservation of attractive profits gives us great insight into how personal computing evolved from computers like the Apple II to the iPhone. This is a long topic, and I hope to touch on it sometime in the future.

For the current discussion, I would like to touch on how Google seems to be trying to manipulate the smartphone value chain and whether it will succeed.

To understand the current situation better, I suggest readers listen to two excellent podcasts which describe the different strategies that Apple and Google are pursuing.

Regarding Google, what is suggested in these podcasts is that Google is trying to commoditize both hardware and software so that their services will reach the widest audience possible, thereby providing Google with data to feed their machine learning project. They do not seem to care about creating an ecosystem in which their hardware OEMs and application developers can sustain profitable businesses.

Viewed from the law of conservation of attractive profits, this can be explained as Google attempting to commoditize hardware and software, so that the service layer will dominate attractive profits.

The question is, will this work?

Listening to Ben Bajarin in the Tech.pinions Podcast, it dawned on me that there is another layer that actually has a bigger chance than Google of gaining the attractive profits. That is the carrier layer.

Carriers have the following advantages;

Carriers are the interface to customers, and importantly, they control the billing, especially in emerging countries.
Carriers own the pipe and can control the flow of content through their networks. For example, they can provide unlimited access to WhatsApp and Facebook, while restricting access to YouTube and other sites.
Carriers are local. This means that they can tailor pricing and promotions to fit the local situation. This is especially important in emerging countries where the spending power of the average citizen is a fraction of that in developed nations.
Before the introduction of the iPhone, carriers had huge power in the ecosystem. So much so that Steve Jobs famously called them “orifices”. It has already been proved that the market structure is such that carriers can command huge profits if the circumstances are right.

Ben Bajarin briefly touched on Cherry Mobile in the Philippines, which is a carrier that is selling its own brand of smartphones.

I am not yet familiar with what Cherry Mobile is actually doing, nor have I spent time thinking about this in more detail. It does appear however, that Google is not the only potential beneficiary from software and hardware commoditization. In fact, it seems totally possible that services will also be commoditized and that the carriers will reap the attractive profits.

This is a theme that I will continue to think and hopefully write about.

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;

14Q1 Google Play app revenue was 2.4x year on year.
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?

Update

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.

Why Google I/O Worries Me

Google I/O 2014 is scheduled to start in a couple of days from today. The event schedule is available here and you can see what sessions are in store. Unlike Apple’s WWDC 2014 event, the session titles are clear and none are secretive like “Shhhh, Can’t Tell You Yet”.

Since I have not looked at previous Google I/O events in detail, I have not idea whether or not the session titles give any indication of Google’s strategy. Having said that, the list of Google I/O sessions seems to have little to do with new Android APIs (or Google Play Service APIs for that matter). What I notice is that there is stuff for web developers, cloud management, wearables and cross development. There are sections devoted to Android, but they seem to be about how to leverage the current APIs, not about new ones.

I am very concerned about this because I am sensing that Android development is being deemphasized within Google. I sense that Google is not interested anymore in expanding the technical horizon of Android smartphones, and is only interested in gaining access to developing nations by making Google smooth on low-powered devices.

The basis of my concern is that Google used the “Jelly Bean” codename for three iterations starting with 4.1 in July 2012 till the introduction of 4.4 in October 2013. More significantly, Android versions have been on 4.* since “Ice Cream Sandwich” in October 2011 till the current “KitKat”. Furthermore, the main improvement in “KitKat” was not new features or new APIs; it was the fact that the new Android OS was designed to run on low-end devices with as low as 512MB of RAM. Even with “Jelly Bean”, the main attraction was “project Butter”; an attempt to make the UI as smooth and responsive as iOS. You can almost say that Google has not added significant new features or design changes to Android since October 2011 (“Ice Cream Sandwich”). A rundown of Android version history is available from Wikipedia so you can verify for yourself whether or not Android has been making large improvements recently.

At first glance, the list of Google I/O sessions seem to confirm my worry that Android is not aggressively moving forward. It seems to me that in the mid-term, Google is more interested in Android as an OS for wearables, not for smartphone. It could well be that Google considers its work on Android to be already “good enough” and therefore Google is reallocating resources to wearables.

We will learn more about this as Google I/O unfolds so it’s rather meaningless to guess Google’s intentions until we at least hear the keynote speech.

I’ll end this article by saying that if Google is indeed deemphasizing the role of Android as a leading (in functionality) platform for smartphones, the profitability of hardware OEMs will look more precarious than ever because high-end devices will lose their appeal and the replacement cycle will lengthen. I’ll also link to a post by Benedict Evans that notes a similar concern on the future stability of the Android platform.

For me, this is by far the most important thing that I want to learn from Google I/O.

As a footnote, keep in mind that iOS 8 has introduced a huge number of APIs and is arguably the largest iOS update ever. Android advocates may comment that iOS 8 is simply copying features that Android has had for years, but that is totally irrelevant. The fact is that iOS 8 is evolving faster than ever and developers are tremendously excited. Whether Android (on smartphones) decides to keep running alongside iOS or rather decides to slow down will have large future consequences.

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.

NewImage

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

NewImage

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.

NewImage

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.

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.