Is it just me, or do most dialogs on Android seem to be removed really, really far away from the main parts of applications?
Not sure what I’m talking about?
Let’s take a look at the browser, for example. Just entering a new URL requires you to go through 3 different screens:
By the time you can start typing it feels like you’re already in a different application1. Switching to a different window also involves going to a special part of the application designed to handle this single task.
This pattern is not limited just to the browser. Entering an address in the maps application or searching the list of your contacts also involves going through several steps.
Back to the browser…
If you take a look the UI of a regular browser you can immediately see a number of frequently used elements such as the location bar, the back button and tabs for switching between windows. Those UI elements are always visible and usable with a single click. On mobile devices things are a bit different. Because of limited screen sizes most of browser’s UI is either eating away precious screen real estate (like on the iPhone) or is hidden behind a menu button (like on Android).
Except that because of the nature of menus, many of those features are not hidden just behind the menu button, but also behind an item on that menu.
Now, just as I’m typing this, Marissa Mayer is on the stage at TechCrunch50 introducing Google fast flip and talking about how Google is obsessed with speed and shaving milliseconds off of repetitive interactions. So what can can we do to speed up interaction with Google’s mobile browser?
First, we need to understand what’s wrong with menus.
A typical menu is a list of actions available for that application, but most of those actions can’t be performed from the menu itself. Instead, selecting an item takes you somewhere else where that action can finally be performed. In essence, a menu keeps asking the question “What do you want to do?” over and over again and the user then needs to explicitly say that he wants to go to to the place where he can type in an URL or go to the place where he can switch to a different window, etc.
How do we handle this situation where we know that in many applications the user’s answer to the menu’s question is going to be the same most of the time?
Like it is the case usually these days, the solution can already be found on the iPhone. No real surprise there. The iPhone doesn’t have built-in support for application menus which could be copied, but it does have this:
What you’re looking at is a special dashboard for controlling music playback, which can be brought up by pressing the home button twice.
With a bit of bad luck – or bad judgment – this could have easily been implemented as a list of items such as “adjust volume” and “control playback”, with each of them leading to a new screen where that action could be performed. But instead its designers made it possible to perform common actions directly from the pop-up and added a “Music” button that takes you to that other app where the rest of the playback controls are.
So let’s take this dashboard pattern and apply it to Android’s browser menu:
While some features (like bookmarks) still remain hidden behind a menu button, the two most commonly used ones are immediately presented in usable form. The “go” button is replaced by an actual location bar and the “Windows” button is replaced by thumbnails of windows. You now no longer need to announce first that you want to go to a different page or switch to a different tab; you can perform that action directly instead.
A quick before/after comparison:
| Action | Before | After |
| Loading a web page | press “menu” → press “go” → focus URL field (3 steps) | press “menu” → focus URL field (2 steps) |
| Switching to a different window | press “menu” → press “tabs” → select tab (3 steps) | press “menu” → select tab (2 steps) |
Removing a single step here and there may not seem like much, but it adds up. Making a typo in the URL or working with several windows suddenly becomes just a little bit less frustrating. A simple improvement that can be achieved simply by ignoring the established meaning of the word “menu”.
- Sure, if you have a phone with a physical keyboard you can just start typing and invoke the default action without going through menus, but what if your phone uses an onscreen keyboard or if you want to use some other action? ↩
Related posts:
I like your idea. Perhaps the next step is to get hacking the Android and show it in action?
An excellent idea; I’d love to see that. When can you start? ;-)
Great idea and mockup. A few design challenges remain, though:
- How do you handle vertical view? Two rows of buttons? Vertical thumbnails?
- How do you handle many windows (and thus many clickable thumbnails)?
By the way, my HTC Hero’s browser is doing what you describe, safe for one thing: there are no preview of the windows (you still need to click one of the menu options, which thankfully is one of the directly visible options).
I do have a URL bar that pops up on top of the screen when i hit the menu key, while the buttons (back, forward, new bookmarks, bookmarks, windows, more…) are displayed on the bottom. I’m not sure if this is HTC-specific.
Thanks for raising those questions, Florent.
1. In vertical view the buttons would either be smaller or in 2 rows. Thumbnails would of course be vertical because in that case all web pages would be rendered in vertical orientation to begin with.
2. With many thumbnails it would probably be best to implement some kind of sideways scrolling to see more of them.
It is obvious that this needs a lot more work. It wasn’t meant as a final solution; I just wanted to get out there the idea on how to get rid of some extra steps. :)
@Florent: I just downloaded Android 2.0 / Eclair SDK and it looks like the improved HTC Hero’s URL bar you write about has made it into Google’s Android builds.