Hacker News Reader

Comment by rryan | Hacker News Reader

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 within the Music app. I don't mind having to hit back a couple of times because I've learned that you can just keep hitting back and you'll eventually get where you were.

View on HN

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 browsers, that shows the back stack?

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.

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.

The back button in browsers is often used as analogy, but how many tabs/windows do you have open in your browser? What if pressing the back button in the browser switched you to a word processor because that is what you were looking at before.

That's what alt+tab and ctrl+tab are for. The confusion comes from the use of only one back button instead of one per hierarchy.

On android we have only one system-wide consistent timeline to work with, and that's the timeline of fired intents. It works across the whole system. Back works on that level by default and is defined by default as "go back in time".

> I disagree. I think the confusion is caused by users not intuitively understanding the context of the android "back"

That's exactly the problem. The user should intuitively understand an action. Since they don't, that means it's Google's fault for implementing it poorly.

I've only used an Android phone once for 5 min (my Mom got one for Christmas), but that was enough to run into Back button confusion.

My assumption was that it would take me up the stack, since when I entered the Mail program and navigated down, Back took me back up. But when I entered from some other place (like the settings app) then back wouldn't take me up to inboxes.

I'm sure it would have made more sense if I realized it was a system-wide Back and not an app-only Back.

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 want to get to the top of the stack). Sometimes I even get confused when the back button takes me back a webpage in the browser.

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.

Why? The "multitasking button" should be enough for that. Press it, and you can switch to your app.

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.

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.

Reply on news.ycombinator.com