That's not an excuse for Android apps that use it inconsistently obviously (though the framework is pretty good about making sure obvious implementations do the obvious thing). But on the whole I think it's a very good feature.
Likewise, "menu" is something that almost everything has and probably deserves a hardware button (or at least a button with a persistent location and presentation -- the Galaxy Nexus apparently has no "hardware" buttons outside the touchscreen).
The "search" button that so many Android phone have, on the other hand, is completely beyond me. Ridiculous.
Instead of launching the browser and then going to an web address, I can punch it in after hitting the search button. Opens browser with that address.
I never have to launch the browser and then search for something.
It's also great if you need to find someone in your contact list and dont feel like scrolling
The search button is also contextual, so that if you're within an app you can search for whatever(maps, sms etc)
Also long pressing on the search button brings up the voice commands.
1) people being confused by the back button because they don't realize it will always pop the current view of the navigationstack, which is systemwide.
2) the fact that the back, menu, search and home buttons are dedicated hardware buttons.
Explaining how 1) works does not mean that 2 is not broken. Personally I find 2 to be the interesting discussion.
Seeing how these hardware buttons are being changed to be a dedicated part of the Galaxy Nexus' touchscreen, and how not all vendors actually put all 3 buttons on there, it's not too hard to argue that something about the hardware buttons is at least flawed, if not broken.
I use my android mostly for calling, texting, music and instapaper (actually instafetch). I hate how I can't easily feel my phone and push a button for things like mute, or pause, or end call, or next song. Sometimes I actually have to unlock the phone with the top button, then swipe to really unlock, navigate to the right app/activity if it's not forefront, then look at the phone to see where the appropriate touch button is located.
Am I one of the few that wants more hardware buttons? And not the capacitive (fixed touch buttons) but the real buttons that maggit mentions elsewhere in these comments; buttons you can feel with your fingers.
That being said, I hope Google will try to get rid of all the physical buttons and "bottom bar buttons" in Android and replace them with gestures (learn from N9 Meego), so we can fully utilize 100% of the screen (and of course no more wasted front space with physical buttons, too). I think there are some phones coming out like the LG U1, which will have both a physical home button and virtual buttons with ICS. How does that make any sense? It wastes double the space.
Another feature request would be getting rid of the icons, too. I don't think icons belong in the touch world. You need bigger graphical elements, that are also richer than just an icon. I see them moving in this direction with some apps, but they need to move faster, preferably by Android 5.0.
I also disagree with Gruber's complaint:
Here’s one thing I don’t like about the Android Back button that I’ve never seen a counterargument for: it presumes that you, the user, remember the activity stack. If you turn your phone on and you’re looking at a web page in the browser, if you don’t remember what you were doing immediately before opening the web page you’re looking at, you have no idea where you’re going to go if you hit the Back button. Could be another app, could be another web page, could be the home screen. And if hitting the Back button takes you somewhere you didn’t want to go, there’s no Forward button to reverse it. It’s like leaving a breadcrumb trail in the dark — you have to remember where the breadcrumbs are because you can’t see them.
http://daringfireball.net/linked/2011/11/02/defending-androi...
Actually, I think what's nice about it is that you don't have to remember the activity stack. You just hit back if you want to go to the previous activity, and if you don't want to go to the previous activity, you go to the home screen. Why would you hit back if you didn't want to go to the previous activity and also didn't remember what the previous activity was?
Here's a common analogous scenario for me. I unlock my phone to a web page. I finish reading the web page and then go, "How did I get here?" I hit back, which usually takes me to the previous web page, to google reader, or to twitter. I then go on with what I was doing, probably skimming feeds. It's a great, natural workflow that allows me to pick up exactly where I left off.
I wonder how Gruber manages to use web browsers' back buttons without getting confused. I mean, when you hit it, it can go to SOME RANDOM WEB PAGE!
As for the forward button, it's just a matter of hitting the exact same link or button that you did the first time. Forward is redundant.
And of course, if you're ever confused, you can just hit the home button and start over. This is your only option in iOS. If you get routed to twitter from another app, and then you want to go back? Hope you remember what you were doing before. In fact, you'd better make sure you remember if you want to get back. Because you're going to have to go back through the home screen to get there.
In my scenario above, ported to iOS, if I wake up my phone to a web page, I basically have no way to go back to the activity I was doing before the web page except to just remember. That, to me, is a much worse workflow. There just aren't any breadcrumbs at all.
I also don't think there's any way to get rid of the OS-wide buttons, because there are basically two axes of navigation. There's the OS wide one along which the back button acts, and there's also the in-app one that takes you between panes of an app. Swipes already move you between panes. How can they also move you back in the activity stack?
I do agree with you that icons are outdated. I hope Android steals more from Windows Phone 7. Those tile are gorgeous.
1. They are capacitive, so there is no tactile feedback ever
2. They are made to be near invisible, so you can't see them in dim light
3. The icons on the buttons are not immediately crystal clear to me
My HTC Legend has none of these problems: I can find the buttons in the dark by feel, and the iconography is clear. To me, the back and menu buttons (and to a lesser degree the home button) are helpful tools that I use all the time.
I am planning on getting a Galaxy Nexus as soon as I can. The only worry I have about this phone is the lack of proper hardware buttons that I can locate and use by feel alone.
I love (some of) the hardware buttons.
So maybe it's just Samsung's implementation of the buttons that is broken, and not the concept of Android hardware buttons. I don't know :)
> 1. They are capacitive, so there is no tactile feedback ever
You can enable haptic feedback or tones (cringe), neither of which has substantial effect on battery life.
> 2. They are made to be near invisible, so you can't see them in dim light
True.
> 3. The icons on the buttons are not immediately crystal clear to me
While this may be true, they quite consistent with all the other android phones. (Are you specifically concerned about the having an icon for menu instead of the "menu" text?)
Apple has done a magnificent job of creating loyal converts based on feelings. Their devices have traditionally been behind Android on a number of features (but always catch up later) because they focused on making people feel like they could accomplish the tasks they wanted to.
Android goes about adding features that are super coolnewawesometrendy and they give it to you right away and it's your job to jump in and learn how to use it. Apple will slowly introduce you to new concepts even if it means limiting functionality. The Android and iOS approaches are both valid but one is better for my mother while the other is better for me.
So when we talk about the back button on Android maybe we're missing the point? Maybe instead of discussing whether the button is inconsistent or not we should be talking about how to make the entire OS feel like it helps you get what you want to do done. I don't have all the answers but I do know a few of the right questions.
Assuming you give someone an Android phone or tablet who has no previous experience or expectations... How do you make the button feel like its consistent? What is the intent of someone pressing the button? How will the action of the button fit in with the rest of the user experience? How can we get users to know what to expect after a single use of the button? Is the button even necessary? Was the decision to include this button made because of preconceived notions such as how phones used to function before touch screens?
This might be a tad bit off topic but I feel like these ideas are a natural next step in the discussion.
Correct, but something being by design does not imply it not being "broken". We have plenty of examples of things with flawed designs.
Activities are hidden, they are not a user visible concept, so you cannot easily build a mental model without knowing and consciously thinking about them. From the UI, it just looks that the button has been overloaded with two functions: changing applications and changing views in the same application, because applications and views are the two very obvious UI concepts.
I also think Matias Duarte and the Android designers agree that the back button has some problems as Android 4 now has two back buttons: the good old one on the bottom and another one on the top left that behaves just like iOS's. I'm not sure two buttons with similar but slightly different behaviors are the perfect solution but we'll see if people like it.
A button such as the back-button on the android, is used to navigate in almost all applications. With the amount of "load cycles" the back-button experiences, it is bound to either fail or start operating inadequately [1]. If or when this happens, the phone becomes rather unusable as it is nearly impossible to navigate in applications that do not have any built in user interface options to perform the same action.
[1] I do not hold evidence for this to be true in general and my hypothesis is only backed by personal experience and the notion of failure rate in a load frequency perspective.
