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;

  1. When commoditization occurs at a certain stage in the value chain, an adjacent stage will gain the opportunity to earn attractive profits.
  2. Attractive profits emerge at the stage which solves the most difficult problems in the industry, typically with an integrated approach.
  3. 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

  1. 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.
  2. 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).
  3. 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.
  4. 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.
  5. 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;

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

  1. Cubed Podcast: “Google I/O Takeaways and Implications”
  2. Tech.pinions Podcast: “Google I/O, 4K, GoPro”

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;

  1. Carriers are the interface to customers, and importantly, they control the billing, especially in emerging countries.
  2. 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.
  3. 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.
  4. 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;

  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?

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.

Google Play Revenue Growth

App Annie just released Google Play their download and revenue report. The title of their blog post that announced the availability of the report was “Google Play’s Phenomenal Growth”. Let’s check this.

Both App Annie and Distimo have regularly released reports in the past. I commented on the most recent report in this blog, and have also commented on previous reports.

First let’s look at a graph from an App Annie / IDC report dated Feb. 26, 2014. By comparing Google Play revenue (in this case limited to games) between 4Q12 (roughly 30) and 4Q13 (roughly 130), we see that annual growth was 430%. This is much much more than the 2.4x (240%) reported for 1Q13 vs. 1Q14. Hence we can say that on a ratio basis, Google Play growth has actually slowed down.

Now attentive readers might have noticed that the current report is for all app categories, while the older report was for games. However App Annie has also mentioned that games represent 80-90% of Google Play revenue. Therefore using all category revenue and game category revenue interchangeably does not significantly change the numbers.

NewImage

However, given Google Play’s rapid growth, it is rather unfair to compare the ratios early in the game to later ratios. We should also look at absolute growth. Since App Annie hides the raw data behind an arbitrarily indexed revenue score, we have to again resort to reverse-engineering their charts.

Looking at the above chart, we can see that 1Q13 was roughly 60 on the Y-axis. Multiplying that by 2.4, we get 144. If we were to extend the above graph and plot 144 for 1Q14, we would see growth in absolute terms actually slowing down. 4Q13 (roughly 130) – 3Q13 (roughly 100) = 30. 1Q14 (roughly 144) – 4Q13 (roughly 130) = 14. What we see is a huge slowdown on a sequential absolute growth basis (30 vs. 14).

Now since these numbers have been reverse-engineered and they also contain ambiguity due to all categories vs. games, I do not intend to conclude that there was a huge slowdown. I simply want to bring attention to the possibility that a slowdown may have happened.

To further understand the character of Google Play growth, you have register your email with App Annie, but you can download the full report for free. Inside this report, you will see that Google Play growth is still completely reliant on Japan, US and South Korea. Even large wealthy economies like Germany which also has a high Android marketshare have minuscule Google Play revenue compared even to South Korea.

The problem is, the lopsidedness of Google Play revenue is likely to limit future growth. Android market share itself is growing in the less-wealthy nations and is flat or decreasing in markets like Japan or the US. If Google Play revenue continues to rely on these countries, growth may soon trail that of the iOS App Store, the figures for which are likely to be released from App Annie quite soon.

Effectiveness of Online Ads

Jordan Weissmann an article that is very much in alignment with my views and experiences with online advertising.

“We Have No Idea If Online Ads Work: The Internet has given us an ocean of data. Turns out, most of it is pretty useless.”

Some excerpts;

Last year, a group of economists working with eBay’s internal research lab issued a massive experimental study with a simple, startling conclusion: For a large, well-known brand, search ads are probably worthless.

For instance, companies like to run large ad campaigns during major shopping seasons, like Christmas. But if sales double come December, it’s hard to say whether the ad or the holiday was responsible. Companies also understandably like to target audiences they think will like what they’re selling. But that always leads to the nagging question of whether the customer would have gone and purchased the product regardless. Economists call this issue “endogeneity.” Derek Thompson at the Atlantic dubs it the “I-was-gonna-buy-it-anyway problem.”

In the end, it all comes down to the evergreen challenge of distinguishing correlation (e.g., a Facebook user saw an ad and then bought some shoes) from causation (e.g., a Facebook user bought some shoes because he saw an ad).

This is exactly the reason why we stopped using AdWords for our antibody search service. Visitor numbers dropped, but our profits didn’t.

Maybe brands that are just starting out need to use AdWords. Maybe if they never gain brand recognition or loyalty, these brands might have to use AdWords forever. However, if your brand has managed to get some recognition, or if your product offerings are unique and listed high in organic search, it is very likely that AdWords is reducing your profit rather than increasing it.

Google and other internet advertising companies are telling advertisers how much data they have and how effectively they can target customers. However, as a recipient of these advertisements, I’m seldom amused when they blatantly show ads from websites that just I visited the day before. If this is all that big data can do, then Internet advertising companies have a big problem.

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.