Now, before anyone tweets / messages these people, don't. They have a point (although I'm not sure if being called "pathetic" is fully justified). I appreciate (most) of these comments and I thought I'd address some of them and explain my "nitpicking" in the previous article.
I write for developers and designers
While getting posted (and voted up) in /r/android usually means a nice incoming traffic to the site I'd rather not see my posts there. /r/androiddev /r/androiddesign are much better places for what I write.
I don't write app reviews for end users. I write for designers and developers.
An app like the Yahoo! Weather is a gold mine as an example when writing about design for couple of reasons:
- It's done by a large company with large budget - I think it would be wrong to do a similar detailed breakdown to an app done by a small team or an individual dev. Small teams & small budgets often create external constraints to the development and design. A large company like Yahoo! on the other hand has everything it needs.
- Yahoo! got close - a detailed evaluation of an app that is so far from the goal that even multiple iterations could not take it there might not be as valuable as evaluating an app that is almost there. The Yahoo! Weather app is beautiful and has a lot of potential. That makes it an optimal example. The app doesn't have to be fully redesigned.
- It's a popular app - everyone knows the app and everyone has an opinion about it.
None of the critics actually told which parts they felt were the wort nitpicking in the article. However, it's pretty safe to assume that my comments about the "hamburger" icon and the share icon could easily be seen as such.
So why did I choose to talk about them? Are all users now confused when using the app because the icons don't match. I'd bet my left leg that no. Users are just fine using the app with the icons Yahoo! chose to use.
Icons are extremely powerful tools. A single icon can convey complex functionality to users. If the platform unifies this messaging the message is delivered to users instantly and completely every time. On the other hand icons that differ from the platform standards have inherent risk of causing confusion.
Now, by this I don't mean that all apps have to use only icons provided by the platform or the platform documentation. Not at all! But there's common functionality which is used on many apps ant in those situations use of the standard icons is more than recommended.
Sharing was one of my examples. Android sharing is different from iOS sharing. The actual sharing happens outside your app. Therefore whenever you have a sharing intent in our app you're, in effect, linking to platform functionality and your link (icon) should reflect that.
The other example was the drawer navigation. Why wasn't I happy with the icon they used and why wasn't I happy with their implementation of the drawer?
The reason is that the drawer is actually a very complex component. I'd argue that the navigation drawer on Android is more than double the complexity than its counterpart on iOS. This is because Android navigation model is more complex than iOS'. We have the back button.
Google took their time to design the navigation drawer patterns and their solution is extremely well thought out. There are tons of subtle hints that help users to understand how the drawer corresponds to rest of the app and how they can interact with it. Therefore I really, really recommend everyone to use the default implementation and the default components.
Before I get yelled at again. I'm very much aware that Google doesn't use the navigation drawer correctly in all of their apps. That's no excuse not to use it in your app. Google will get there with their apps.
It's pretty strange what the word Holo had become to mean in different circles. Let's be clear: apps that follow guidelines don't have to be gray/black with blue accent colours. When we say that apps should follow guidelines we're not advocating all Android apps looking the same!
I want to refer back to Nick Butcher's comments about the topic. It's very clear what Holo is meant to mean.
Holo and Android design guidelines don't mean anything to users and they shouldn't. The design guidelines are for us the developers and designers. We need to know them. Users don't need to know of them.
It is unlikely that regular users notice the difference between apps that follow the design guidelines and the ones that don't with direct observation. It is much more likely that users simply simply feel like some apps are more effortless to use than others. Some apps require them to relearn how to use certain things while some apps just seem to be intuitive and easy to learn.
Even more importantly you don't have to put so much design effort to your own app if you follow the guidelines. When you run into a problem in your app design take a look what the guidelines say and follow them. You can potentially save days of work on both design and implementation.
But the guidelines are just that, guidelines. You can break them without making your app a bad app. Every time you break them you should have a reason to do so though. You'll also have to make sure that you have the required skill in your team to make your unconventional solution work in your app.
So, what I'm saying about following guidelines in the previous post is that I don't see any reason why the guidelines should have been broken in the Yahoo! Weather app. They gained no benefit and the resulting UI is worse than what it would have been if they'd just followed the guidelines. They could even have done more branding and made the app more beautiful that way. Take a look what Taylor Ling came up with in his post proposing few simple changes. I think this could be an extremely beneficial discussion about Android design.
There you have it. I hope this helps you understand why I chose to nitpick the Yahoo! Weather design. I don't hate Yahoo!, I don't want every app look the same and I'm not pathetic (at least I think I'm not).