Hacker News Reader

Comment by masklinn | Hacker News Reader

> I really think iOS should also steal the back button from the Android.

There are many potentially interesting things in Android (although I think WebOS would be a far better source of ideas to steal, it's always been).

But not the back button. The back button is probably the worst part of Android's UI, it's the embodiment of "mystery meat" navigation and interface: a hardware button which behaves in a completely arbitrary and essentially random manner without providing any clue as to what will happen when it's tapped.

View on HN

Android's back button is its single best feature. Without it, I might not still be using Android. What it should do: go back to the screen you were previously on. Android apps are generally full-screen apps; there's little mystery there (IMO).

Unfortunately, Google is mandating that it acquire "up button" semantics rather than back button semantics - for many apps, it's supposed to go to the "top" level before it exits out. That I'm not a fan of, and I'm afraid it's going to encourage its "mystery meat" nature, because it'll no longer act like a browser back button.

> what it should do: go back to the screen you were previously on

At the time I used Android (1.6) this promise was broken nearly all the time, so you'd skip or just be unable to get to the exact screen you were looking for... removing that is very wise.

Have you ever used a palm pre? Being able to go forward, back, alt-tab and multitask all with a directional swipe beats the back button on any android device i have tried. Though I think either way beats iOS style.

>Unfortunately, Google is mandating that it acquire "up button" semantics rather than back button semantics - for many apps, it's supposed to go to the "top" level before it exits out.

You have a source on that? I know of only one Google app that does this if called from an outside Activity or notification.

http://developer.android.com/design/patterns/navigation.html

"If your app was reached via the system mechanisms of notifications or home screen widgets, Up behaves as described for app-to-app navigation, above.

"For the Back key, you should make navigation more predictably by inserting into the task's back stack the complete upward navigation path to the app's topmost screen. This way, a user who has forgotten how they entered your app can safely navigate to the app's topmost screen before exiting it.

"For example, Gmail's Home screen widget has a button for diving directly to its compose screen. After following that path, the Back key first returns to the Inbox, and from there continues to Home."

(Emphasis added.)

Thanks, wasn't aware of this and frankly am quite disappointed by it.

I got bitten by it just yesterday. I was setting an alarm. I pick the alarm, click on 'Time', set the time, hit the 'set' button. Then the time goes away and I'm back on the alarm screen, and I hit the back button to exit the app. But that 'cancels' my change and the alarm goes back to the old time.

It's a combination of setting alarms having too many screens, and android having trained me to hit back-back-back when I'm done with an app.

Hmm. When I'm done with an app, I usually hit the home key. I usually use 'back' when I'm taken to another app by some other means: an email notification, a link starting the browser, opening a file in a file browser. Perhaps the confusion lies in different usage behaviours?

And FWIW, I just tried doing what you describe with the ICS clock / alarm app. It worked as expected for me: after tapping "set", the alarm was set, and Back took me back to the clock, and another Back exited the app.

One practical way the new semi-broken approach affects me is with JustPictures, a photo viewing app. I use it in conjunction with ES File Explorer. It used to be that when you launched a photo from the file explorer, it would come up in JustPictures, and then you'd return to the file browser when you tapped Back. But now, after JustPictures was updated to better conform with guidelines a month or two back, it goes into its own "tile" view of the folder before sending me back to the file browser. This behaviour is according to the new guidelines, but I find it quite upsetting. I launched JustPictures not because it has its own top screen and file system navigation etc., but because it has more reasonable photo viewing functionality (specifically, file-based rather than media library based) than the gallery app.

The new Android approach seems focused on becoming more like iOS, where each app is its own silo, rather than how it started out, with activities blurring the distinction between apps and enabling a higher level of integration. But the more Android becomes like iOS, the less reason I have to prefer it over iOS.

There's actually a similar dynamic going on with Firefox. Firefox is slowly cloning Chrome's look and feel, and I have to work harder and harder to get the menu bar, status bar etc. back in place. The day I can no longer do that, is the day in which I might as well give up on Firefox and use Chrome. (Well, that and Chrome's text selection algorithm. It's absolutely hideous for this compulsive text-highlighting reader.)

"I just tried doing what you describe with the ICS clock / alarm app. It worked as expected for me: after tapping "set", the alarm was set, and Back took me back to the clock.."

Are these the screens you see?

- Clock with alarm time

- 'Alarms' page with list of alarms and 'add alarm' button

- 'Set alarm' page with time, repeat, ringtone, etc. and cancel/delete/ok buttons at the bottom

- Set time - with the dials for hour and minute, and cancel/set buttons at the bottom

I'm talking about adjusting the time dials, hitting 'Set', returning to the 'Set alarm' page, hitting back, which simulates hitting 'cancel', throws away my change (without asking for confirmation), and returns me to the 'Alarms' page.

Does this make more sense? I'm on Ice Cream Sandwich if that helps. (Being forced to upgrade a device with a smaller viewing area to an OS that assumes a galaxy-sized screen, that's a whole separate rant.)

I'm starting to realize it's partly because backing out of an app was a way in my mind to close the app. But ICS doesn't seem to pay attention to that anymore, so you're right, I should just hit the home key.

That's a problem of the app you're looking at, not the button itself.

The design guidelines clearly state that you _shouldn't_ hijack that button to change the default of 'back to last activity' unless you have a very good reason to do so.

If you constantly see apps behaving unexpectedly - file a bug/complain to the developer/search for a better suited alternative? That actually adheres to the platform guidelines.

From the same author as the parent article: http://ignorethecode.net/blog/2011/07/15/the_back_button_dil...

The guidelines are broken then if so many developers are compelled to break it.

It if confusing, but having been forced to use an Android device for the last two months, and now back with the iPhone, it did have some advantages. Sure, you wouldn't know what it would do, but before having to go home and you just press the back button, and sometimes it takes you where you wanted, sometime it doesn't. Then you just rerun the app.

And yet, many iOS apps end up using screen space on a Back button. And I find myself missing it on those that don't.

> And yet, many iOS apps end up using screen space on a Back button.

I did not say "back" is a bad idea (seriously, read what's written, not what you think would be the easiest to pithily reply to). "Back" is a good idea when it is coherent and/or explorable. Which the android "Back" button is not, because it's mystery meat navigation.

iOS apps use screen space with a "Back" button, and that back button generally tells you where you're going to go back to[0]. Android's back button does not, you might go up in the application's hierarchy, you could go sideways into an other object of some sort from which you originally came, you could go to an other application, and you have no way to know without learning how each and every application hooks into that button.

[0] that's Apple UI guidelines, although even when applications don't implement it they won't just drop you into an other application "at random".

On Android you always go to the last Activity, whether that activity is from the same application or a different application. When you get something other than the last activity, that's because the developer is overriding the button's purpose.

Like the built in Messages, or Gmail, or Browser apps? It's hard to have a general rule when it seems that most apps on the platform break it. :(

iOS "back" button is generally an "up" button, not a "back" button. For that reason, it's not nearly as useful as Android's.

> iOS "back" button is generally an "up" button, not a "back" button.

So's it on Android[0], except when it's a back button, or something else entirely.

Which, you may want to note, is the very issue I originally outlined with it: Android's back button behaves inconsistently and provides no way to discover its behavior in advance.

> For that reason, it's not nearly as useful as Android's.

Inconsistent behavior precludes usefulness. The iPhone's "back" buttons behave consistently (and explain where the user will land, if Apple's HIG are followed). Theoretically the Android back button could be more useful than iOS's, practically that is not the case.

[0] http://developer.android.com/design/patterns/navigation.html

> If your app was reached via the system mechanisms of notifications or home screen widgets, Up behaves as described for app-to-app navigation, above.

> For the Back key, you should make navigation more predictably by inserting into the task's back stack the complete upward navigation path to the app's topmost screen. This way, a user who has forgotten how they entered your app can safely navigate to the app's topmost screen before exiting it.

> For example, Gmail's Home screen widget has a button for diving directly to its compose screen. After following that path, the Back key first returns to the Inbox, and from there continues to Home.

You're quoting the reference I myself quoted elsewhere in these comments. I quoted it as evidential support for a trend in Android that I decry - one that may drive me away from Android, along with its movement away from the menu button towards cryptic app-specific icons and inconsistent menu button placement.

Moved from the Palm Pre (1st gen.) to Android on EVO 3D 6 months ago. AFAIAC, both the Back button and the Home button are crutches. I use it w-a-y to much b/c there is no card implementation (like webOS had). It was very easy to go back & forth between open apps and cards within the same app. Backswipe=last screen viewed.Simple. The inability to easily, definitively close apps (upswipe/throw off screen on webOS) is maddening. I never know if an app is "still" running or really closed (& don't know until I go home & pick app.... Sloppy, messy, maddening. I REALLY miss webOS.

That's like saying that the 'T' letter key on the keyboard behaves unpredictably and should be removed just because any program could map it to any other character or action.

Of course I am not familiar with your background, but I wonder what you base that opinion on.

What Android device did you own and use that had such a bad implementation of the back button?

Reply on news.ycombinator.com