Live data from Hacker News

Android Design

developer.android.com

31–40 of 143 posts

Re: Android Design

#31
post #23

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…

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.

Re: Android Design

#32

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/

Re: Android Design

#33
post #10

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,…

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.

Re: Android Design

#34

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.

Re: Android Design

#35

I like the date picker http://developer.android.com/design/building-blocks/pickers....

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

Swiping works just fine.

Re: Android Design

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

Re: Android Design

#37

I like the date picker http://developer.android.com/design/building-blocks/pickers....

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

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.

Re: Android Design

#38
post #22

Earlier quoted context omitted.

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.

Re: Android Design

#39
post #26

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…

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 wit…

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?

Re: Android Design

#40
post #26

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…

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 wit…

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?
Post reply on HN