I have a similar problem on my Droid X. Sometimes the back button goes back a page (such as in a web browser) or while reading a message back will go to my contacts list (in google talk or google voice).
But sometimes, in the same apps, the back button might take me back to the home screen (If i answered a message from the notification bar), or a previous app if something launched a browser.
It's incredibly aggravating that the behavior changes, and especially so as Android devices have a home button! Back should be constrained to a specific application. Otherwise in google talk I have no reliable way to get back to my contacts and usually have to make a trip back to the home screen to directly launch the talk app.
I think the presence of a hard back button in Android is something that iOS is sorely missing. Whenever I switch from using my Droid X to my iPad I am constantly looking for the 'back' button, especially when installing an app from inside the Apple App Store (I find it very annoying that iOS kicks you out of the App Store and brings you to a seemingly random home screen just to show that it's now installing an app).
The back button in Android does have the fault of not always being consistent, but that is due to it being usable by the developer of individual apps. I find it extremely useful that I can be doing something in Tweetdeck, click a link which opens up my browser (Dolphin HD), view the full article, and then just press the back button to go right back into Tweetdeck. That's just not possible on iOS.
Also, long-pressing the back button in certain apps (like Dolphin HD) provide a nice shortcut to quitting the app (instead of keeping it running in the background), which helps on battery life.
Can't say much about Android, but the Back button on the Windows Phone is unreliable and doesn't always take you back to where it's supposed to be. It's just confusing. I much prefer the simple UI that iPhone has with a single button.
I kinda have to agree with contextfree that I can't imagine not having a back button on my wp7. But I also agree with you that it doesn't always take you to where you expect to go. Same problem with the search button.
The problem here, I think, isn't so much the button itself, but developers not following the conventions, and Microsoft (and possibly google, I don't have an android) not steering developers in the right direction.
For example, the IMDB app on WP7 has a search icon on the top right of the screen which they expect you to use to search. They should have used the already existing search button on the phone, but if you hit the phones search button, you go to bing search, because the app only knows how to use it's own search button.
Same with back buttons. If the developer has used it properly, it should take you to the previous screen of that app, but 90% of the time, it goes to the previous app.
Hopefully 'app switching' in mango (I don't think multi-tasking is the problem, its that we can't switch from one app to another without going to the home screen) will solve much of the back button issues, and possibly the new Bing/app search integration tools will help with the search button.
I'm curious what these apps are that don't support the back button. The back stack is an integral part of the Silverlight framework on the phone - unless your app is XNA-based you would have to go out of your way not to support it.
btw, IMDB can't support the search button because it's actually not exposed to third-party developers. Use of the search button for in-app search is actually scrapped in Mango because people found it confusing - the built-in apps that support search now have their own on-screen search buttons.
Thanks for clarifying on the search button, and now that I'm going through apps on my phone, I can't seem to find the places where before I've found 'unexepected' use of the back-button exiting the app rather than taking me to the apps previous screen.
I guess that is really the problem, the majority of apps follow convention, but then every once in a while you get something that doesn't and it is gets confusing.
Fair enough. My guess is that the apps that don't support it are mostly games, which generally use a different framework that doesn't bake in this or any other interface conventions. But I can see how any amount of inconsistency could prevent a feeling of confidence. I guess to me the fact that these games tend not to look or feel anything like other apps is enough to keep their behavior from polluting my subconscious mental model of expected behavior in general.
Being useful and hard to use are two different things. For developers, more buttons mean more things to consider when developing apps.
Personally, I just don't see the usefulness of Back buttons on WP. The Back button should be replaced when the multitask swtich feature in "Mango". The Search, maybe, it's useful sometimes. Again, like you've mentioned, the users would have to guess whether it will bring up the Bing Search or the in-app one. It sounds just confusing.
I'm not saying your POV isn't valid, but when you say "I just don't see the usefulness of Back buttons", my visceral reaction is as if you'd just said "I just don't see the usefulness of having thumbs." After using WP and Android for a while, hitting the back button became almost a subconscious reflex action, and trying to use something without it seriously almost feels like I'm missing a body part.
I am well aware that we all got 10 fingers unless you are mutants. Why use only one, right? Well, when comes to UI, the less is better for users. And it's less UI behavior consideration for developers. That's all.
Well, it actually did. Compare the Firefox 1 UI with current FF5 browser you will notice how much the UI has changes, simpler and cleaner, and the history-back buttons are gone.
I do not think those pictures show what you think they do.
I can clearly see the back button in all 3 UI pictures, including the one for Firefox 5. For that matter, I can see the back button in the Firefox 5 window I'm using to type this comment. I agree that Firefox 5's UI is simpler and cleaner than Firefox 1's and Netscape's, but I don't know where you got the idea that they'd eliminated the back button.
Obviously you didn't read my reply clearly. I said "the history-back button" (one of back buttons)is gone, that is the little down-arrow button when clicked it shows the history.
fwiw, I've had completely the opposite experience. I've found the back button a godsend on both WP and Android platforms, and haven't really noticed this unreliability. Actually, as a user I prefer to use my Windows phone over my other devices almost entirely because of a combination of two features: the back button (missing from iOS) and a decent soft keyboard (missing from the Android phone I have, which is running 2.2. I've heard the keyboard in 2.3 is much improved, but unfortunately the upgrade wasn't available for my phone last I checked). There are a lot of things the other platforms have over the WP, but being able to have those two things together is enough to outweigh all of them and ensure that my SIM card stays in my Windows phone 70% of the time ...
What WP do you have? My Samsung Focus soft touch button is so sensitive that I hit those buttons by accident ALL THE TIME. That's just frustrating. I'd rather not having any button at all or replace those with press-down real buttons.
Having fewer buttons seem to make interface cleaner and less chance to screw up for users. But again it's a hardware issue for debate rather than software.
Oh, I hate capacitive buttons too as do all right-thinking people, but I still vastly prefer the capacitive back button (on my Dell Venue Pro - not recommended, btw) over none at all. I don't really hit the buttons by accident myself, but this does seem to be a problem for new users (as I've discovered on the occasions where I lent my phone to someone who needed to make a call).
That's exactly my point. It's a major fundamental difference between iOS and Android. The back button in Android can be contextual, while the back button in iOS only moves back between views in the same application. There are many times during a day where I switch between apps by clicking a link only to want to immediately return to the previous app, which is not possible in iOS (I first have to click the 'home' button or double click it to bring up the previously used apps bar and then select the app I want to return to).
But doesn't that render the function of the back button ambiguous? Task switching is not the same thing as navigating a stack of views.
EDIT (more): I can also imagine many situations in which I want to disallow a back button (like in my own application for example), or in which the back button could be expected to perform, but actually doesn't. Say I'm in a game and have navigated to a level, start the level, but then decide I want to exit. It isn't clear that the programmer has implemented the back function, or what level of destruction the back button will perform. I'm going to have to test the back button every time I press it to see what it even does, or what the implementation is. This is poor UI. In iOS, the developer is free to label the back button or to disable it entirely to remove ambiguity. I would say that this is far more powerful than occasionally switching to the previous app if I haven't navigated at all yet in the stack of the new app.
What you consider ambiguous many users could consider extremely useful, and the beauty of having the soft key is that if you don't want to use it you don't have to. As for the 'level of destruction' that a back button would cause, it is up to the developer to properly save the state of the application whenever the state of the application / game changes. This isn't unique to Android AFAIK.
I'm not sure if you've used an Android device, and it is quite different from an experience w/ an iOS device, but the inclusion of a dedicated back button really is a welcome one IMO. You have to switch from thinking about the back button as 'go back to the previous view in this app' to 'go back to the previous thing that I was doing'. I think iOS doesn't go far enough to create synergy between apps here (and yes, Android can go too far in some instances) but the point is that the possibility is there in one and isn't in another.
As a developer, I don't want the obligation of an unlabeled inconsistent back button constantly to annoy and confuse my user. I want it to be there when I want it to be there. This holds in general for the iOS ecosystem.
The one feature that you are really stating is a plus of a dedicated back button is to serve as a pointer to the referring app, but there is nothing in the UI to indicate that the back button will go there either, just a mental note by the user!
If you sum up all of the points of confusion that could possibly arise from a permanent and ambiguous unlabeled back button to be used for in-app navigation and compare it to the pain of double tapping to get back to the previous app in iOS (guaranteed, by the way, from any point in the app), I don't see how you could possibly come to the conclusion that forcing a back button into every point of every UI is a net plus. Not even close.
> but there is nothing in the UI to indicate that the back button will go there either, just a mental note by the user!
I'm not sure where you expect such an indicator to be, but that isn't the problem. If the user can't remember where they came from, why would they want to go back? The same 'problem' must also apply to the double-tap of iOS. (Which I had never heard of until now, but I only use iPhones occasionally.)
Given that you seem to have no issue with the concept of global 'return to home' and 'return to previous app', both of which are places previously visited, it's rather contradictory to take issue with a method of going back which is at worst equivalent to those features.
> If the user can't remember where they came from, why would they want to go back?
Because "back" is often conflated with "out"--the user might simply be done with the task and wants to get out. Unfortunately, the app simply shoots them to the previous app on the stack, which may or may not be where they want to go or remembered they came from.
Ex: Many apps go to the browser, but the user might not remember which app sent them to the browser. They might have thought it was Twitter, when it was in fact the home screen.
To enlighten you, the home double tap in iOS does not take you straight to the previous application. It brings up iOS's multitask tray that has the four previously viewed apps on it, in order of recent use. The first app on it is always the previous app. You can see which one it is. Android doesn't show this to you, nor do you even have the option of getting to the previous app unless you are at the bottom of the stack.
Edit: We're arguing about the merits of having a dedicated back button. If an advantage to the iOS task switching feature is found in yet another button on Android, that doesn't contribute support to the back button's existence.
>Ex: Many apps go to the browser, but the user might not remember which app sent them to the browser. They might have thought it was Twitter, when it was in fact the home screen.
This is exactly what I like about the back button. Frequently I'll finish an article I was reading in the browser but not remember immediately what brought me there. (This might happen if I had to interrupt reading it for a moment to pocket my phone and use two hands.) I'll have a sense I'm supposed to do something with it, but what? Did someone text it to me? Was it in a Gchat? Email?
"Well, that was a good article... why am I here, again?" I hit back, and find myself in an email with a link to the article. "Ah, yes, that's it! Joe emailed it to me." Now I can reply to Joe about it.
Maybe this wouldn't be as helpful to others, but I like it because I'm quite forgetful.
There's no distinction between "tasks" and "views" in Android. Everything is just an activity. When you press back it takes you to the previous activity you were on. When you launch an application you're really just launching the default activity for a given package. The home screen is itself an activity.
This also allows you to launch in the middle of an application, to a specific screen, etc. It's better to think about activities as URLs. The back button on Android behaves the same as the back button on your browser.
Even if Android restricted what you could do, it would be an apples-to-oranges comparison since an app-specific back button has no concept of 'take me to the activity that spawned me'. But in light of what I've shown it is hardly less powerful.
You miss my point in disabling the back button. The user still needs to test it every time to see what it does and where it goes, if it works at all. That's bad UI.
As for going back to the previous app, as I argue below, the back button is crippled there too because you need to be in the root view controller of whatever stack you're in for it to do that, and you need to remember which app sent you there, which is not indicated in the UI.
In iOS you can get back to the previous app from anywhere in the navigation stack with a double-tap gesture. An additional tap, to be sure, but all ambiguity from the constant and ever-present back button is removed.
It's bad UI if the developer programs bad UI. The back button returns you to the previous activity by default, you can override it but you should have a good reason. If I downloaded shovelware from the app store and a button labeled 'Play Game' actually took my photo and uploaded it to hotornot, I wouldn't blame iOS for allowing buttons to do things other than what they said.
That's also another thing: iOS is app-based, Android is activity based. You don't have the same navigation possibilities in iOS so you can get by without it. When you flow from one activity to another, you want to return to the previous activity rather than the previous app. Hence the back button.
I talked about UI indications for the previous app elsewhere, but it's dishonest to present the lack of indication as a point against Android when iOS doesn't even have a precise analogue of this, and what feature it does have already exists Android by long-pressing Home!
> but it's dishonest to present the lack of indication as a point against Android when iOS doesn't even have a precise analogue of this
No it isn't. This whole argument just boils down to whether it makes sense to require an unlabeled backward pointing arrow to be present at all times in all UIs. In practice it doesn't make much sense to require a button that isn't always used and doesn't always do the same thing just for the sake of returning to the previous app from an empty navigation stack when you need to do that occasionally. iOS might not do it, but this comes with the added benefits that no back buttons anywhere in the iOS UI is ambiguous.
I think what people fail to realize is Android already has the functionality to share or push functionality thats best suited for apps based on context, example as soon as you take a picture, you can push it to dropbox, send it to email, edit it in photoshop.. from a contextual menu and will automatically push that image to the app that you want. So being able to go back and forth easily is a huge advantage in Android.
The four-finger swipe to switch between apps more or less fixes that issue. I've had the four-finger gestures enabled on mine for a couple months, and they really are a noticeable improvement.
I find the 3 and 4 fingered swipes, especially on the smaller screens of the iPhone/touch devices to be pretty inconsistent and not very natural from a hand gesture perspective. I'd also suggest that 'more gestures' isn't what the average consumer is going to find as useful.
I'm also not looking forward to the first gesture requiring the use of my big toe.
You can't pull off a four-finger swipe with one hand unless you aren't holding your phone. Maybe on the iPad, but it's practically worthless for handhelds.
There's no such thing as a "specific application" in Android. With that in mind, the back button behavior makes sense. Launch your email client from the home screen, read a message, click a link. When you hit back in the browser, you go back to the email message. When you hit back in the email message, you go back to the list of messages. When you hit back in the list of messages, you go back to the home screen.
When you hit back in the browser, you go back to the email message iff the browser did not open with an existing history. If it did, then it navigates to the previous page inside that browser, instead.
I'm unable to reproduce this bug. I clicked a link from an email message and the browser opened the link in a new tab (several tabs are open). I clicked back and it took me to the email message.
If I have the maximal 4 open windows in my browser, and then click some link, it cannot open in a new window, so it opens it in an existing window. Then, back manipulates that window, rather than returning from the web browser itself.
The back button in Android is supposed to mean "take me to the last screen I was on"; it's not supposed to be tied to the specific app you're in. I have the reverse issue on iOS, if Twitter launches a browser there's no obvious way to get back to the screen I was on in Twitter beyond calling up the app switcher[1] Honeycomb introduces an "up" button[2], and it can be presumed the concept will make it's way to ICS.
[1] PSA: you call up the Android switcher by holding Home
[2] This isn't a hard button like home/back, instead the app logo gets painted with an "up" arrow when this is available.
Unfortunately, it's really up to the discretion of the app developer to decide what "back" does. There are guidelines and "best practices", but nothing dictated by the API or operating system.
The back button always goes backwards in the history stack, but the app developer can push new pages onto the history stack however they see fit. An analogy on the web is either navigating to a new page (back button works), or loading a new page on top of the current page (back button doesn't work).
Yeah, I've noticed that, too. If you jump directly into, say, an individual email on Android, you can't move "up" inside the application. I wonder if I'm just missing something.
I think they leave the "up" to the in-application UI. e.g. with email there's a button to go back to the inbox, but the physical back button takes you back to where you were previously. This seems more natural to me than for the back button to take you "up" in the application you're in. Otherwise how would you go back to where you were before?
Honeycomb adds the equivalent of the "up" button you're describing here. The convention is that in the upper left corner of a screen there's a button that takes you to your "home within the app" (e.g. the inbox for Gmail). I expect that this will filter into phone UIs with Ice Cream Sandwich.
(Yeah, I realize that using the back button to invoke the application's back function would cause its own set of issues. It's a case where the same button needs to do two different things based on the user's current mindset, which the phone obviously won't know about.)
Yes, it is natural to me too. If I am at the home screen and click on an email notification, I expect to read the e-mail, hit back and be back on the home screen, not in the inbox.
The back button on Android is fundamentally broken. WebOS is the only operating system that really does this right, and it's because they've architected the entire OS around it. The way apps use scenes and stages makes the whole thing flow.
Proper back button behavior isn't something you can bolt on, but Android could still get much better than they are.
But sometimes, in the same apps, the back button might take me back to the home screen (If i answered a message from the notification bar), or a previous app if something launched a browser.
It's incredibly aggravating that the behavior changes, and especially so as Android devices have a home button! Back should be constrained to a specific application. Otherwise in google talk I have no reliable way to get back to my contacts and usually have to make a trip back to the home screen to directly launch the talk app.