Live data from Hacker News

Android Design

developer.android.com

121–130 of 143 posts

Re: Android Design

#121
post #81
post #59

Earlier quoted context omitted.

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

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.

Re: Android Design

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

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/

Re: Android Design

#123

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…

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.

Re: Android Design

#124

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…

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.

Re: Android Design

#125

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…

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

Re: Android Design

#126

Earlier quoted context omitted.

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

Re: Android Design

#127

Earlier quoted context omitted.

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…

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.

Re: Android Design

#128
post #75
post #62

Earlier quoted context omitted.

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

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

Re: Android Design

#129
post #55

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

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.

Re: Android Design

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

Post reply on HN