Live data from Hacker News

Android Design

developer.android.com

61–70 of 143 posts

Re: Android Design

#61
post #18

Earlier quoted context omitted.

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

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.

Re: Android Design

#62
post #19

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.

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.

Re: Android Design

#63

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!

Re: Android Design

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

Re: Android Design

#65
post #54
post #48

Earlier quoted context omitted.

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

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…

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.

Re: Android Design

#66
post #57
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.

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

Re: Android Design

#67
post #26

Earlier quoted context omitted.

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…

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

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.

Re: Android Design

#68
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…

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.

Re: Android Design

#69
post #41

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

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.

Re: Android Design

#70
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.
Post reply on HN