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

51–60 of 143 posts

Re: Android Design

#51

Post by barrkel »

dminor wrote: post #17
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…

I happen to like this functionality and don't think it's confusing at all. As long as pressing back eventually gets me back to where I was before it's just fine.

In the email app (not the gmail app, the email app) I frequently have to press back 20 or more times, bouncing between earlier emails I read, before I get back to the app that I was on before the email notification popped up.

Whatever way you look at it, that's pathological behaviour.

Re: Android Design

#52

Post by russell_h »

rryan wrote: post #26
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…

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 how you get to a given location. Google seems to be opting for the latter option.

Re: Android Design

#53

Post by cuu508 »

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

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 useful settings where developer simply couldn't decide. I particulary dislike configuration UIs that devote whole section of toggles and switches for configuring the configuration screen itself.

Re: Android Design

#54

Post by nl »

romey wrote: post #48
rryan wrote: 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…

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 player from the home screen and it is still showing the song, what behaviour should the back button have?

I think it should take me back to the song list (because I am now in the "Music" context in my head - and this is what it now does). But one could argue that the back button should take me back to the home screen.

Re: Android Design

#55

Post by swanson »

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 Android docs I've been digging through for months already. Searching for things like "Index Scrolling" (which would be awesome to add to an app) or "Switches" doesn't return anything useful - so what are the Building Blocks and how do I get them into my app?

This page should either a) include demos (or links to the demos if they exist already) or b) be embedded in the code docs (android.widget.GridView should show the screenshot and UI guidelines).

Re: Android Design

#56

Post by nl »

kenjackson wrote: post #31
natrius wrote: post #23

Earlier quoted context omitted.

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

What if you change to the message app via the task manager?

In the message app context "back" takes you to a list of messages, which makes a lot of sense.

Re: Android Design

#57

Post by kefs »

cuu508 wrote: post #53
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

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.

Re: Android Design

#58

Post by pax »

Why did choose to put 2 phones on the homepage? Because one phone has 3, the other 4 buttons? Isn't that still a bit redundant. (If it where not for a design-centric page it wouldn't have troubled me)

Re: Android Design

#59

Post by nl »

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

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

and

"But wait!" you say. "It's important to have options for advanced users who want to tweak their environments!" In reality, it's not as important as you think. This reminds me of when I tried to switch to a Dvorak keyboard. The trouble was, I don't use one computer. I use all kinds of computers. I use other people's computers. I use three computers fairly regularly at home and three at work. I use computers in the test lab at work. The trouble with customizing your environment is that it just doesn't propagate, so it's not even worth the trouble.

http://www.joelonsoftware.com/uibook/chapters/fog0000000059....

Re: Android Design

#60

Post by mhaymo »

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…

Does that second part really apply to mobile development though? Most people only use one phone, or maybe two, for anything more involved than making a call.
Post reply on HN