December 19, 2014

Duarte on Honeycomb: Hardware Buttons, Multi-Tasking Overhaul and More

Image: Engadget

In a 25 minute interview at C.E.S. with Engadget’s Joshua Topolsky, Android Director of User Experience Matias Duarte revealed several details of what’s changing in Honeycomb, including that all hardware buttons will be optional, opening up manufacturers to create form factors that don’t include the familiar Back/Menu/Home/Search combination.

“With Honeycomb, you don’t need to have physical buttons. … We’re not going to dictate to you if you need to have buttons or not.”

Duarte, who was responsible for the UI of webOS and the Sidekick before joining Google, revealed other tidbits about Honeycomb in the interview:

  • He confirmed that Honeycomb is not just a tablet version of Android, but “is absolutely the direction for Android” for all kinds of devices.
  • The multi-tasking UI gets an overhaul, with an on-screen button that users tap to bring up a view of recent apps– not just icons and names, but a “visible, tangible representation” of the what the app looks like. While the long-press goes away for this function, it is “still part of Android in terms of interacting and selecting objects.”
  • An “application bar” at the top of the screen will show different actions the user can take, changing contextually to expose the most common functions and reduce the need to hunt through menus.
  • OEM skins like Sense and Blur are not going away. Honeycomb will be open source like every other release of Android, and he “hopes partners will feel comfortable re-skinning it and adding value. … We want to craft a really solid basic platform for everybody to innovate on top of.”

Those are just the highlights– the interview is full of interesting stuff about Android and UI design in general. Watch it below and head on over to Engadget for their take on it.

[viddler id=e1968407&w=437&h=266]



  • http://www.ashersimonds.com Asher S. (Vazguard)

    I watched this video this weekend and it was great to see Google putting “suggestive” control back into Android. I’m sure many remember that stack picture of 8 or so devices’ button layouts – most of them used a different order. This, while small in the overall process, can make transitioning from one Android phone to another a little difficult.

    Google’s inclusion of software buttons by default gives Android a base control scheme that is constant regardless of platform (that is, if OEMs decide to use it). Many firms might simply decide it isn’t worth their time to develop new control schemes, which can benefit users. Google still gives the hardware developers plenty of options, as Duarte said in the interview, but I think by establishing a software standard for controls Google is hinting to its partners that the current array of mobile button schemes is detrimental to users.

    What do you all think?

  • derek p

    its like hes encouraging android fragmentation?

  • EU

    @ derek p: fragmentation or differentiation? as far as i know, the OEM UIs may look different but apps will work the same on all of them. fragmentation only comes into play when apps work on some iterations of Android and not on others.

  • http://twitter.com/velazcod velazcod

    The problem with said “skins” and custom UIs, is not about the looks only.

    The problem is mainly when they modify the framework, and make developers have to modify their apps so they work on said custom skins and shit. I as a developer, do not care about the skins, they could be blue and yellow with gray widgets for all I care, but do not modify unnecessary things that break APIs…

    For example, on Sense UI, the field screenBrightness in WindowManager.LayoutParams is broken if the phone’s autoBrightness is active. On stock android, it automatically overrides auto brightness and allows the app to set it’s own brightness. On Sense, it won’t do that… you would have to manually deactivate autoBrightness in your app, set the custom brightness using the field above, and then activate autoBrightness again.

    On the Droid X, the buttonBrightness field in WindowManager.LayoutParams is also broken. The keyboard buttons do not go off if you trigger it with that field. It works on other phones, including those with hardware keyboards, why not on the DX? Oh… yeah, Motorola wasn’t paying attention to the APIs when they were working on it… THAT IS THE BIG PROBLEM.

    That is one stupid thing, but it’s one I can remember now and I have found many many others. I hate that it works fine on stock android, when many developers use stock Android devices like the Nexus One for development, then these phones with custom skins and shit break things up and users complain….