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.
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".
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.
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.
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.
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.
You have a source on that? I know of only one Google app that does this if called from an outside Activity or notification.
"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.)
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.
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.)
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.)
What Android device did you own and use that had such a bad implementation of the back button?
swiping up with 4 fingers works, too, at least on iPad.
To solve this problem, non-concave buttons (flat or convex) live in wells. These buttons in wells carry unnecessary aesthetic weight - lots of angles and short surfaces in a small space. Apple's hardware rarely carries such adornment - they do smooth, "authentic" surfaces.
As such, the Home button simply _is_ the well - and it's rarely pushed by accident.
Precisely. And we already have the solution at hand, it just lacks implementation:
swipe up from the bottom of the screen
It's missing so much that I find myself expecting the in-app back button to go back to the previous app if I click it enough. BTW, I've never owned an Android phone so my expectations aren't carried over from another OS -- it just seems natural and it's jarring when it's missing.
As an iOS and Android user the Home button is still my favorite. It's what I'm used to and for the most part they work the same on both platforms.
However, applications need an additional bit of UI so that from the SMS message you could go "back" to the list of all messages, etc within the app. It sounds like, on Android, there is some confusion between these two use cases and other issues that make it unreliable. It's a shame because the concept is sound.
http://www.iphonehacks.com/2011/12/how-to-fix-you-iphones-un...
1. http://techcrunch.com/2011/11/10/class-action-lawsuit-forces...
I agree, however, that the home buttons on iPhones (and I assume iPod Touches and iPads) wear out too quickly. My 3Gs's home button was getting pretty bad after two years of use, even with lubrication, though I will admit to having gotten a fair amount of sand and possibly a bit of seawater in it, and having disassembled and reassembled it several times, so that may not have helped things.
Perhaps with the ICS interface guidelines being more heavily read this has improved, but on the phone I have it's a very bad interface.
While a bit more cumbersome than a back button, you can double-press the home button and the previous app will be on the left of the list of apps that appears on the bottom of the screen. No guarantees it'll remember its state, though :(
Angry Birds may seem to be a silly little game, but it is not an edge case. It's an exemplar of interaction paradigms going forward.