Google Kills Android Menu Button, Replaces It with Action Bar(pcmag.com)
pcmag.com
Google Kills Android Menu Button, Replaces It with Action Bar
http://www.pcmag.com/article2/0,2817,2399437,00.asp
8 comments
Damm that is annoying. I really liked the dedicated hardware button and considered it a great improvement over IOS.
In the last two phones I've owned they're not even hardware buttons any more, just special backlit icons below the screen that react exactly like the touchscreen above it. Which I don't like, but eh, designers love taking shit out of products these days.
> In the last two phones I've owned they're not even hardware buttons any more
They're "hardware" buttons in that they're hard-set in the hardware, but capacitive. The Galaxy Nexus has done away with even "hardware" buttons, the three black-on-white keys at the bottom are OS soft-keys and displayed on the screen, they're not even a separate and hard-wired area anymore.
They're "hardware" buttons in that they're hard-set in the hardware, but capacitive. The Galaxy Nexus has done away with even "hardware" buttons, the three black-on-white keys at the bottom are OS soft-keys and displayed on the screen, they're not even a separate and hard-wired area anymore.
That's true, though the difference doesn't matter to me that much as a user.
This is why you should avoid developing for the Android for at least 6 more months. It has been too liquid and fragmented so far. The yield for your effort is not very optimal.
I would argue that now is the perfect time to start developing for Android, if for some reason you aren't doing it yet. The recently published design guidelines from Google are clear and lay a good foundation for anyone who has struggled with figuring out how to develop and design for the OS, and also show that Google finally "gets" where their platform has been lacking so far.
The Action bar, although in a limited manner, can also be implemented in older versions of Android, so from a coding perspective, there's nothing terribly scary about it.
The Action bar, although in a limited manner, can also be implemented in older versions of Android, so from a coding perspective, there's nothing terribly scary about it.
Fragmentation is definitely not that kind of issue. It has to do with Hardware Acceleration, Screen sizes, Memory capabilities, native I/O threading and the likes. The only fragmentation issue I've ever had that directly concerns the UI is the presence of default Android Icons and fonts. Some manufacturers remove them, others decide to not implement them or give them arbitrary layout constraints: Sense UI for instance refuses to let you draw a Generic android icon over less than 40pixels. Motorola Xoom's default OS on Honeycomb did not let you display a size 106 font. Stuff like that.
These are the kind of fragmentation issues you're going to have to bite.
Fragmentation over whether a phone has or doesn't have a menu button is of no relevance. This app(1) for instance works both with the Action Bar, the software menu button and the hardware menu button. I only had to point the onCreateOptionMenu method to a single XML, and the ICS SDK did all the defragmentation work for me. It works fine from Froyo to Ice Cream Sandwich, on tablet, on phone, on KindleFire.
(1) shameless plug: https://market.android.com/details?id=com.fairyteller.icanre...
These are the kind of fragmentation issues you're going to have to bite.
Fragmentation over whether a phone has or doesn't have a menu button is of no relevance. This app(1) for instance works both with the Action Bar, the software menu button and the hardware menu button. I only had to point the onCreateOptionMenu method to a single XML, and the ICS SDK did all the defragmentation work for me. It works fine from Froyo to Ice Cream Sandwich, on tablet, on phone, on KindleFire.
(1) shameless plug: https://market.android.com/details?id=com.fairyteller.icanre...
a lot of contracts will come up of companies updating apps..money to be made..
When the poorly coded app freezes, the Android menu buttons are often the only escape. This was an advantage in my opinion.
I'm actually surprised by this. I've never liked the extra hardware buttons: they're in different orders on different phones, developers use them inconsistently and (IMHO) they lead to an inconsistent experience (eg in a browser you press the "back" hardware button to go back but a "soft" button to go forwards). Oh and discovery is more difficult (eg compare the iOS Settings app vs Menu -> Settings).
That all being said, I see ICS as a watershed moment for Android. I personally still prefer iOS but with ICS (at least with the native Google experience rather than the crapware layers most handset makers put over it) I think it's reached a point where I think it's a reasonable choice for, say, (non-techie) friends and family.
This all reminds me of the mouse a little. The Mac famously persevered with one buttons but the Windows two button mouse clearly won (even OSX has context menus). Even so, I have a hard time explaining to people about right-clicking so it's problematic. On iOS at least I think the single button is just fine, even preferable, and certainly far easier to understand and more consistent.
That all being said, I see ICS as a watershed moment for Android. I personally still prefer iOS but with ICS (at least with the native Google experience rather than the crapware layers most handset makers put over it) I think it's reached a point where I think it's a reasonable choice for, say, (non-techie) friends and family.
This all reminds me of the mouse a little. The Mac famously persevered with one buttons but the Windows two button mouse clearly won (even OSX has context menus). Even so, I have a hard time explaining to people about right-clicking so it's problematic. On iOS at least I think the single button is just fine, even preferable, and certainly far easier to understand and more consistent.
On iOS at least I think the single button is just fine, even preferable, and certainly far easier to understand and more consistent.
I don't disagree that the right mouse button can take new users a while to come to grips with.
The trade off of course is that even in moderately complex tools, a single button can't provide all of the actions a user would likely want to do. In the Mac world this was historically resolved by burying functions under layers of unmemorable keyboard combinations...e.g. command+shift+t or some such or in menus in the menu bar.
So the question then becomes, who do you optimize your interface for? The new user that can barely understand the abstraction of moving a physical device that's loosely mapped to screen coordinates? Or the user that needs to get-stuff-done-and-after-all-won't-be-a-new-user-all-that-long.
I personally think this move away from the menu button in Android land is a mistake. I already have issues with it on my Tab. With the software button showing up all over the screen or not at all.
I don't disagree that the right mouse button can take new users a while to come to grips with.
The trade off of course is that even in moderately complex tools, a single button can't provide all of the actions a user would likely want to do. In the Mac world this was historically resolved by burying functions under layers of unmemorable keyboard combinations...e.g. command+shift+t or some such or in menus in the menu bar.
So the question then becomes, who do you optimize your interface for? The new user that can barely understand the abstraction of moving a physical device that's loosely mapped to screen coordinates? Or the user that needs to get-stuff-done-and-after-all-won't-be-a-new-user-all-that-long.
I personally think this move away from the menu button in Android land is a mistake. I already have issues with it on my Tab. With the software button showing up all over the screen or not at all.
This is Matthias Duarte at work. A "bar" has been present in webOS since the beginning. In 1.x and 2.x, you could press the app name or swipe down from the top of the screen to view the app's menu or other options like Cut n Paste, logging in or out, etc. In 3.x, the top bar was expanded to include notifications and dashboards, greatly improving multitasking. In all three versions, the top bar also had quick access to system settings (again with a tap or a swipe down) such as WiFi, Bluetooth, VPN, or airplane mode.
Such a shame that Palm/HP let Duarte go. He's really bringing the best of webOS to Android. The classic webOS experience (which was a little muddled up with the Touchpad) only had buttons for power and volume. Everything else was done tapping or swiping on the screen or gesture area. Now, Duarte is doing away with hardware buttons on Android and who knows, maybe a gesture area is next.
Such a shame that Palm/HP let Duarte go. He's really bringing the best of webOS to Android. The classic webOS experience (which was a little muddled up with the Touchpad) only had buttons for power and volume. Everything else was done tapping or swiping on the screen or gesture area. Now, Duarte is doing away with hardware buttons on Android and who knows, maybe a gesture area is next.
Duarte's work at Android as Director has been really impressive. Honeycomb was the first major release with an element of his design influence.
Besides, I really loved Web OS UI. It was built for user-friendliness from the ground up and brought some very bold design decisions to the table. It sadly never took off.
Besides, I really loved Web OS UI. It was built for user-friendliness from the ground up and brought some very bold design decisions to the table. It sadly never took off.
[deleted]
I wish he hadn't been let go, but for perhaps the opposite reasons... ;)
If only we could go back in time and eliminate all of the Android phones which have a menu button and/or are not running ICS.
Oh. Wait. That's like 99.999% of all Android phones.
Oh. Wait. That's like 99.999% of all Android phones.
Exactly this. As an android developer, I'll developer my applications for the broadest range of devices that I can support. I know eventually ICS will take off, but for now 80% of the market is >= 2.2.
This is just another wrench thrown into the cog of advancing Android development. They pretty much have to break all their conventions before moving forward which is a pain in the ass to work through.
Also, if Google actually cared about it's developers, wouldn't it make sense for them to back this decision up with an official library to support an action bar on other OSs? There's third party libraries that you can use but it just goes to show again that Google just doesn't really care which state their developers are in.
This is just another wrench thrown into the cog of advancing Android development. They pretty much have to break all their conventions before moving forward which is a pain in the ass to work through.
Also, if Google actually cared about it's developers, wouldn't it make sense for them to back this decision up with an official library to support an action bar on other OSs? There's third party libraries that you can use but it just goes to show again that Google just doesn't really care which state their developers are in.
You do know that issue is discussed in some depth in the google piece under discussion?
The hardware buttons were one of the worst aspects of the Android experience and its good that their are finally going away. It's a shame that given the fragmentation and poor upgrade paths it will be at least a year before there is sufficient usage of ICS for developers to consider spending the time to implement for it.
Although I've read about poor UX experience with the action bar in that its too close to the space bar so you often end up hitting the soft buttons accidentally when typing 'space'.
Although I've read about poor UX experience with the action bar in that its too close to the space bar so you often end up hitting the soft buttons accidentally when typing 'space'.