Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: