iOS – Page 2 – Naofumi Kagami

HTML5 Is Not Yet Good-Enough

Another company is moving away from HTML5 and into native app development for mobile.

“Gree admits failure with browser-based mobile gaming, shifts half of workforce to make native games for iOS and Android”

This trend is not new and ever since Facebook (a huge HTML5 proponent) admitted that HTML5 was a huge mistake, HTML5 development has been on the defensive.

What we saw and still continue to see is, whenever the user experience is an important feature, native app development is the better approach.

This doesn’t mean that every developer must ditch HTML5 and go native. There are many cases where user experience is not the priority. In these cases, it might be still more practical to chose HTMl5.

Rather than debating HTML5 vs. native app development, it is more worthwhile to try to understand what this continuing trend means for the evolution of smartphones. My view is that this trend suggests the following;

The user experience of HTML5 is still not good enough. That is to say that users value the smoothness, responsiveness and beauty of native apps. Users notice the difference.
This would also suggest that the smoothness of the iOS user interface in comparison to Android, is still highly valued.

What’s interesting is that PC users never really demanded smoothness or responsiveness, and were more or less content with Web interfaces. I wonder why.

Android L Screenshots

Uzair Ghani has put up screenshots comparing Android “L” preview to Android KitKat and iOS 8 beta.

A few notes;

Android L is definitely not yet finished. Even the calendar app uses the old Holo theme. Compared to where iOS 7 was when it was announced at WWDC, there still seems to be a lot to do. Maybe Google is planning to gradually update the Google Play apps; they may not yet be updated at the Android L release.
Android L does not seem to use the “frosted-glass” effect that iOS 7 has had (and iOS 8 also). On the iPhone 4, iOS does not use “frosted-glass” either. Maybe the GPUs are not yet powerful enough on most Android phones. This is a bit interesting because a lot of the UI effects on Android L look like they would depend on a good GPU.
The settings screen is no longer white letters on dark background. This is an important improvement in my opinion, as it sheds the final traces of Android’s geek-oriented history. It makes the setting panel much more approachable.
I’ve always been concerned about the general disregard for consistency in Android user interfaces, even in the Apps that Google itself designs. Unfortunately, we can already see this in the few screenshots. Specifically, in the L phone app, we see the action overflow menu on the upper left. It should be on the right. The action overflow has always been abused in Android, starting life as a hardware key. It has always been a UI control with low discoverability. It would be sad if it is still not getting the respect it deserves.

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.

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

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.

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.