Some of these are really nice. I'm curious how many of these are Android-specific though. Path looks pretty similar on iOS and so do FourSquare, Flipboard etc. Which of these are examples of good mobile design that holds itself on various platforms (iOS, Android etc.) and which are unique to Android?
Some of them definitely use the Holo UI style, while others use their own non-holo/non-iOS style, although I wouldn't know if they use the same one for their iOS apps, too.
Most of them look like their iOS counterparts. For example Catch Note's 'home' screen looks the same on Android as it does on iOS. Same with Flight Track Free and Feedly. Pintrest is more or less the same, with a slightly adjusted menu.
Co-founder of Catch here, some context; we launched our first Android app in 2008 and have about 10x as many users on there as we do on iOS.
The issue we've seen is that people build an iOS app and then port it over to Android.
We designed Catch 5.0 apps for Android and iPhone in parallel. This let us keep consistency between the platforms when it made sense, but also let us tweak the design early on so it could take advantage things unique to the platform, e.g. Action Bar on Android.
The team is incredibly proud of this release, and it is nice to see folks taking notice. Both Google and Apple have also featured this release, everybody is beaming here. =)
is it bad if i find it inconsistent, annoying to use, etc?
I mean, it is pretty (well, arguably, most of them are), but, the buttons are all over the place and everyone seems to have it's own UI plastered on top of more or less "android ui compliant" stuff.
the inconsistencies are usually defined by the developers. As you can see most these apps are available to the ios store as well. So its really not fair to judge the platform vs the developers.
I think nobody would have a problem using any of these apps. Most of them even implement some kind of action bar so you totally know where to look for your user controls.
This is a complaint about Mobile in general, not Android. People bitch about fragmentation (and it is a bit painful), but in the regard of "everyone has their own UX on top of the system default" iOS is in exactly as bad a boat, if not worse. Some of the most popular iOS apps take their UX off in crazy directions (a common example: Tweetbot).
Look closely though. You'll notice the ActionBar is extremely prevalent in these. The ActionBar is actually one of those few Android teachable moments; I wish Apple did this as well, as consistently, or as themably. I've used a lot of these apps (and I am sad to not see Pattrn up there!) and it's very much the case that they have a fairly consistent set of "touch semantics" that screenshots don't reveal. E.g., Tap upper right corner to configure; long press for edit; swipe horizontally to navigate; long press on text fields to engage c/p editor bar.
For better or worse, Android's toolkits offer a lot more guidance to the programmer on "the right way" than Apple's do (a great example of this that bleeds into UI is how Android has a ton of Loader patterns and iOS doesn't have anything nearly so sophisticated in its core lib). So in some respects, Android is actually slightly better off; the bigger toolkit means you get some superior consistency. The recent iterations (and backported support) framework strongly encourages you to do things like support long presses and swipe navigation and backpane navigation.
I have written iOS apps (although never public published) and taken classes in iOS development. I am much more of a novice at Android development, but have written a complete (albeit simple, un-networked appliance) app. I've focused more on Android recently because that platform is evolving quickly.
So let's just pretent this isn't a shitty genetic fallacy post and address your challenge head on, "Back up your example and prove to me Android's APIs give more guidance than Android's in how to do ______." I specifically mentioned the Loader pattern.
In iOS There is no concept of a "Loader", so the community has come up with stuff like AsyncUIImageView and friends (code here: https://github.com/nicklockwood/AsyncImageView) which still doesn't entirely solve the problem, because solving the problem takes a lot of framework support.
Sadly, fragmentation is at play again in this; and many Android developers don't use Loaders because they're intimidated or confused or can't use them for their entire panoply of supported devices; so there are a fair share of Android apps that do not use them. You can usually catch this if you change orientation and see things reload from scratch.
Given the rapidly increasing velocity of deployment of 4.0 devices, I think this issue with framework fragmentation is transient.
These seem really inconsistent to me. Feedly looks almost like a metro (sorry, "Windows 8-style") app. doubleTwist looks like an iOS app, as do Square Card Reader and Tumblr. Reddit Sync Pro seems to fit in with Google+, so I assume that's what modern Android apps are supposed to look like.
None of these general aesthetics are bad, but the inconsistency seems to be an issue. (Actually, a few of them do look bad to me, like Rdio, with the very dated "app home screen" that looks like it was copied from the old Facebook iOS app.)
Android doesn't have as much "drag and drop" as iOS. For example, you can't add a tab bar at the bottom, nav bar at the top, table view in the middle, set the text of each cell in the table view, and have an app that looks complete and looks like a stock Apple app. If you do that with Android you're just going to have a flat black screen with lines of text crammed next to each other with 0px of spacing. You really have to do _all_ your own design with Android. That tends to lead to more inconsistency, but more originality as well. Besides, when each app takes up all available real estate, do you really need consistency between apps? Distinctive styles are just a nice reminder of what app you're in.
But this is not a problem Android has when apps target 4.0. The ActionBar has been a huge stabilizing influence on the Android interaction pattern; strongly enforcing backpaning, swipe-to-navigate, and consistent locations for navigation.
I'm not sure why you'd say this. Android actually hasn't suffered from tactile UI fragmentation much more than iOS has.
> Android actually hasn't suffered from tactile UI fragmentation much more than iOS has.
If the apps on this page a representative, I'd say that Android has experienced a lot more UI fragmentation than iOS. These are being held up as examples of best Android interfaces, and they look very inconsistent to me.
In contrast, I just opened up a bunch of random apps on my phone's home screen, and they all look very much like "iOS style". Obviously the native apps match well, but so does OneBusAway, Wikipanion, Skype (though the UI is flatter than the rest), Google Voice, Amazon, OneNote, etc.
I thought you were talking about the actual meaning of taps and swipes and whatnot... that's what I was referring to the as "tactile" part of it, where things like long presses and swipes mean the same thing between apps. In terms of visual style, there has been significant change over the last 18 months as designers come to grips with the new 4.0 style. Both iOS and Android tend to suffer from the problem of "What the fuck can I press?" with some apps.
But to my eyes as an Android user, I see a lot of consistency here. The ActionBar is firmly in place, so I know where to go for navigation. The visual metaphors vary in terms of actual look, but I get what's up.
For example, compare to very different apps: Catch and doubleTwist Alarm Clock. Both are "bounded" by their top bar (although Catch has elected to add extra app-specific chrome at the bottom, too). The navigation "upwards our out" between panes is consistently in the upper left. The additional actions for the app as a whole are on the top right.
In cases where the apps deviate (e.g., bottom bars in Gmail and Catch), the designers have had the good sense to use the standardized icons as opposed to further customization, helping to signal the user that this app does deviate from pure actoinbar navigation. The share, attach, favorite, and trash icons are all with pixels of standard.
A lot of iOS users first coming to Android (including myself) after the advent of ICS may be surprised once they realize how consistent the presence of the ActionBar is, even if it varies in appearance. I encourage you to play with one to see this in action. I certainly felt that sense of confusion at first because I'm used to unified navigation chrome from iOS for most things outside of games. I think this is just a case of longtime iOS users not being familiar with the visual language of the Android platform.
Well, the meaning of taps and swipes is part of the consistency issue. Interaction is more than just "what does swipe do?". It's also "how do I go back?", "how do I take an action on this item?", "how do I change context?".
I personally don't run into a ton of issues in iOS with determining what swipes vs long-presses vs long-taps do. Swipes in a list tend to invoke the "delete" context. Swipes up/down scroll. Tap to invoke. Long-tap for select in a text context. There's certainly not 100% consistency, but it seems fairly consistent to me with the apps I use. I can't speak to how consistent or inconsistent these are on Android, because I haven't used an Android device enough to really know.
Speaking to Catch and doubleTwist, these seem inconsistent to me. Visually, they're quite different, but there seem to be pretty significant functional differences. Many of the doubleTwist screens do not have the "up/out" chevron in the upper left (how is this not redundant with the global "back", anyway?). On the 4th screenshot in particular, there's no "up/out", but there is a settings cog that appears in none of the other screenshots. It appears that doubleTwist also uses a "slide to reveal" metaphor (invoked by the chevron on the main screen) that isn't in Catch or the other apps. In catch, despite there being an action bar at the top, virtually all of the actions you might want to take actually seem to be in the custom bar at the bottom. I don't see how these at all demonstrate consistency.
> I personally don't run into a ton of issues in iOS with determining what swipes vs long-presses vs long-taps do.
Unless you play games or use some of the most popular twitter clients. ;)
> Visually, they're quite different, but there seem to be pretty significant functional differences.
To be expected, they do very different things. I chose them because of their differences. Both apps have deviated from a very mellow Holo standard without introducing a lot of confusion. Evaluate their differences as deltas from the Android baseline (the way a user would), instead of as deltas from each other (which is how someone looking at screenshots on a webpage would).
> (how is this not redundant with the global "back", anyway?)
Oh, because back goes to the last thing you were doing. The chevron goes up in the app. Any Android user figures this out and why it is this way very quickly, but I can see why an iOS user probably finds the distinction weird.
Apps share functionality in Android. So unless the app has hijacked your back button (very rare, only games, browsers and the keyboard tend to do this now), it generally goes where you expect. It took a LONG time for the Android devs to get this right, but for the most part it works surprisingly well now.
> On the 4th screenshot in particular, there's no "up/out", but there is a settings cog that appears in none of the other screenshots.
This is DoubleTwist being cute, for them they have their chevron animate down with a backpane. The navigation has traveled to the lower left. This is confusing in screenshots, but not in practice since it is essentially a snazzy modal dialogue and the user has just spent 160ms or so watching the pane slide down. It's essentially a backpane dialogue.
> In catch, despite there being an action bar at the top, virtually all of the actions you might want to take actually seem to be in the custom bar at the bottom. I don't see how these at all demonstrate consistency.
The ActionBar generally speaks to navigation aspects of the app, not specific screen actions. In this, it's very much like iOS's topbars and clearly there was some inspiration there. It's not unusual in an iOS app to see a novel piece of chrome with fixed position for "add" and "remove" and other actions core to the app.
> Unless you play games or use some of the most popular twitter clients.
I haven't noticed any weird issues in games, but it's true that I don't play much, nor do I use twitter with any frequency.
> To be expected, they do very different things.
I agree there should be differences. My point is that with these two apps I see almost no actual similarities in the UI. If you'd told me that one of these was an Android app and the other was from, say, Meego, I'd totally have believed it.
> Evaluate their differences as deltas from the Android baseline (the way a user would), instead of as deltas from each other (which is how someone looking at screenshots on a webpage would).
Ok, but the question was whether there was more fragmentation in Android than iOS, and from what I can see the answer still appears to be yes. The deviation from the "baseline" seems higher in Android.
> Oh, because back goes to the last thing you were doing. The chevron goes up in the app. Any Android user figures this out and why it is this way very quickly, but I can see why an iOS user probably finds the distinction weird.
Maybe I'd understand this more if I used an Android device for an extended period of time. It seems that these have a ton of overlap, though. Most of the time, in my experience, up/out is the same as back, because I got to my current location by drilling down through the content. Unless back is only between apps now.
> This is DoubleTwist being cute
I get what they're doing. My point is that it's inconsistent with the platform.
> The ActionBar generally speaks to navigation aspects of the app, not specific screen actions.
Someone should tell the Google+ team. On their ActionBar, I see "write" (new post?), "refresh", "reply", and "upload picture" (I'm guessing).
> I can't speak to how consistent or inconsistent these are on Android, because I haven't used an Android device enough to really know.
They are pretty consistent. Swipe to delete in a newer action, but other than that most things tend to have similar functionality. I have mainly used 2.3 and I think I never had issues with finding UI elements. Options button helps when nothing else does.
Back button does have issues at places (browsers mostly) but it eventually takes you where you want to go. I shifted to ICS 4.0 very recently and experience is even better.
That might be because you have subconsciously (or consciously) installed apps that have similar UIs. Your other comments here indicate that you value consistent UIs strongly, so that's not suprising. The author of this blog is only targeting "beautiful" apps. I personally agree with you, most of my apps are in the ICS style. I find apps that I used to think were attractive (like DoubleTwist and DoubleTwist Alarm) to look dated now and out of place.
However we also know that normal users don't necessarily value consistency as strongly. Many developers have reported that their iOS apps do better with an in-your-face UI.
Could be. I think it's more that iOS has had a relatively consistent UI style since day 1, while Android's style has been changed more. Additionally, most Android apps have traditionally come after their equivalent iOS apps, and so have often been the victim of bad UI ports (as evidenced by the large number of Android apps that look distinctly iOS-esque).
I wonder if Window Phone will suffer from the same as it (hopefully) becomes popular. I assume the vastly different UI style will probably prevent some of this, though.
> Besides, when each app takes up all available real estate, do you really need consistency between apps?
Yes. Consistency between apps is what allows you to start up a new app and intuitively know how to use it. You shouldn't have to re-learn how to interact with each app.
> Distinctive styles are just a nice reminder of what app you're in.
Distinctive style up to a point is useful and pleasant. Gratuitous differences make interaction more awkward. Even at the purely aesthetic level, a reasonable level of consistency improves the feel of the device. When an app looks completely different from all the apps that come with the device, it looks less distinctive and more out-of-place.
I, for one, revel in diversity of looks, function, and interface. It keeps things fresh and interesting. Especially in an internet that seems to be more and more conformed to the same styles (all of googles products, twitter bootstrap, etc)
It's funny you mention that. I just got through looking at ubermusic which is almost an exact clone of (or, if you prefer, heavily inspired by) the Zune software for Windows Phone.
Looks somewhat inspired by Metro... not that that's a bad thing. ICS made a huge stride in the Android UI, and Google was even talking up the new font during the announcement.
Since ICS, Android is beautiful. Well, the OS core is, anyway. Widget makers and the like still don't seem to have got the design memo, but I suspect that's because design talents are so focused on iOS.
We just need the app makers to catch up. Foursquare, for instance, has been redesigned and looks great. However, their widgets haven't been touched and look awful by comparison. Spotify has done a far better job of updating everything at once.
It's not because design talents are focused on iOS, it's that design talents are focused on the Android users that are worth targeting. Namely, people on 2.1 or 2.2+.
Android generally monetizes/converts worse than iOS, so those who want a presence on Android can't afford to take advantage of any of the new stuff until old devices are retired sufficiently to make the tradeoff really worth it. It's been really tough to see all of the improvements, because Google is addressing user upgrades so poorly (even though the fault lies mostly with the manufacturers) that the upgrade problem is such a big deal for developers.
There are some pretty gaping holes in the compatibility library. Luckily the most important of these (ActionBar support) is covered by a great 3rd party library (ActionBarSherlock).
If anything, I think the existence of the compatibility library and ABS show that Google is dropping the ball a bit on the core Android framework. Why even have these be extra (and in one case 3rd party) libraries? Where possible why not just write the core SDK in a way such that it can fall back to 1.6 or 2.2 without having to worry about fiddling with compatibility libraries?
Precisely. Furthermore, the older platforms have major problems with stream poisoning for HTTP requests, include an incomplete beta version of Apache's HTTP classes, have old SQLite libraries which don't support upserts, and so on.
But Android was designed to allow fallback to older versions. Can you think of a case where you cannot? If anything the compatibility libraries stand as proof.
My point was the fallback should be more seamless (and shouldn't rely on 3rd party FOSS libraries, which it sometimes does).
Example 1: Fragments.
Introduced with Honeycomb. Android supports these via the "support" library back to 1.6, but the APIs you're using are slightly different (eg. getFragmentManager() vs getSupportFragmentManager()) and the classes you use live in different packages (eg. android.app.Fragment vs android.support.v4.app.Fragment). If the support library were more tightly integrated with the mainline SDK, you wouldn't have to worry about all these splits, but it isn't so you do. You have to decide up front if you want to code to the mainline SDK classes or the support versions and then this gets worse when you implement other classes which use Fragments in a library meant for other developers -- should your classes assume those developer's Fragments derive from android.support.v4.app.Fragment or android.app.Fragment? It gets really messy really fast.
Example 2: ActionBar
Not even supported via the regular support library, you have to go get ActionBarSherlock which itself extends the Android support library. Kudos to Jake Wharton on this great library, but why didn't Google just make their ActionBar backward compatible to earlier versions out of the gate? It is clearly possible to do this as ABS does it.
I'm sure there is some specific reason the Android devs could give for why the support lib and the main SDK are so increasingly fragmented and it may have a very good legacy reason for existing, but having them work this way is harmful in the long run, IMO. Maintaining this split makes things much harder for devs just trying to get into Android who are very confused by all the different decisions they have to make just to get basic app functionality working across a decent cross-section of Android devices.
Granted, I'm not saying any of this makes Android development impossible or akin to rocket science, but it does make it needlessly complex which is bad given that Android is already seen as a bit of a red-headed-stepchild to iOS development even despite the overall marketshare advantage Android has.
Google does have a backwards-compatible implementation of the action bar planned but they haven't given a release date. I agree that it shouldn't fall on the Foss community to fill this gap.
The SDK is a collection of stubs (none of the methods have an implementation), which is why the compatibility library exists as an add-on. The library does fall back to the native implementation on versions of the OS that support it for whatever you're using the library for.
The problem with the Android UI isn't (only) the lack of beauty, it's the lack of consistency, style and attention to detail. Things like included/used fonts (although the default iOS notes app also fails horribly here), placement of back buttons. And that's exactly one of the things that disturb me in the Android UI, things like the 'back' functionality, which is utterly confusing. In iOS the 'back' button is always on the same location AND tells you where you're going back to. Android has a dedicated button, and it surprised me more than enough where it was taking me back to.
So yes, Android could use a better/cleaner visual style, but that's not it's biggest problem. Also, if a new visual style would be adopted, it should be universal. Right now it's a mess of apps trying to do their own thing because the default style is ugly, and these examples demonstrate that perfectly... Android 4 has shown some improvement but I still don't like it.
There are also quite a few iOS apps that don't necessarily respect the general look&feel of iOS, but some of them succeed in having a distinct style without clashing badly with the rest of the interface. Hell, Google showed that it is capable of doing just this, just look at the Google+ and the new YouTube app, they are pretty neat.
I think Android UI designers should use iPhones and Windows 7/8 phones as their daily device, or switch at least once every week. Then they'd see what's wrong, what irritates them about every OS and find a way around some of the moronic decisions were made in some of these OS's, and all are guilty of this to some extend. Android at this moment however gets the crown in usability WTF's.
Disclaimer: I own an iPhone and iPad, but mainly develop for Android/BB/WinMobile.
>And that's exactly one of the things that disturb me in the Android UI, things like the 'back' functionality, which is utterly confusing.
I think this is more of a personal preference thing than something that is broken. I use an android phone, and used to use a honeycomb tablet. When i replaced the tablet with an iPad, the thing i hated most about iOS was the back button behaviour. In iOS back takes you back to wherever the application developer thinks back should take you. In Android, except for very rare cases, back takes you back to the previous screen you were on, which might be up one level like on iOS, or it might be a different app entirely. One isn't better than the other, they're just different functions.
In iOS the 'back' button is always on the same location AND tells you where you're going back to.
Yes, that is true, but only for a screen with a back button, otherwise that spot on the screen is probably an "edit" or something else you don't want to do. And after you realize its not "back", you're off hunting around the rest of the screen for the "done" or "cancel" button. Unless of course, you came from a different screen on the same logical "level", where to go back to the screen you came from means picking from one of the row of tabs at the bottom of the screen. Unless you're in an app with a row of tabs at both the top and the bottom of the screen. In that case, the tabs at the top might belong to the page selected at the bottom, or the tabs at the bottom might belong to the page selected at the top, hopefully the UI has been designed with a visual afforance to give you a hint.
Disclaimer: I've been using an iPhone for about 2 months after 2 years of android ownership. They both have their own way of doing things that you can get used to one and think the other feels foreign. FWIW, After time and familiarity, you forget to look at it critically; iOS UI is clunky and unintuitive, its just that us iOS owners have been tossing eachother off about just how great iPhones are for years. And you can't pretend like this isn't true, now that I'm in the club, iDevice owners try to get me to join in some collective pursuance-rationalization quite frequently.
For anyone looking for a fully-featured notes app, Catch, mentioned in TFA, is the way to go. It does sync, has a web interface, and probably a 100 other features I haven't used.
I have never seen a UI from the seventies, but I imagine them being more DOS-y. Yes, the design has not received any major upgrades for 5 years now, but this also makes users "feel at home". I once switched from my iPhone 1 to an HTC Desire because I wanted a fresh look - but boy did I wish my iPhone back after some weeks.
I'm now both an iOS & Android dev and designer (and owning quite some devices from both sides), but I'll choose an iPhone anytime over iOS. There is no Android experience. There is only a Galaxy Nexus experience, an S3 experience,... But there IS an iPhone experience, and I know that my phone won't restart on me when I want to show my ticket to the train conductor.
Of course Android can be beautiful if you showcase a few screen shots created by some very talented designers. After spending the last 4 years as an Android developer, its clear that the platform falls short in two places at the intersection of UX and UI. I've worked with some of the best designers and they always produced beautiful assets and screens, but we were always left making important UX decisions that caused inconsistency with other apps. The "beauty" that many users come to appreciate with iOS and Metro, is the cross app consistency, experience and cohesion with the operating system itself. Even apps produced by Google have a tremendously wide gap in consistency. The other major problem is development decisions made (and allowed by the platform) by software engineers. More than a few of the apps in this list do unthinkable things like processing data on the UI thread or having terrible offline experiences. This can turn a beautifully designed app into a terrible app very quickly.
It's important to distinguish "looks pretty" and "beautiful".
Oh for the love of God, we still need convincing of this? Anyone with an ICS/JB phone knows that Android is perfectly capable of looking good. My "least-good" looking application that I use on a regular basis is the Flashlight app, and even then, it's just a big round glossy button.
Very happy to see the Bump 3.0 on there (I worked on it). ICS and all of it's native apps were a great statement by Google to show how they'd like their apps to look and feel. We followed their queue and used the action bar and view pager to great success. Also having a great visual designer doesn't hurt either.
I agree that Android can look gorgeous, but that can only go so far. Android's problem is consistency. I've used every alternate android build I could find, and the custom (and default) themes and UI menu system lacked consistency. My favorite was MiUi and even that had terrible consistency issues.
iOS, on the other hand, is supremely superior in this department. The cohesiveness of the experience is second to none. I value that over custom configurations any day. My android phones have been wonderful hack-fests, but at the end of the day, the one thing I can't hack into them is a consistent experience.
I find the iOS UI patterns to be consistent, but the "skins" on those UI elements tend to vary quite a bit. Now this is the case on the iPad, since I don't have an iPhone I cannot speak to that. Just getting a podcast program on android that had a consistent UI where things made sense was a fruitless effort. Streaming content is not consistent either, some apps stream really well (audio galaxy), while other stream terribly. These are the types of things that I found maddening.
The ActionBar is very consistent on these apps - of the first several dozen I only saw 2 that were not using an ActionBar.
Streaming has nothing to do with UI consistency. It's a battle, because the APIs are very high level and you're limited in the amount of control you have without a ton of work, and it seems like manufacturers are screwing with the stack somewhere. Doesn't matter, though, because we're talking about UI consistency.
The podcatcher app is sort of ripe for some good competition in this space, with Google Listen no longer available. I am working on something. http://imgur.com/RtG8e , but someone else should get in here too.
Specifically for podcasts, I have found the Doggcatcher app to be very high quality, streams very well, and still has plenty of options and features to make it work exactly how you want it to. It's $5 and well worth it:
I just dont see. Beatuiful is extremely subjective, so the title of this is inherently incorrect. And beautiful they may be, but they are not usable, consistent, or friendly. And the ones that are close to being good, have niggling issues like spacing between items, which drives me nuts
There's a horizontal scrollbar per photoset just below the photo's.
I'm guessing this was designed by someone with a multitouch trackpad. I know I tend to forget not everyone else has 2 finger scroll at their fingertips, I've had to get into a habit of having a test run using a mouse when I put together pages.
I see them now. I missed them because they don't look like scroll bars. I don't even know what 2 finger scroll is. I usually scroll with my mouse wheel. To scroll horizontally, I click the middle mouse button. These scroll bars seem not to support that.
I only found them after I went looking because of your comment. Seems weird not just to have the single horizontal scroll at the bottom, it's too fiddly.
Those of us using multitouch trackpads can scroll by just swiping on the page using N fingers, like scrolling on a touch phone by dragging the page with your finger.
Android is no longer an ugly-duckling platform trying to catch up with iOS, but a beautiful platform that truly rivals iOS in all important ways -- and now surpasses it in terms of market share. However, mobile app developers have only recently begun to transition from "we need an app for Android too, quick!" to "we need great apps for both Android and iOS," so it will take a little while for all those ugly, hastily-put-together Android apps to become a thing of the past.
Is there a way to see how the fragmentation (most important for me: screen size) is at this moment? I've got a low end android phone (Galaxy Mini) which works well but I can't install a lot of stuff (Path comes to mind) because of screen resolution.
I think the mobile OS market is going to end looking somewhat similar to the PC OS market, but changing Windows for Android. The market share race is impossible for Apple to win with their current pricing and model range. It's normal to see a lot of activations if the cheapest phone is $50
I wish Google would force manufacturers to stop using the 320x240 resolution. The browsing experience is very poor on such a resolution, unless you're using Opera Mini perhaps, and I imagine it's hard for developers to refit their apps for such a small resolution, too, as even menu text will take a lot of space on that resolution.
I also wish they mandated everyone has at least 512 MB of RAM in their phones, and at least 2 GB for the OS and 2 GB of app space. That way upgrades can be ensured for years, and people, especially regular people, can actually install more than 5 apps without running out of space (and no, App2SD doesn't count, and it's almost useless). And while they are at it, they should also stop supporting the ARMv6 architecture, now that the ARMv7 Cortex A5 and next year Cortex A7 are going to be used.
If Google wants to bring down the hammer on manufacturers, it should be for stuff like this, that ensures users of Android devices, even at the very low-end, get a pretty good experience, otherwise they'll always think Android devices are crap, after their first cheap Android smartphone. They don't want that kind of perception to affect the Android brand in the long term.
I kind of doubt that users of low-end phones know what Android is or know what they're missing. It's not like they're downgrading from an iPhone, they're probably upgrading from a feature phone. And even the worst Android phone is much nicer than that.
Eventually they will upgrade to a nice Android phone, and will enjoy the enhanced user experience. But cost does matter to some people, and although browsing at 320x240 is hardly ideal, it's probably better than not being able to buy food for a week.
(I personally use very few apps aside from the default Google apps. I mostly want to receive text messages, make phone calls, and browse the web. Apps, to me, don't add much value when the app-maker already has a perfectly fine website.)
I'm a hacker news user, and I have a cheap phone with a 320x240 single-touch screen and keyboard. I don't see what's so bad about browsing the web on it, I can certainly access HN fine enough.
The same could be said about browsing the web with IE6, that doesn't mean that the latest Chrome/Firefox won't provide a much better and smoother experience.
> they're probably upgrading from a feature phone. And even the worst Android phone is much nicer than that.
I would disagree - I've heard quite a few non-technical people say they are never getting another android because they are so frustrated by their gingerbread/froyo handsets. They envy the iPhone simply because they never hear people swearing at them (whereas their phones prompt a tirade of profanity)
>Eventually they will upgrade to a nice Android phone
Anecdotally I know people who had cheap Android phones and then upgraded to an iPhone because their experience with Android was terrible.
That being said I don't really think it's Google's job to protect Samsung's future profits from being eaten into by people's poor experience with a crappy LG phone. It's just one more case where Apple's total control model is beneficial to them.
Exactly. The free-with-contract market is real, and wants smartphone features. If "Google Android" doesn't want that market (which isn't insane, iOS doesn't want it) then something else will fill the niche, and "AOSP Android" is the most likely candidate.
The grandparent's desire is isomorphic to wanting Google to force users to spend more on their phones so she has to spend less on her software. That's not a good business tactic.
What I've suggested in the past is that Google introduce a new brand like "Android Platinum" for the high end. For manufacturers to be allowed to use the brand, they'd have to meet requirements on minimum specs and commit to timely OS updates for some period.
I don't think screen size is a big problem for Android. Yes it makes good design harder but not impossible. I think the bigger problem is the inconsistent implementation of low level APIs, broken functionality on specific phones etc. They all require special care which makes developing a high quality Android app very hard. My thoughts on the issue in detail: http://birbit.com/the-real-problem-with-android-fragmentatio...
I don’t know about screen size fragmentation, but here’s a chart of Android OS versions currently in use: http://developer.android.com/about/dashboards/index.html. Android 2.3 Gingerbread is the most common version right now.
The apps look great for sure and it seems like the big dogs are prioritizing Android. Many of these examples are in fact on both platforms, and overall they look better on iOS than the android version. On Android they look like a modified, less 'pretty' version of the iOS app- particularly the ones that carry over iOS design patterns.
I meant the big app developers. Its a throwaway comment for sure. I was just trying to encourage the original idea of the post while taking out its legs by pointing out how most of these don't look as good as they do on iOS.
your original comment says one thing (prioritization of Android) then another (how a lot of Android apps repurpose iOS designs).
Are you saying there's a general appreciation for Android, so it's higher priority nowadays?... or are you saying Android is actually being prioritized over iOS? The latter would be surprising imo.
What does this site have to do with android anyway? Isn't the article basically saying, its possible to develop good looking apps on android?
The problem with android is that it never had any design language like iPhone and the Windows Phone have. They give a framework for an app developer to work within. It inspires them to make consistent beautiful designs. Android has always been this free-form thing which I think caused many ugly apps to be developed for it.
Windows Phone market place for one is full of such beautiful apps, thanks to the detailed guidelines about the metro design.
This is still a recent development. It never had this originally. Besides going by the ugly apps, it hasn't had much impact so its ineffective at best.
162 comments
[ 3.4 ms ] story [ 218 ms ] threadThe issue we've seen is that people build an iOS app and then port it over to Android.
We designed Catch 5.0 apps for Android and iPhone in parallel. This let us keep consistency between the platforms when it made sense, but also let us tweak the design early on so it could take advantage things unique to the platform, e.g. Action Bar on Android.
The team is incredibly proud of this release, and it is nice to see folks taking notice. Both Google and Apple have also featured this release, everybody is beaming here. =)
I just wish I had more than one friend actually using it. Heh.
Flagged.
Now that I can see the examples, they are actually pretty decent.
>> As it stands, If you design a great app for Android and people say 'hey, that looks like an Android app', that means you've failed.[1]
[1] https://twitter.com/sdw/status/187245772205600769
I mean, it is pretty (well, arguably, most of them are), but, the buttons are all over the place and everyone seems to have it's own UI plastered on top of more or less "android ui compliant" stuff.
Look closely though. You'll notice the ActionBar is extremely prevalent in these. The ActionBar is actually one of those few Android teachable moments; I wish Apple did this as well, as consistently, or as themably. I've used a lot of these apps (and I am sad to not see Pattrn up there!) and it's very much the case that they have a fairly consistent set of "touch semantics" that screenshots don't reveal. E.g., Tap upper right corner to configure; long press for edit; swipe horizontally to navigate; long press on text fields to engage c/p editor bar.
For better or worse, Android's toolkits offer a lot more guidance to the programmer on "the right way" than Apple's do (a great example of this that bleeds into UI is how Android has a ton of Loader patterns and iOS doesn't have anything nearly so sophisticated in its core lib). So in some respects, Android is actually slightly better off; the bigger toolkit means you get some superior consistency. The recent iterations (and backported support) framework strongly encourages you to do things like support long presses and swipe navigation and backpane navigation.
So let's just pretent this isn't a shitty genetic fallacy post and address your challenge head on, "Back up your example and prove to me Android's APIs give more guidance than Android's in how to do ______." I specifically mentioned the Loader pattern.
Compare: Google's Loader pattern: http://developer.android.com/reference/android/content/Loade...
A concrete and common example, doing an async task: http://developer.android.com/reference/android/content/Async...
Compare this to the equivalent API for doing async task usage in iOS: http://developer.apple.com/library/ios/#documentation/Perfor...
In iOS There is no concept of a "Loader", so the community has come up with stuff like AsyncUIImageView and friends (code here: https://github.com/nicklockwood/AsyncImageView) which still doesn't entirely solve the problem, because solving the problem takes a lot of framework support.
Sadly, fragmentation is at play again in this; and many Android developers don't use Loaders because they're intimidated or confused or can't use them for their entire panoply of supported devices; so there are a fair share of Android apps that do not use them. You can usually catch this if you change orientation and see things reload from scratch.
Given the rapidly increasing velocity of deployment of 4.0 devices, I think this issue with framework fragmentation is transient.
None of these general aesthetics are bad, but the inconsistency seems to be an issue. (Actually, a few of them do look bad to me, like Rdio, with the very dated "app home screen" that looks like it was copied from the old Facebook iOS app.)
I'm not sure why you'd say this. Android actually hasn't suffered from tactile UI fragmentation much more than iOS has.
If the apps on this page a representative, I'd say that Android has experienced a lot more UI fragmentation than iOS. These are being held up as examples of best Android interfaces, and they look very inconsistent to me.
In contrast, I just opened up a bunch of random apps on my phone's home screen, and they all look very much like "iOS style". Obviously the native apps match well, but so does OneBusAway, Wikipanion, Skype (though the UI is flatter than the rest), Google Voice, Amazon, OneNote, etc.
These all look like iOS apps to me.
http://itunes.apple.com/us/app/onebusaway/id329380089
http://itunes.apple.com/us/app/wikipanion/id288349436
http://itunes.apple.com/us/app/skype/id304878510
http://itunes.apple.com/us/app/google-voice/id318698524
http://itunes.apple.com/us/app/amazon-mobile/id297606951
http://itunes.apple.com/us/app/microsoft-onenote/id410395246
But to my eyes as an Android user, I see a lot of consistency here. The ActionBar is firmly in place, so I know where to go for navigation. The visual metaphors vary in terms of actual look, but I get what's up.
For example, compare to very different apps: Catch and doubleTwist Alarm Clock. Both are "bounded" by their top bar (although Catch has elected to add extra app-specific chrome at the bottom, too). The navigation "upwards our out" between panes is consistently in the upper left. The additional actions for the app as a whole are on the top right.
In cases where the apps deviate (e.g., bottom bars in Gmail and Catch), the designers have had the good sense to use the standardized icons as opposed to further customization, helping to signal the user that this app does deviate from pure actoinbar navigation. The share, attach, favorite, and trash icons are all with pixels of standard.
A lot of iOS users first coming to Android (including myself) after the advent of ICS may be surprised once they realize how consistent the presence of the ActionBar is, even if it varies in appearance. I encourage you to play with one to see this in action. I certainly felt that sense of confusion at first because I'm used to unified navigation chrome from iOS for most things outside of games. I think this is just a case of longtime iOS users not being familiar with the visual language of the Android platform.
I personally don't run into a ton of issues in iOS with determining what swipes vs long-presses vs long-taps do. Swipes in a list tend to invoke the "delete" context. Swipes up/down scroll. Tap to invoke. Long-tap for select in a text context. There's certainly not 100% consistency, but it seems fairly consistent to me with the apps I use. I can't speak to how consistent or inconsistent these are on Android, because I haven't used an Android device enough to really know.
Speaking to Catch and doubleTwist, these seem inconsistent to me. Visually, they're quite different, but there seem to be pretty significant functional differences. Many of the doubleTwist screens do not have the "up/out" chevron in the upper left (how is this not redundant with the global "back", anyway?). On the 4th screenshot in particular, there's no "up/out", but there is a settings cog that appears in none of the other screenshots. It appears that doubleTwist also uses a "slide to reveal" metaphor (invoked by the chevron on the main screen) that isn't in Catch or the other apps. In catch, despite there being an action bar at the top, virtually all of the actions you might want to take actually seem to be in the custom bar at the bottom. I don't see how these at all demonstrate consistency.
Unless you play games or use some of the most popular twitter clients. ;)
> Visually, they're quite different, but there seem to be pretty significant functional differences.
To be expected, they do very different things. I chose them because of their differences. Both apps have deviated from a very mellow Holo standard without introducing a lot of confusion. Evaluate their differences as deltas from the Android baseline (the way a user would), instead of as deltas from each other (which is how someone looking at screenshots on a webpage would).
> (how is this not redundant with the global "back", anyway?)
Oh, because back goes to the last thing you were doing. The chevron goes up in the app. Any Android user figures this out and why it is this way very quickly, but I can see why an iOS user probably finds the distinction weird.
Apps share functionality in Android. So unless the app has hijacked your back button (very rare, only games, browsers and the keyboard tend to do this now), it generally goes where you expect. It took a LONG time for the Android devs to get this right, but for the most part it works surprisingly well now.
> On the 4th screenshot in particular, there's no "up/out", but there is a settings cog that appears in none of the other screenshots.
This is DoubleTwist being cute, for them they have their chevron animate down with a backpane. The navigation has traveled to the lower left. This is confusing in screenshots, but not in practice since it is essentially a snazzy modal dialogue and the user has just spent 160ms or so watching the pane slide down. It's essentially a backpane dialogue.
> In catch, despite there being an action bar at the top, virtually all of the actions you might want to take actually seem to be in the custom bar at the bottom. I don't see how these at all demonstrate consistency.
The ActionBar generally speaks to navigation aspects of the app, not specific screen actions. In this, it's very much like iOS's topbars and clearly there was some inspiration there. It's not unusual in an iOS app to see a novel piece of chrome with fixed position for "add" and "remove" and other actions core to the app.
I haven't noticed any weird issues in games, but it's true that I don't play much, nor do I use twitter with any frequency.
> To be expected, they do very different things.
I agree there should be differences. My point is that with these two apps I see almost no actual similarities in the UI. If you'd told me that one of these was an Android app and the other was from, say, Meego, I'd totally have believed it.
> Evaluate their differences as deltas from the Android baseline (the way a user would), instead of as deltas from each other (which is how someone looking at screenshots on a webpage would).
Ok, but the question was whether there was more fragmentation in Android than iOS, and from what I can see the answer still appears to be yes. The deviation from the "baseline" seems higher in Android.
> Oh, because back goes to the last thing you were doing. The chevron goes up in the app. Any Android user figures this out and why it is this way very quickly, but I can see why an iOS user probably finds the distinction weird.
Maybe I'd understand this more if I used an Android device for an extended period of time. It seems that these have a ton of overlap, though. Most of the time, in my experience, up/out is the same as back, because I got to my current location by drilling down through the content. Unless back is only between apps now.
> This is DoubleTwist being cute
I get what they're doing. My point is that it's inconsistent with the platform.
> The ActionBar generally speaks to navigation aspects of the app, not specific screen actions.
Someone should tell the Google+ team. On their ActionBar, I see "write" (new post?), "refresh", "reply", and "upload picture" (I'm guessing).
They are pretty consistent. Swipe to delete in a newer action, but other than that most things tend to have similar functionality. I have mainly used 2.3 and I think I never had issues with finding UI elements. Options button helps when nothing else does.
Back button does have issues at places (browsers mostly) but it eventually takes you where you want to go. I shifted to ICS 4.0 very recently and experience is even better.
However we also know that normal users don't necessarily value consistency as strongly. Many developers have reported that their iOS apps do better with an in-your-face UI.
I wonder if Window Phone will suffer from the same as it (hopefully) becomes popular. I assume the vastly different UI style will probably prevent some of this, though.
Yes. Consistency between apps is what allows you to start up a new app and intuitively know how to use it. You shouldn't have to re-learn how to interact with each app.
> Distinctive styles are just a nice reminder of what app you're in.
Distinctive style up to a point is useful and pleasant. Gratuitous differences make interaction more awkward. Even at the purely aesthetic level, a reasonable level of consistency improves the feel of the device. When an app looks completely different from all the apps that come with the device, it looks less distinctive and more out-of-place.
http://gadgetix.com/wp-content/uploads/2011/08/Uber-Music-fo...
http://www.youtube.com/watch?v=7f92ptAjm3I
http://www.youtube.com/watch?feature=player_embedded&v=f...
http://www.reddit.com/r/androidthemes/
We just need the app makers to catch up. Foursquare, for instance, has been redesigned and looks great. However, their widgets haven't been touched and look awful by comparison. Spotify has done a far better job of updating everything at once.
Android generally monetizes/converts worse than iOS, so those who want a presence on Android can't afford to take advantage of any of the new stuff until old devices are retired sufficiently to make the tradeoff really worth it. It's been really tough to see all of the improvements, because Google is addressing user upgrades so poorly (even though the fault lies mostly with the manufacturers) that the upgrade problem is such a big deal for developers.
http://developer.android.com/tools/extras/support-library.ht...
So older Android versions can use modern apps. Both the examples I gave (Foursquare, Spotify) work with both newer and older versions.
If anything, I think the existence of the compatibility library and ABS show that Google is dropping the ball a bit on the core Android framework. Why even have these be extra (and in one case 3rd party) libraries? Where possible why not just write the core SDK in a way such that it can fall back to 1.6 or 2.2 without having to worry about fiddling with compatibility libraries?
Example 1: Fragments.
Introduced with Honeycomb. Android supports these via the "support" library back to 1.6, but the APIs you're using are slightly different (eg. getFragmentManager() vs getSupportFragmentManager()) and the classes you use live in different packages (eg. android.app.Fragment vs android.support.v4.app.Fragment). If the support library were more tightly integrated with the mainline SDK, you wouldn't have to worry about all these splits, but it isn't so you do. You have to decide up front if you want to code to the mainline SDK classes or the support versions and then this gets worse when you implement other classes which use Fragments in a library meant for other developers -- should your classes assume those developer's Fragments derive from android.support.v4.app.Fragment or android.app.Fragment? It gets really messy really fast.
Example 2: ActionBar
Not even supported via the regular support library, you have to go get ActionBarSherlock which itself extends the Android support library. Kudos to Jake Wharton on this great library, but why didn't Google just make their ActionBar backward compatible to earlier versions out of the gate? It is clearly possible to do this as ABS does it.
I'm sure there is some specific reason the Android devs could give for why the support lib and the main SDK are so increasingly fragmented and it may have a very good legacy reason for existing, but having them work this way is harmful in the long run, IMO. Maintaining this split makes things much harder for devs just trying to get into Android who are very confused by all the different decisions they have to make just to get basic app functionality working across a decent cross-section of Android devices.
Granted, I'm not saying any of this makes Android development impossible or akin to rocket science, but it does make it needlessly complex which is bad given that Android is already seen as a bit of a red-headed-stepchild to iOS development even despite the overall marketshare advantage Android has.
Kind of meta but IMO the screenshots on that site are too big and should be scaled down a bit.
The XL is the actual size (pixel-wise) that you would see on a phone such as the Galaxy Nexus.
So yes, Android could use a better/cleaner visual style, but that's not it's biggest problem. Also, if a new visual style would be adopted, it should be universal. Right now it's a mess of apps trying to do their own thing because the default style is ugly, and these examples demonstrate that perfectly... Android 4 has shown some improvement but I still don't like it.
There are also quite a few iOS apps that don't necessarily respect the general look&feel of iOS, but some of them succeed in having a distinct style without clashing badly with the rest of the interface. Hell, Google showed that it is capable of doing just this, just look at the Google+ and the new YouTube app, they are pretty neat.
I think Android UI designers should use iPhones and Windows 7/8 phones as their daily device, or switch at least once every week. Then they'd see what's wrong, what irritates them about every OS and find a way around some of the moronic decisions were made in some of these OS's, and all are guilty of this to some extend. Android at this moment however gets the crown in usability WTF's.
Disclaimer: I own an iPhone and iPad, but mainly develop for Android/BB/WinMobile.
I think this is more of a personal preference thing than something that is broken. I use an android phone, and used to use a honeycomb tablet. When i replaced the tablet with an iPad, the thing i hated most about iOS was the back button behaviour. In iOS back takes you back to wherever the application developer thinks back should take you. In Android, except for very rare cases, back takes you back to the previous screen you were on, which might be up one level like on iOS, or it might be a different app entirely. One isn't better than the other, they're just different functions.
Yes, that is true, but only for a screen with a back button, otherwise that spot on the screen is probably an "edit" or something else you don't want to do. And after you realize its not "back", you're off hunting around the rest of the screen for the "done" or "cancel" button. Unless of course, you came from a different screen on the same logical "level", where to go back to the screen you came from means picking from one of the row of tabs at the bottom of the screen. Unless you're in an app with a row of tabs at both the top and the bottom of the screen. In that case, the tabs at the top might belong to the page selected at the bottom, or the tabs at the bottom might belong to the page selected at the top, hopefully the UI has been designed with a visual afforance to give you a hint.
Disclaimer: I've been using an iPhone for about 2 months after 2 years of android ownership. They both have their own way of doing things that you can get used to one and think the other feels foreign. FWIW, After time and familiarity, you forget to look at it critically; iOS UI is clunky and unintuitive, its just that us iOS owners have been tossing eachother off about just how great iPhones are for years. And you can't pretend like this isn't true, now that I'm in the club, iDevice owners try to get me to join in some collective pursuance-rationalization quite frequently.
If anybody has any questions feel free to email me at a@catch.com
I'm now both an iOS & Android dev and designer (and owning quite some devices from both sides), but I'll choose an iPhone anytime over iOS. There is no Android experience. There is only a Galaxy Nexus experience, an S3 experience,... But there IS an iPhone experience, and I know that my phone won't restart on me when I want to show my ticket to the train conductor.
It's important to distinguish "looks pretty" and "beautiful".
iOS, on the other hand, is supremely superior in this department. The cohesiveness of the experience is second to none. I value that over custom configurations any day. My android phones have been wonderful hack-fests, but at the end of the day, the one thing I can't hack into them is a consistent experience.
Streaming has nothing to do with UI consistency. It's a battle, because the APIs are very high level and you're limited in the amount of control you have without a ton of work, and it seems like manufacturers are screwing with the stack somewhere. Doesn't matter, though, because we're talking about UI consistency.
The podcatcher app is sort of ripe for some good competition in this space, with Google Listen no longer available. I am working on something. http://imgur.com/RtG8e , but someone else should get in here too.
https://play.google.com/store/apps/details?id=com.snoggdoggl...
I'm surprised that so apps look WP metro style
I'm guessing this was designed by someone with a multitouch trackpad. I know I tend to forget not everyone else has 2 finger scroll at their fingertips, I've had to get into a habit of having a test run using a mouse when I put together pages.
Those of us using multitouch trackpads can scroll by just swiping on the page using N fingers, like scrolling on a touch phone by dragging the page with your finger.
UPDATE: koko775 raises a good point: the large installed base of pre-ICS Android versions may also be a factor. See http://news.ycombinator.com/item?id=4533819
I think the mobile OS market is going to end looking somewhat similar to the PC OS market, but changing Windows for Android. The market share race is impossible for Apple to win with their current pricing and model range. It's normal to see a lot of activations if the cheapest phone is $50
I also wish they mandated everyone has at least 512 MB of RAM in their phones, and at least 2 GB for the OS and 2 GB of app space. That way upgrades can be ensured for years, and people, especially regular people, can actually install more than 5 apps without running out of space (and no, App2SD doesn't count, and it's almost useless). And while they are at it, they should also stop supporting the ARMv6 architecture, now that the ARMv7 Cortex A5 and next year Cortex A7 are going to be used.
If Google wants to bring down the hammer on manufacturers, it should be for stuff like this, that ensures users of Android devices, even at the very low-end, get a pretty good experience, otherwise they'll always think Android devices are crap, after their first cheap Android smartphone. They don't want that kind of perception to affect the Android brand in the long term.
Eventually they will upgrade to a nice Android phone, and will enjoy the enhanced user experience. But cost does matter to some people, and although browsing at 320x240 is hardly ideal, it's probably better than not being able to buy food for a week.
(I personally use very few apps aside from the default Google apps. I mostly want to receive text messages, make phone calls, and browse the web. Apps, to me, don't add much value when the app-maker already has a perfectly fine website.)
I would disagree - I've heard quite a few non-technical people say they are never getting another android because they are so frustrated by their gingerbread/froyo handsets. They envy the iPhone simply because they never hear people swearing at them (whereas their phones prompt a tirade of profanity)
Anecdotally I know people who had cheap Android phones and then upgraded to an iPhone because their experience with Android was terrible.
That being said I don't really think it's Google's job to protect Samsung's future profits from being eaten into by people's poor experience with a crappy LG phone. It's just one more case where Apple's total control model is beneficial to them.
Wouldn't that be worse for (1) customers, (2) android's reputation and (3) Google?
The grandparent's desire is isomorphic to wanting Google to force users to spend more on their phones so she has to spend less on her software. That's not a good business tactic.
Warning massive derail... One thing the tech commentariat has slacked off on is better labels for different Android flavors. I'd suggest:
AOSP = "Opendroid" (forkdroid?)
stock Android (Opendroid + Google services/ecosystem) = "stockdroid"
Android + Touchwiz/Sense = "Samdroid"/"Sensedroid"
Opendroid + Amazon services/ecosystem = "Amazdroid"
Samsung Galaxy Chat B5330 http://www.gsmarena.com/samsung_galaxy_chat_b5330-4866.php
ZTE Style Q http://www.gsmarena.com/zte_style_q-4602.php
A couple of more devices which are reportedly coming soon: http://goo.gl/F411K
These are cheap phones, though I imagine you'd get a much better deal if you spent the same amount of money on a used Android phone.
Who are those big dogs? Google? :) Microsoft? :)) Apple? :)))
Are you saying there's a general appreciation for Android, so it's higher priority nowadays?... or are you saying Android is actually being prioritized over iOS? The latter would be surprising imo.
The problem with android is that it never had any design language like iPhone and the Windows Phone have. They give a framework for an app developer to work within. It inspires them to make consistent beautiful designs. Android has always been this free-form thing which I think caused many ugly apps to be developed for it.
Windows Phone market place for one is full of such beautiful apps, thanks to the detailed guidelines about the metro design.
Also, the Google guide is much nicer to look at itself than MS's.