Yahoo! Weather App: a Followup
Yahoo! Weather App: a Followup
Join the DZone community and get the full member experience.Join For Free
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 ;) )
I Write for Developers and Designers
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:
- 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.
- 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 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.
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.
I want to refer back to Nick Butcher's comments about the topic. It's very clear what Holo is meant to mean.
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 , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.