Hacker News Reader

Comment by dolinsky | Hacker News Reader

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

View on HN

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.

Android does do this from any screen, you just have to press the home button and hold it down, which will bring up the 6 previously used apps.

>As a developer, I don't want the obligation of an unlabeled inconsistent back button constantly to annoy and confuse my user.

Then don't override the default functionality. Overriding the back button on android is like doing so in a web browser, optional and a dumb idea.

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.

> ... or what level of destruction the back button will perform

This is true especially when the app provides the button.

> In iOS, the developer is free to label the back button or to disable it entirely to remove ambiguity.

You can do what you like with Back in Android, including disable it. http://android-developers.blogspot.com/2009/12/back-and-othe...

> I would say that this is far more powerful

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.

On the iPad now this is a four fingers swipe up, then a single press. Or a 4 finger swipe across to the next app.

Reply on news.ycombinator.com