This is a long overdue but very well put-together UI and Usability Guide for Android Developers. My only qualm from reading it thus far is the very last section under Navigation [1] regarding System-to-app navigation:
"For the Back key, you should make navigation more predictably [sic] by inserting into the task's back stack the complete upward navigation path to the app's topmost screen."
No. This piece of advice is the sole reason why the back button is confusing to users. Injecting activities artificially onto a user's Back Stack based on some arbitrary and imaginary path that they might have taken to get there is horrible. If I'm in the middle of reading a book and get an email notification, and I touch that notification to quickly read the email, that Back button better damn well take me BACK to what I was doing. Don't take me UP to the list of emails in my inbox. This is where the average user will become lost and not understand why they aren't taken back to reading their book, and will just end up touching Home out of frustration.
This was a huge frustration for me on 2.x. I'm glad they're suggesting that people insert fake activities to fix it.
Here's an example -- from the homescreen, click a Music widget. The Music app opens and shows the song I was listening to. I want to go back to the playlist I was playing from so I hit back. Instead, I'm dumped back to my home screen. you have to hit the Google Music icon in the top-left to go back within the Music app. I don't mind having to hit back a couple of times because I've learned that you can just keep hitting back and you'll eventually get where you were.
The way you suggest is why Android's back is confusing. If I hand you my phone and put you on a particular screen and ask you "if you press back right now where will you end up" you have no idea
Even if it's your own phone if it's been a few minutes, hours since you last used an app you'll have no idea.
Here’s what I hope is an objective fact about the Android back button. IT’S NOT PREDICTABLE!
The way it works is that each app has a “stack” of screens. Pressing the back button pops the current screen off that stack revealing the screen below. If there are none you are taken to the home screen. The problem is let’s say you start the Messaging app. The first screen is “list” of conversations screen. You pick a conversation and now you are on the “conversation” screen. From the conversation screen you press “back” and you get the “list” screen. Press back again you get the “home” screen.
Now let’s take another senario. You are in the browser. You get a notification that you have a new message. You select the notification for the message. You are taken to the “conversation” screen. You press home and do something else, say listen to music. Later you decide you want to send a message to someone. You go the home screen and pick the messaging app. Since the app is still running you see the “conversation” screen. You press back you get the “home” screen. WTF!
In the first case it went “conversation”->”list” in the second case it went “conversation”->”home”
Notice in this case, even if you had an amazing memory and could remember that you happened to launch the messaging app from a notification an hour ago or last night or something you still have no direct way to get to the “list” screen. The only way there is to select the messaging app either from the home screen or the recently used list. You’ll get the “conversation” screen. You press “back” and you’ll exit the messaging app back to the “home” screen. Now you have to navigate the home screen to the screen that has the messaging app icon on it so you can re-launch the messaging app and have it start in on the “list” screen.
Android should never have had a back button in the first place. If there was no back button there'd be no way to make it inconsistent. Switching back to another app would be come the simple habit of holding home for a moment and picking the app you want to go back to and you'd always be able to predict where any button will take you.
I applaud them for trying to fix it but putting in the guidelines, which may or may not be read by the majority of devs, seems unlikely to fix the problem.
Google Voice follows (or used to, at least) your advice, which led to endless frustration. You'd tap a notification to read a text, then have no way at all to get to the main screen of the Google Voice app. In Android 4.0, Google Voice has an app-specific back button that helps, but I think Google's advice on this is correct.
I happen to like this functionality and don't think it's confusing at all. As long as pressing back eventually gets me back to where I was before it's just fine.
I think this in an interesting discussion. Sometimes the user presses back to go to the previous screen, sometimes to go to the parent element (i.e., when you're seeing an email and press back to return to your inbox).
For me, the best solution would be make the back button come back to the previous screen, ignoring where they are. So, if you are playing Angry Birds, tap an email notification and then press back, you return to Angry Birds. But, also, in screens in which the user may want to go to the parent element, developers should put a button to go "home". In the email screen, a button to go back to inbox, in the Music app a button to go to the Music app initial screen...
Of course the real problem isn't which back button behavior too choose, it's that there's a choice to be made at all.
Both back button behaviors are perfectly valid and convincing arguments can be made for each, so the choice is pretty much arbitrary. But if Google doesn't enforce any particular behavior and leaves it up to the developers, the only possible result is confusion.
Additionally one could make the argument that the whole back button concept itself is inherently confusing, precisely because the right choice of behavior isn't obvious.
I like Android, but the back button is totally useless to me. It only works in the simplest of cases, namely when opening an app and not navigating beyond that, I know I can press the back button to get to the home screen.
Otherwise, my workflow basically goes: press home button, use the task manager to kill everything, then visit an app and navigate top-down to where I want to go. Rinse and repeat for the next app. Like others have been saying, the back button is inherently either arbitrary or confusing, and I don't know how to fix it.
It should be replaced as a permanent UI feature with a task switcher button. I don't know how a modern operating system can get by without some sort of taskbar equivalent. I need to know what apps are open, and be able to navigate to them and close them as needed. Why has this not been implemented? I'd suggest putting this into the slide down top bar if there weren't full screen apps that totally break this function. Therefore, I suggest replacing the back button with a task switcher. I won't be holding my breath.
The ideal behavior would be if the app is launched via another app it should not touch the back stack. If I launch the email app from the home screen or app folder, it should populate the back stack so that hitting back brings me from the email I had open to the inbox.
My motivation for debating the two uses of the back button is whether I prefer a smooth OS integration (back as in back in time) or whether I prefer displaying more ads and am willing to capture the user inside (back as in up within my app).
It has unfortunately little to do with UX, since both end up being confusing on edge cases (Astro's horribly enraging "press back twice to 'exit'", the conversation or gmail app issues people mentioned in this thread).
I personally tend to prefer back as in back in time but I know for sure opinions vary.
Weird, I just read the docs and none of the comments seem to relatr. The guidelines from an app with hierarchy is to have back and up buttons one all pages but home, up is on top left, back is in nav bar, bottom left, and this even when they point to the same target. Back is about click history, up is about information architecture. It makes sense.
Since no one else has mentioned it, ICS has improved how you navigate among apps.
The three omnipresent buttons are now back, home, and recent apps. Recent apps pulls up a visual stack of everything you've used recently, so the ICS expectation would be that users would hit that key if they want to navigate among apps.
I agree. Please get rid of the way the back button currently works, Google. It should only go back within the app, and that's it. Just like your browser back button on your PC, doesn't affect any other app in the system.
And while you're at it, pretty consider getting rid of all the buttons altogether, and just use screen gestures, kind of like in N9's Meego. I keep getting this feeling that being there all the time, they are just wasting precious space.
As an Android developer for many years I was excited when I read the blog post about the site. When I went to the site, I was very disappointed. I've spent the better part of 10 minutes on the site so far and haven't seen anything other than marketing text and screenshots of what my phone looks like.
How do I make these "beautiful designs" work across all Android phones? How do I use an Actionbar on a non 3.0+ device without external libraries? How can I supply a consistent look and behavior for my application when some android OEM keyboards don't even offer the same modules as other ones?
How am I supposed to follow these guidelines when every Google application has a different implementation of the Actionbar itself?
The link at the bottom to the core developer site shows you how to implement most, if not all, of what they discuss here. Though it would be nice if they had links interspersed throughout the design text to their tutorials and API guides about the UI features.
Agreed. Very frustrating for "building blocks" to show things like "scrollable tabs" that I'd quite like to use, where in fact no such standard implementation seems to exist! It's all well and good to display UI best practices, but give us the actual widgets you're talking about, otherwise the whole thing is pointless.
The website felt odd to me. It's clearly aimed at developers, given the subject material, but it felt like it was written as an ad for prospective buyers.
It listed a bunch of features and user interface methods that apps should have, but I couldn't find any resource for actually implementing what they suggested, apart from the link to the android developer page at the end.
I completely agree. The wording is so basic and kind of insulting as seen here for instance, "Text fields allow the user to type text into your app. They can be either single line or multi-line." Very elementary for either a developer or a designer to read.
I think it might be too early to pass judgement. I would hope that over time Google releases sample applications, better widgets, and so on to take care of the boilerplate. (Similar to HTML "grab and go" type sites.)
I love that they included the ICS home screen's "glass desktop" effect in the "Delight me in surprising ways" section (http://developer.android.com/design/static/content/principle...). It's a completely unimportant feature, but the first time I swiped past the edge of my rightmost homescreen and saw the effect, I appreciated the attention to detail.
Where I disagree is with their "Pictures are faster than words" suggestion. I completely agree that many things are best said with images, but I've had a hard time identifying the function of several features in the icon-driven UI's featured in both ICS and in new Google web redesign. In ICS's Gmail app, I'd understand the words "Mark Unread" much quicker than the "sealed envelope" icon which I had to experimentally discover.
It's also interesting to note that in ICS Gmail, Mark Unread is an icon and Report Spam is text, where in web Gmail, Mark Unread is text and Report Spam is a stop sign.
I kind of agree with the sentiment that a few others are having. I've spent the past 4 months working on an Android project and when I opened this page I was in shock.
Everything looks so awesome and shiny - but where is the actual implementation? Is this stuff just a ICS theme (I haven't used it myself as our app is in 2.2 land)?
Others pointed out to check the "Developer" link - but that is just the standard Android docs I've been digging through for months already. Searching for things like "Index Scrolling" (which would be awesome to add to an app) or "Switches" doesn't return anything useful - so what are the Building Blocks and how do I get them into my app?
This page should either a) include demos (or links to the demos if they exist already) or b) be embedded in the code docs (android.widget.GridView should show the screenshot and UI guidelines).
I think this is the most consistent UI for Android so far. It still feels a bit more like a "style guide" rather than "human interface guidelines", but it's a great step forward.
Am I missing something? I'd like to get my hands on the templates, mocks, wirefames, etc. Let me play with those (as a designer) and I'll be able to better follow the specs and guidelines.
Note: Microsoft (for once) actually one-up Big G. here. They provide the PSD and fonts for Windows Phone 7 on MSDN + the UX Guidelines.
Also, for Apple, 3rd party made all the PSD and templates for them...
Simply put, and coming from an Apple fan-boy, this is REALLY nicely done. I honestly think this will significantly improve the usability of the platform as a whole by attracting the right designer/developer talent.
Interesting how they make sure to say that you shouldn't use bottom tabs like in iOS. For my project I decided to do exactly that instead of using an Android standard action bar, because:
1:The bottom bar fits 5 items. An action bar needs to have the app name as well, which means it can't have 5 items anymore. Having a "More" option is just dumb.
2:The iOS bottom bar has text underneath its icons and the action bar doesn't. I'm afraid the icons I have aren't obvious enough without text.
3:This is a conversion from iOS so the images are already made
4:Getting an Android action bar to work on older versions is very difficult. The Android compatibility library doesn't help here, and the third party libraries I looked at were not mature enough. I'm doing this work as part of a fixed price contract so I can't waste days getting it to work reliably.
Bottom line: Android apps would look a lot better if doing things the right way was also the easiest way.
This is great! If apps start following this it should significantly improve the Android user experience, as well as making it much easier to design good Android apps.
I tried browsing this on my old Android phone... I couldn't get past the first page. I hope "people should be able to read your content" is one of the guidelines...
[+] [-] Pewpewarrows|14 years ago|reply
"For the Back key, you should make navigation more predictably [sic] by inserting into the task's back stack the complete upward navigation path to the app's topmost screen."
No. This piece of advice is the sole reason why the back button is confusing to users. Injecting activities artificially onto a user's Back Stack based on some arbitrary and imaginary path that they might have taken to get there is horrible. If I'm in the middle of reading a book and get an email notification, and I touch that notification to quickly read the email, that Back button better damn well take me BACK to what I was doing. Don't take me UP to the list of emails in my inbox. This is where the average user will become lost and not understand why they aren't taken back to reading their book, and will just end up touching Home out of frustration.
Bad Google!
[1] http://developer.android.com/design/patterns/navigation.html
[+] [-] rryan|14 years ago|reply
Here's an example -- from the homescreen, click a Music widget. The Music app opens and shows the song I was listening to. I want to go back to the playlist I was playing from so I hit back. Instead, I'm dumped back to my home screen. you have to hit the Google Music icon in the top-left to go back within the Music app. I don't mind having to hit back a couple of times because I've learned that you can just keep hitting back and you'll eventually get where you were.
[+] [-] greggman|14 years ago|reply
The way you suggest is why Android's back is confusing. If I hand you my phone and put you on a particular screen and ask you "if you press back right now where will you end up" you have no idea
Even if it's your own phone if it's been a few minutes, hours since you last used an app you'll have no idea.
Here’s what I hope is an objective fact about the Android back button. IT’S NOT PREDICTABLE!
The way it works is that each app has a “stack” of screens. Pressing the back button pops the current screen off that stack revealing the screen below. If there are none you are taken to the home screen. The problem is let’s say you start the Messaging app. The first screen is “list” of conversations screen. You pick a conversation and now you are on the “conversation” screen. From the conversation screen you press “back” and you get the “list” screen. Press back again you get the “home” screen.
Now let’s take another senario. You are in the browser. You get a notification that you have a new message. You select the notification for the message. You are taken to the “conversation” screen. You press home and do something else, say listen to music. Later you decide you want to send a message to someone. You go the home screen and pick the messaging app. Since the app is still running you see the “conversation” screen. You press back you get the “home” screen. WTF!
In the first case it went “conversation”->”list” in the second case it went “conversation”->”home”
Notice in this case, even if you had an amazing memory and could remember that you happened to launch the messaging app from a notification an hour ago or last night or something you still have no direct way to get to the “list” screen. The only way there is to select the messaging app either from the home screen or the recently used list. You’ll get the “conversation” screen. You press “back” and you’ll exit the messaging app back to the “home” screen. Now you have to navigate the home screen to the screen that has the messaging app icon on it so you can re-launch the messaging app and have it start in on the “list” screen.
Android should never have had a back button in the first place. If there was no back button there'd be no way to make it inconsistent. Switching back to another app would be come the simple habit of holding home for a moment and picking the app you want to go back to and you'd always be able to predict where any button will take you.
I applaud them for trying to fix it but putting in the guidelines, which may or may not be read by the majority of devs, seems unlikely to fix the problem.
[+] [-] natrius|14 years ago|reply
[+] [-] dminor|14 years ago|reply
[+] [-] gjulianm|14 years ago|reply
For me, the best solution would be make the back button come back to the previous screen, ignoring where they are. So, if you are playing Angry Birds, tap an email notification and then press back, you return to Angry Birds. But, also, in screens in which the user may want to go to the parent element, developers should put a button to go "home". In the email screen, a button to go back to inbox, in the Music app a button to go to the Music app initial screen...
[+] [-] schrototo|14 years ago|reply
Both back button behaviors are perfectly valid and convincing arguments can be made for each, so the choice is pretty much arbitrary. But if Google doesn't enforce any particular behavior and leaves it up to the developers, the only possible result is confusion.
Additionally one could make the argument that the whole back button concept itself is inherently confusing, precisely because the right choice of behavior isn't obvious.
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] kefs|14 years ago|reply
http://i.imgur.com/ym4W4.png
[+] [-] drcube|14 years ago|reply
Otherwise, my workflow basically goes: press home button, use the task manager to kill everything, then visit an app and navigate top-down to where I want to go. Rinse and repeat for the next app. Like others have been saying, the back button is inherently either arbitrary or confusing, and I don't know how to fix it.
It should be replaced as a permanent UI feature with a task switcher button. I don't know how a modern operating system can get by without some sort of taskbar equivalent. I need to know what apps are open, and be able to navigate to them and close them as needed. Why has this not been implemented? I'd suggest putting this into the slide down top bar if there weren't full screen apps that totally break this function. Therefore, I suggest replacing the back button with a task switcher. I won't be holding my breath.
[+] [-] jra101|14 years ago|reply
[+] [-] babebridou|14 years ago|reply
It has unfortunately little to do with UX, since both end up being confusing on edge cases (Astro's horribly enraging "press back twice to 'exit'", the conversation or gmail app issues people mentioned in this thread).
I personally tend to prefer back as in back in time but I know for sure opinions vary.
[+] [-] bookwormAT|14 years ago|reply
This is what I was told at the Android developer labs in Paris last November, in a Session about Ice Cream Sandwich Design:
http://developer.android.com/guide/topics/ui/actionbar.html#...
[+] [-] estel|14 years ago|reply
[+] [-] gbog|14 years ago|reply
[+] [-] starwed|14 years ago|reply
The three omnipresent buttons are now back, home, and recent apps. Recent apps pulls up a visual stack of everything you've used recently, so the ICS expectation would be that users would hit that key if they want to navigate among apps.
[+] [-] nextparadigms|14 years ago|reply
And while you're at it, pretty consider getting rid of all the buttons altogether, and just use screen gestures, kind of like in N9's Meego. I keep getting this feeling that being there all the time, they are just wasting precious space.
[+] [-] noveltyaccount|14 years ago|reply
[+] [-] jc4p|14 years ago|reply
How do I make these "beautiful designs" work across all Android phones? How do I use an Actionbar on a non 3.0+ device without external libraries? How can I supply a consistent look and behavior for my application when some android OEM keyboards don't even offer the same modules as other ones?
How am I supposed to follow these guidelines when every Google application has a different implementation of the Actionbar itself?
[+] [-] Pewpewarrows|14 years ago|reply
http://developer.android.com/index.html
[+] [-] notatoad|14 years ago|reply
[+] [-] joshsharp|14 years ago|reply
[+] [-] drivebyacct2|14 years ago|reply
[+] [-] adpowers|14 years ago|reply
http://developer.android.com/design/static/content/ui_overvi...
http://hipsteripsum.me/
[+] [-] kevinh|14 years ago|reply
It listed a bunch of features and user interface methods that apps should have, but I couldn't find any resource for actually implementing what they suggested, apart from the link to the android developer page at the end.
[+] [-] wattjustin|14 years ago|reply
[+] [-] alexchamberlain|14 years ago|reply
[+] [-] aChrisSmith|14 years ago|reply
[+] [-] evanw|14 years ago|reply
I love that they included the ICS home screen's "glass desktop" effect in the "Delight me in surprising ways" section (http://developer.android.com/design/static/content/principle...). It's a completely unimportant feature, but the first time I swiped past the edge of my rightmost homescreen and saw the effect, I appreciated the attention to detail.
Where I disagree is with their "Pictures are faster than words" suggestion. I completely agree that many things are best said with images, but I've had a hard time identifying the function of several features in the icon-driven UI's featured in both ICS and in new Google web redesign. In ICS's Gmail app, I'd understand the words "Mark Unread" much quicker than the "sealed envelope" icon which I had to experimentally discover.
It's also interesting to note that in ICS Gmail, Mark Unread is an icon and Report Spam is text, where in web Gmail, Mark Unread is text and Report Spam is a stop sign.
[+] [-] swanson|14 years ago|reply
Everything looks so awesome and shiny - but where is the actual implementation? Is this stuff just a ICS theme (I haven't used it myself as our app is in 2.2 land)?
Others pointed out to check the "Developer" link - but that is just the standard Android docs I've been digging through for months already. Searching for things like "Index Scrolling" (which would be awesome to add to an app) or "Switches" doesn't return anything useful - so what are the Building Blocks and how do I get them into my app?
This page should either a) include demos (or links to the demos if they exist already) or b) be embedded in the code docs (android.widget.GridView should show the screenshot and UI guidelines).
[+] [-] myko|14 years ago|reply
It would be amazingly helpful if they would link from the 'Android Design' page to the docs exactly what they are talking about.
[+] [-] wmf|14 years ago|reply
[+] [-] amirkhella|14 years ago|reply
Kudos
[+] [-] georgechen|14 years ago|reply
Note: Microsoft (for once) actually one-up Big G. here. They provide the PSD and fonts for Windows Phone 7 on MSDN + the UX Guidelines.
Also, for Apple, 3rd party made all the PSD and templates for them...
[+] [-] vlokshin|14 years ago|reply
[+] [-] aw3c2|14 years ago|reply
[+] [-] alexchamberlain|14 years ago|reply
[+] [-] kizza|14 years ago|reply
1:The bottom bar fits 5 items. An action bar needs to have the app name as well, which means it can't have 5 items anymore. Having a "More" option is just dumb.
2:The iOS bottom bar has text underneath its icons and the action bar doesn't. I'm afraid the icons I have aren't obvious enough without text.
3:This is a conversion from iOS so the images are already made
4:Getting an Android action bar to work on older versions is very difficult. The Android compatibility library doesn't help here, and the third party libraries I looked at were not mature enough. I'm doing this work as part of a fixed price contract so I can't waste days getting it to work reliably.
Bottom line: Android apps would look a lot better if doing things the right way was also the easiest way.
[+] [-] krosaen|14 years ago|reply
http://developer.android.com/design/patterns/multi-pane-layo...
Good advice for rich web apps too.
[+] [-] nodata|14 years ago|reply
Does a button marked "on" indicate it is already on, or that pushing the button will make it "on"? I'd like to see that standardised.
[+] [-] emehrkay|14 years ago|reply
http://developer.android.com/design/building-blocks/pickers....
[+] [-] njs12345|14 years ago|reply
[+] [-] problemspace|14 years ago|reply
[+] [-] fdb|14 years ago|reply
Any ideas how they made this schematic?
[+] [-] JacobIrwin|14 years ago|reply