Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Android Design

developer.android.com

Post reply on HN
Print view View original

111–120 of 143 posts

Re: Android Design

#111

Post by babebridou »

Pewpewarrows wrote: post #9

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…

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.

Re: Android Design

#112

Post by AliCollins »

helpbygrace wrote: post #93

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

Re: Android Design

#114

Post by bookwormAT »

Pewpewarrows wrote: post #9

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…

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

Re: Android Design

#115

Post by saket123 »

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.

Re: Android Design

#116

Post by fbailey »

kefs wrote: post #50
Pewpewarrows wrote: post #9

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…

... or users can just be given the option and decide for themselves. http://i.imgur.com/ym4W4.png

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.

Re: Android Design

#117

Post by schrototo »

Pewpewarrows wrote: post #9

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…

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.

Re: Android Design

#118

Post by nielsandersen »

amirkhella wrote: post #43
georgechen wrote: post #25

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

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.

Re: Android Design

#119

Post by [deleted] »

nl wrote: post #59
kefs wrote: post #50

Earlier quoted context omitted.

... or users can just be given the option and decide for themselves. http://i.imgur.com/ym4W4.png

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

[deleted]
Post reply on HN