Android Design | Hacker News Reader

Android Design

developer.android.com

437 pointsrtsuk137 comments

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.

Bad Google!

[1] http://developer.android.com/design/patterns/navigation.html

I'm not sure where I stand on this; and it's possible the context should determine the behaviour. But equally, perhaps Google just want consistency?

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.

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.

In the email app (not the gmail app, the email app) I frequently have to press back 20 or more times, bouncing between earlier emails I read, before I get back to the app that I was on before the email notification popped up.

Whatever way you look at it, that's pathological behaviour.

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'd think that the "typical" behavior would be to go back to what you were doing. I'm playing "Angry Birds", notification shows for text message. I click it, read the notification, hit back to get back to Angry Birds.

I don't see how inserting items between the text message and Angry Birds is a good idea.

What apps should have, is a way to always get to the apps main screen in the app. But changing the back button behavior seems confusing.

What if you change to the message app via the task manager?

In the message app context "back" takes you to a list of messages, which makes a lot of sense.

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.

I've only used an Android phone once for 5 min (my Mom got one for Christmas), but that was enough to run into Back button confusion.

My assumption was that it would take me up the stack, since when I entered the Mail program and navigated down, Back took me back up. But when I entered from some other place (like the settings app) then back wouldn't take me up to inboxes.

I'm sure it would have made more sense if I realized it was a system-wide Back and not an app-only Back.

There has to be some kind of middle ground here, some kind of way to do it that gives you quick access for transitory things, like email and text messages, but also lets you get back up the stack. Maybe if artificialy adding things to the stack was disabled when you're coming from notifications, but not otherwise?

You would be able to tell if the user had previously used the app, gotten to a state, switched out, then went back to the app to find that state or if the application was pushed to a certain state when it was opened.

Personally though, I would prefer the back button system-wide only. You can easily provide a UI element to take you to the top of the stack (especially since when an app is forced into a state, you only want to get to the top of the stack). Sometimes I even get confused when the back button takes me back a webpage in the browser.

Seems reasonable to me to use the (generally) hardware back button as a 'system' back button and the ActionBar back button as the in-app back button.

Why? The "multitasking button" should be enough for that. Press it, and you can switch to your app.

I disagree. I think the confusion is caused by users not intuitively understanding the context of the android "back". In a web browser, if you click a link to a sub-page on a different domain, you don't expect the back button to take you to the home page of that domain, you expect to go to the previous site you were browsing. Do any android devices have something akin to the right click on the back button in web browsers, that shows the back stack?

This consistently confuses me too (and I much prefer it when application insert artificial pages).

I've thought about it some, and I think the problem is that the back button lacks the concept of context.

In the music app example, when I first use it I get the front screen, then choose a song.

Then I press the home button, put my phone away and at some point the song stops.

Now, some hours later I open up the music player from the home screen and it is still showing the song, what behaviour should the back button have?

I think it should take me back to the song list (because I am now in the "Music" context in my head - and this is what it now does). But one could argue that the back button should take me back to the home screen.

The biggest problem for me is the uncertainty and inconsistency. Do you always remember the previous screen you were on in any app hours ago? What if you got to the song from some other screen? I would constantly have to "guess", what is this app going to do, take me back to where I previously was or to a higher level in the app. It needs to be consistant, back is back and navigating within the app needs to be obvious and on the UI itself.

The back button in browsers is often used as analogy, but how many tabs/windows do you have open in your browser? What if pressing the back button in the browser switched you to a word processor because that is what you were looking at before.

That's what alt+tab and ctrl+tab are for. The confusion comes from the use of only one back button instead of one per hierarchy.

On android we have only one system-wide consistent timeline to work with, and that's the timeline of fired intents. It works across the whole system. Back works on that level by default and is defined by default as "go back in time".

> I disagree. I think the confusion is caused by users not intuitively understanding the context of the android "back"

That's exactly the problem. The user should intuitively understand an action. Since they don't, that means it's Google's fault for implementing it poorly.

The problem is that the "Back" button has replaced onscreen upward navigation in Android apps. This means that the back button cannot function strictly as a means of returning to your previous activity if upward navigation is going to be possible. The options are for apps to build upward navigation into their UI (how its done on the web) or for apps to push their entire navigation tree onto the stack, regardless of how you get to a given location. Google seems to be opting for the latter option.

But they're not... The Google Music, Reader, Market and others that I can't think of use the top left icon and a left handed arrow to take you back in the apps activity and that works regardless of the actual Activity stack (And the back button works as a stack navigator).

This inconsistency and change in Google apps' behaviors is frustrating and is the only thing that I think they failed at in their attempts to fix the "consistency" problems of Android UI/UX.

I'm with the grandparent, I'd like to see this clarified. Some picture-based examples might help explain this issue better to those unfamiliar with Activity management.

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...

... or users can just be given the option and decide for themselves.

http://i.imgur.com/ym4W4.png

I'd be wary of configuration settings like this, they sidestep the problem and create another one--you still have potentially confusing navigation and now there's more clutter in configuration screen. In this case, the configuration setting is badly named too, 'Manage "Back" button' makes sense to the developer, less so to the user.

There are useful settings that help me accomplish the task, and then there are not so useful settings where developer simply couldn't decide. I particulary dislike configuration UIs that devote whole section of toggles and switches for configuring the configuration screen itself.

So, giving the user more control is a bad thing?

While I understand that users can be easily overwhelmed with a plethora of options, this one makes sense.. especially for an email app.

Looks more like working around deficiency in navigation, than giving more control.

Rethink your UX, put together prototypes, user-test, and repeat. Leave configuration option as last resort. That's the approach for app that wants to "Simplify my life" and "Make me amazing".

There are hundreds of design decisions that go into any product. Designers can't give each and every one a configuration setting, and can't know before launch which decisions will be the wrong ones.

If the back button did it's job properly then the feature would just work; you wouldn't need to manually configure it to match your mental model.

No, no.

Config settings like that are a way for lazy designers to avoid making hard decisions.

Joel Spolsky wrote about this over 10 years ago:

Every time you provide an option, you're asking the user to make a decision. That means they will have to think about something and decide about it. It's not necessarily a bad thing, but, in general, you should always try to minimize the number of decisions that people have to make.

and

"But wait!" you say. "It's important to have options for advanced users who want to tweak their environments!" In reality, it's not as important as you think. This reminds me of when I tried to switch to a Dvorak keyboard. The trouble was, I don't use one computer. I use all kinds of computers. I use other people's computers. I use three computers fairly regularly at home and three at work. I use computers in the test lab at work. The trouble with customizing your environment is that it just doesn't propagate, so it's not even worth the trouble.

http://www.joelonsoftware.com/uibook/chapters/fog0000000059....

Does that second part really apply to mobile development though? Most people only use one phone, or maybe two, for anything more involved than making a call.

They also use a tablet or two, maybe an ebook reader, maybe a TV running the same OS, etc etc.

i love those reasoning of 'real' designers to enforce what THEY think is best.

like the 'designers' of gnome3 (using the term loosely here) who thinks focus-follow-mouse and click-does-not-raise-window are things that only the devil would use and so no one should be allowed 'for usability sake' and 'think of the children'

think about it. a black wallpaper is the best readability option. period. so let's remove the user ability to change wallpapers pronto!

what i say "everytime you provide the user an option, you are asking him to, if he uses the software enough, to take a little second to make a decision that will give him an incredible productivity edge"

now, stop being lazy and hiding behind excuses. work on the real problem: how to present the options so they are not in the way, like joel mentions it while not being missed by the user

Did you read the link? He specifically addresses a subset of your issues:

This doesn't mean eliminate all choice. There are enough choices that users will have to make anyway: the way their document will look, the way their web site will behave, or anything else that is integral to the work that the user is doing. In these areas, go crazy: it's great to give people choices: by all means, the more the merrier. And there's another category of choice that people like: the ability to change the visual look of things, without really changing the behavior. Everybody loves WinAmp skins; everybody sets their desktop background to a picture. Since the choice affects the visual look without affecting the way anything functions, and since users are completely free to ignore the choice and get their work done anyway, this is a good use of options.

(Note this part: everybody sets their desktop background to a picture)

Yes, and i was pointing out how bad it is.

So you can only go crazy on futile options and not useful ones? Give me a break.

I think the best of both worlds is to have whatever your giant designer brain thinks is best be the default, and include options to change whatever you want. So if you don't care, you get a good preset, and don't have to make any decisions, and if you do care you aren't restricted.

Now that's only an option, if users understand what will happen and why they should change this setting. "Manage Back Button" is not an understandable option. So instead of solving the problem you just defered to the user. That's not design, that's just lazy.

WRONG! :-)

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.

Totally agree with you. WP7 behaves the way you describe.

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.

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.

What confuses me about this guideline is it suggests the back button behaves the same way as the new up button introduced in Honeycomb?

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#...

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.

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.

How do phones with hardware buttons access the recent apps list? Same as in 2.3 (long-press home)?

I only have a galaxy nexus, so no idea! :) Repurposing the search key would probably make the most sense to me, but I can see that would be confusing.

Has ICS rolled out to any older phones yet?

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.

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.

http://developer.android.com/index.html

That's definitely true, I don't know why they didn't put a "click here for more technical info!" next to each point.

The things that really bother me are:

1. If I implement one of the new themes they're discussing on the linked page, it only works in 3.9% of Android phones on the market, so if I want my apps to look like Google's on older phones I'm left to implement my own version of the themes. This is the same thing that happened when they announced "Homepages with square buttons for activities are the new way you should do everything!" and didn't release source code for how to do it for years afterwards with the Google I/O app, so every app that tried it did it a different way.

2. How am I supposed to use the action bar if Google's own applications can't decide on how to use it? Look at the "What's up with the bar" section of this blogpost: http://minming.posterous.com/google-currents-yet-another-con...

As for 1st point, check out section "Pure Android". It says you shouldn't copy UI style from other platforms. I think this could be extended to major versions of single platform too. App with Holo theme on Froyo phone would look very out of the place, I think.

The announcement for and docs of the Action Bar specifically point to libraries that can be imported pre-3.0 to provide the Action Bar.

You mean the ActionBarCompat example which is so minimal that only the simplest apps can use it? It's lacking almost every feature of the action bar.

No, that's not what I meant.

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.

Are you talking about a ViewPager?

http://android-developers.blogspot.com/2011/08/horizontal-vi...

The ViewPager doesn't include any sort of tab bar. You have to integrate them with tabs yourself or use a 3rd party library like ViewPagerIndicator.

Guidelines are not tutorials. This might not be what you wanted, but this is what a design guidelines document looks like.

Ha! I love that they are using Hipster Ipsum:

http://developer.android.com/design/static/content/ui_overvi...

http://hipsteripsum.me/

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.

Isn't it for Designers, rather than Developers?

Designers, managers, or any other project stakeholders. Many of whom may have the same understanding as customers.

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.

If the goal is to bring devs in from other platforms, who might have all kinds of crazy notions about what Android dev entails, erring on the side of over-simplification will give more people the sense that "hey yeah, not so hard."

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.)

Regarding the Design Principles page: http://developer.android.com/design/get-started/principles.h...

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'm not saying it's right or good usability, but the new "picture based buttons" can be long-pressed for a textual toast-style popup that tells you what they do.

Google is heavy on logic but weak on intuition. Why their designs seem to look good but are hard to follow.

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 by Index Scrolling it means to use the SectionIndexer interface: http://developer.android.com/reference/android/widget/Sectio...

It would be amazingly helpful if they would link from the 'Android Design' page to the docs exactly what they are talking about.

Do they have a schedule for when Google's apps will follow these guidelines?

This really appears to be for Android 4.0+. Google's core apps follow these guidelines but Android 2.3 down seems to be left behind.

I'm not sure as an Android developer I'm ready to leave those users behind just yet which means a lot of extra work maintaining 2 different sets of UI code. The action bar is the killer.

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.

Kudos

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...

There's some third party work done for Android as well: http://designmodo.com/android-kits-developers/

Thanks. Nice. But since Big. G. is heavily pushing ICS, they should really put the ICS files up there.

I've recently updated Keynotopia templates to include Android ICS UI components for Keynote and PowerPoint (http://keynotopia.com/android-prototyping-templates/)

Great resources on your site. Should you ever feel inclined to port your stuff to Axure you have at least one paying customer right here.

One of the nice features of the Android hierarchy viewer (provided with the Android SDK) is that it lets you dump your app's visual structure as a PSD with layers - very useful for working with a designer. Ask your developer!

I will! Thanks! I assume that's new in ICS?

Actually, it's been around for a while. The tool is kinda unpolished, but quite useful..

I agree. I don't understand why they aren't linking to those resources as well, or maybe I missed 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.

I know it is silly and offtopic but that gorgeous website's navigation does not work without Javascript for no good reason.

I like the density-independent pixel concept...

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.

you can break out tabs into a separate action bar or use scrollable tabs. You're using elements from another platform your users don't use. You're just going to confuse or annoy them.

For sure, but like I said, I don't have days to spend making half-baked action bar code work.

I like this bit on using multipane layouts to be flexible on both tablets and mobile:

http://developer.android.com/design/patterns/multi-pane-layo...

Good advice for rich web apps too.

I wish they'd make this searchable. This is from Google after all.

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.

I like the date picker

http://developer.android.com/design/building-blocks/pickers....

Fun fact: the up and down arrows work exactly opposite how you expect them to.

Hilarious because i've been flip flopping on how they worked. The arrows seem to be a paradigm from mouse-based computing, can you scroll these lists like on ios?

If you scroll them they actually remove the arrows and make a lot more sense.

Before you drag: http://i.imgur.com/4MUXO.png

After you press to drag: http://i.imgur.com/BqXMY.png

To be fair, it's a huge improvement over: http://i.imgur.com/2exF7.png

As a day 1 Droid user after 10 years on Palm OS, I was stunned that the control in your third picture made it into a release, and even more stunned it persisted so long. On Palm OS you could pick a time with a maximum of three taps. There's no reason it should take more than five: one for each digit plus AM/PM.

I'm not a fan of the swiping, but you're right. It is a huge improvement.

At my job the application we're currently working on is aimed for Android 2.1 and above so we can't the new TimePickerDialog.

I actually had testers come up to me and report bugs about the Android TimePickerDialog as bugs in our application saying that it didn't work as expected and it was against the UI specifications (which of course only have pictures for the iPhone version of the application).

I had to actually replace them with two dropdown sliders and a button so that the testers would be happy.

you know you can just press the number and use the keyboard, right?

Well, after pressing backspace twice to erase the already entered numbers... It's just amazingly bad :-)

To me the huge irritation with time picking in a lot of Android apps is that they usually force me to specify a fully populated "minutes" field. IIRC, in iOS most apps instead round to ~5 minute intervals. 99% of the time, that is what I want. If you round to 5 minute intervals, there are only 12 possible minute values, not 60. This makes it a lot less work to find what you want and get that calendar appointment scheduled or that alarm clock set up.

I'll sound like wierdo, but I always set uneven minutes to alarms, so there's less chance they overlap each others' snooze alerts. (yep, I have a problem with getting up and have to set up 3 alarms next to each other)

Now that I think about it this must be why iOS uses 9 minutes for the snooze interval, to avoid similar overlap (always wondered).

that's clever. now tbh I don't even know how long is snooze on my phone, I just assumed it must be even.

Looks a lot less intuitive than the UIDatePicker in iOS, which is styled like a slot machine [1].

Does anyone know whether you can manipulate the controls by dragging, or do you really have to use those little up and down buttons?

[1] http://blog.blackwhale.at/wp-content/uploads/2011/05/UIDateP...

You can drag them.

See my other comment here: http://news.ycombinator.com/item?id=3458159

Swiping works just fine.

Swiping works, but due to its minimalistic design, I first expected it to count up when I swiped up - while it did the contrary. It behaves like the iOS slotmachine, but clearly the affordance is broken.

It is quite annoying, if you say want to move a meeting to next Tuesday you have to work out the date, as you get no day of week indicator. And changing date and also time involves two pickers. Every time I use it I wonder if it could be improved...

I despise it. One of my Gmail labels is set to sync content for 365 days. I nearly got RSI spinning that damn thing with my thumb until it hit 365.

Um, you can just tap the number and it will bring up a 10-key keypad. You can just type "365".

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...

I find the "app structure" schematic (http://developer.android.com/design/patterns/app-structure.h...) a very useful visualization to see the screens of an app in one glance.

Any ideas how they made this schematic?

For Android/Google on web, it's possibly the most apple.com-like designed page I've seen yet.

Why did choose to put 2 phones on the homepage? Because one phone has 3, the other 4 buttons? Isn't that still a bit redundant. (If it where not for a design-centric page it wouldn't have troubled me)

because part of that site talks about compatibility with different devices.

the phone on the left is a nexus s, which has the (now) older style of dedicated hardware buttons. the nexus prime on the right is apparently what newer devices are supposed to have, which are software buttons that are actually just part of the main lcd and the operating system reserves a section of the screen to draw them in software.

the big benefits of the newer style are that they can be hidden while playing movies or in other situations where they are not needed, they can be rotated when the device is rotated, and, maybe most importantly, the operating system now gets to control which buttons are there and in what order they're in. an annoying thing about the hundreds of different android phones prior to this was that every manufacturer seemed to put the 3 or 4 hardware buttons in a random order that made them inconsistent.

Utterly worthless. This looks like a web designer on crack had too much time to promote the beauty of the new Android.

However, from a developer's point of view this is almost unusable. By not providing the according XML/Java code, we are forced to reimplement everything from scratch, making smaller and larger errors, introducing inconsistency and making the look and feel not quite the same between apps.

Then again, it fits well with the current way Google is doing UX design (http://minming.posterous.com/google-currents-yet-another-con...).

Some of the pieces DO work (48dp as hit-target is a good advice, and colour palette etc. is pretty usable). I think it's a good start for all the Android devs (non-designers) who put apps together which are 99% crappy looking. I am quite frustrated however that they do not tell us how to get the same behaviour on older devices - they should release a look-and-feel compatibility library or something. Actionbar is also very inflexible (tabs with buttons in one row, anyone? adjustable tab width?) and making the same code work for 2.x - 4.x devices is just plain spaghetti.

I found the site by way of an @AndroidDev tweet [1], and I was incredibly frustrated. Their old documentation [2] was completely useless, and this is even worse. Am I supposed to purchase and learn proprietary design tools to develop an effective Android app? This turns me off to the platform as a whole.

[1]: https://twitter.com/#!/AndroidDev/status/157570583800971264

[2]: http://developer.android.com/guide/practices/ui_guidelines/i...

All of the UI elements are available in source provided by Google. Koush (on Twitter) tweeted with Tim Bray about them being split out into a more-easily-consumed library.

Yes, they are hiding somewhere in the multi-gigabyte Android source code. At least the basic default elements. And their style formatting.

And then there are the closed-source Google apps which at least slightly resemble the UX guidelines given on that site.

And then there are the more complicated UI elements which provoked the creation of fork projects to allow for the reusability and compatibility not provided by the Google devs, like http://actionbarsherlock.com/ and http://viewpagerindicator.com/

I'm going to assume the internet has already somehow collectively dealt with the fact that the Android name for a drop-down list control is a "Spinner."

it doesn't always drop down. Sometimes it "drops" up, like if the element is at the bottom of the phone. You can "spin" through options. Makes sense.

Finally!. Isn't too late? Are OEM and carriers going to follow the same principles? Or they can build whatever skin/mess they want as they did so far?

Google, good work on the Android design guidelines, but is that enough to tame the wild west in the marketplace and the current "anarchy"?

Does anyone know how to see Roboto font as anti-aliased in Windows7? In my windows 7, Roboto font looks really jagged and weird.

Likewise on my XP Laptop in Chrome...and I have Roboto TrueType font installed. Then un-installed the font, and it looks far better!!

All we need now is an accessibility document for Android.

Accessibility is notably absent from the design doc.

"Android Design"

    .../index.html

It's the little things that matter. This is shameful for a company so big.

I'm confused, why does this matter?

From a technical perspective, littering your URLs with implementation debris is not a good idea. What if you want to revamp the site, put it in a shiny CMS, and now it's in PHP or JSP or does it even matter? You have all these references to `index.html` you have to maintain or you'll be wrecking your linkage.

Bury those. If you're doing a plain HTML site, use MultiViews to hide the extensions. They're not important to the content.

When I see `index.html` in a URL, it's never a good sign. It's done by a sloppy "web designer" that knows how to use DreamWeaver and FTP things to the server. They make a tremendous mess for the next team that has to come along and somehow upgrade the site without breaking everything.

It's not 1998 any more. You can afford to script your pages, have clean URLs, and still get great performance.

This site is really useless. As an android developer I was hoping for more steps rather then another marketing docs. Its funny how little android provides out of the box and I have to just keep searching source to find how things are implemented and best way to implementing such designs. Sad state of affairs as I have to waste most of my time trying to understand these designs and corresponding code designs in source.

Another thing I hated about the website is how sparse it is in technical details. If Google really hopes us to make use to these pattern why not release some of these as widgets or templates.

Isn't ICS like just around 0.5%(or was it 5%) of Android handsets as of December 2011? This design guide is ALL about ICS and nothing about the 99% of the Android handsets used by people.

in 2 years everyone will have ics or better. carrier contracts.

That's kinda sad, compared to Apple, Microsoft, and RIM. ICS fixes bugs too. People shouldn't have to deal with them until they buy a new phone.

I know some will criticize this is ticky-tacky, but it's one small thing that, when added with a lot of other little details, make Android feel like it's still designed by engineers.

They've "touched nearly every pixel" and "App icons are works of art in their own right" but the contact name on their contacts icon is "Lorem Ipsum". Not exactly a warm, human feel.

http://developer.android.com/design/static/content/design_el...

"Lorem Ipsum" is more of a designer thing.

Lorem Ipsum is supposed to show you the "experience" of the design, and leave out any emotional or cognitive associations you might have with specific text. It's used as a content-free placeholder in design. It really has nothing to do with "engineers".

Reply on news.ycombinator.com