Mobile Zone is brought to you in partnership with:

I am an Android developer and enthusiast with over 10 years of Java development experience. I'm big fan of good design an appreciate well though usability design in applications. Juhani is a DZone MVB and is not an employee of DZone and has posted 104 posts at DZone. You can read more from them at their website. View Full User Profile

Yahoo! Weather App: a Followup

  • submit to reddit

Yesterday, I wrote an article pointing out issues in the new Yahoo! Weather app. To my surprise, the post has turned out to be quite a controversial one. Here are some reactions to it (I won't even touch Reddit comments ;) )

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 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 Yahoo! Weather is a gold mine as an example when writing about design for a couple of reasons:
  1. It's done by a large company with a large budget: I think it would be wrong to do a similar detailed breakdown on an app done by a small team or an individual dev. Small teams and small budgets often create external constraints to development and design. A large company like Yahoo!, on the other hand, has everything it needs.
  2. 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.
  3. It's a popular app: everyone knows the app and everyone has an opinion about it.

Design Nitpicking

None of the critics actually told which parts they felt were 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 they're not. 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 and 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 your 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's 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 the 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 has become to mean in different circles. Let's be clear: apps that follow guidelines don't have to be gray/black with blue accent colors. When we say that apps should follow guidelines we're not advocating that all Android apps should look 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 with direct observation the difference between apps that follow the design guidelines and the ones that don't. It is much more likely that users 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 into your own app if you follow the guidelines. When you run into a problem in your app design, take a look at 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 to look the same and I'm not pathetic (at least I think I'm not).
Published at DZone with permission of Juhani Lehtimaki, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)