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

81–90 of 143 posts

Re: Android Design

#81

Post by gcb »

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…

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

Re: Android Design

#83

Post by noveltyaccount »

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…

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

Re: Android Design

#84

Post by joshsharp »

jc4p wrote: post #7

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…

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.

Re: Android Design

#86

Post by mdwrigh2 »

joshsharp wrote: post #84
jc4p wrote: post #7

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…

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

Re: Android Design

#87

Post by georgechen »

njs12345 wrote: post #63
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...

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?

Re: Android Design

#88

Post by notatoad »

jc4p wrote: post #7

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…

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

Re: Android Design

#89

Post by notatoad »

alexchamberlain wrote: post #5
kevinh wrote: post #4

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.

Re: Android Design

#90

Post by underwater »

kefs wrote: post #57
cuu508 wrote: post #53

Earlier quoted context omitted.

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…

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.

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.

Post reply on HN