Bashing the Awesome Bar
A couple weeks ago, Daring Fireball posted this screenshot, adding the disclaimer that “this is not a joke.”
A total mess. A textbook example of bad UI design.
Right?
#The Space-Time Paradox
37 signals soon suggested that this wasn’t an example of bad design so much as it was design targeted to the repetitive requirements of active users. Ryan referred to Tufte’s notion of a tension between space and time (emphasis mine):
The trade-offs between elements adjacent in space versus stacked in time are always in the mind of a UI designer. Placing many elements on the same screen reduces the need for navigation and gives users a comprehensive feeling of “it’s all at my command.” Moving focus from one element to another is instant and seamless. On the flip side, separating elements onto different screens slows things down with navigation while increasing clarity. There is more room for explanation and luxurious space when fewer elements occupy the page. The eye has less to filter through. The course of action is more obvious.”
There is indeed a tension between space and time, between the simplicity-driven design at Apple Google, and Facebook, and the more expressive and efficient interfaces that the most active users almost always demand.
This tension is exacerbated in the emerging age of small screens and clumsy fingers, where simplicity and expressiveness are both required.
#The Blossom of Awesome
The Awesome Bar represents Mozilla Lab’s first step into a language-based interface for the point-and-click crowd. The best addition to Firefox 3, the Awesome Bar is stupid smart. It’s usefulness has blown away my expectations, admittedly modest at first.
It also provides some context for the discussion led by Jono DiCarlo on his site:
How should the ideal linguistic UI behave?
For ease of learning, it should:
* Accept input in something very close to the human language I’m already familiar with.
* Give me clues about what commands are available.
* Give me clues about what I can type next.
* Give me clues about what the current command will do if executed.
* Give me suggestions about other commands it thinks I might be looking for.
* Help me understand what ranges of arguments to a command are valid, and what the arguments mean.
* Propose commands appropriate to my working context or to the type of data I have selected.
For efficiency, it should:
* Allow the user to start with the noun or to start with the verb.
* Let me autocomplete a partial word with a keystroke.
* Recognize words even if they’re super-abbreviated.
* Remember what suggestions I’ve chosen in the past and pop them up next time I give the same input.
* Let me partially enter something, see the suggestions, choose one as mostly-right, and edit that one some more before executing it.
* Guess, from my context and my selection, what I want, and fill mostof it in for me, while letting me easily override it if it’s wrong.
For expressiveness, it should:
* Handle commands with multiple arguments, including optional arguments, that can take various data types.
* If I have data selected, let me use that selection as an input for any of the multiple arguments — or for none of them.
* Let me chain commands together, with the output of one going to the input of the next, like Unix pipes.
* If my input could mean more than one thing, give me a sensible way to resolve the ambiguity.
* Let me compose a complex command out of small parts, in the flexible way that natural language does.
* Let me save a complex command that I’ve created and give it a simple name so I can re-use it in the future.
* Give me an easy way to create my own commands — and to share them with others.
The language-based interface Jono describes isn’t just a feat of interface design, but could have explosive potential if hooked into web services - a bash console for the cloud.
Of course, Google arguably is already the console of the cloud. (Or http://goosh.org, my own home page). That’s why Mozilla should focus on incorporating the best elements of Google and improving on them with powerful new features:
Web Scripts - Translate my commands into just-on-time web service requests. Gmail example. such as XMPP subscriptions, or complex ‘shell scripts’ that are effectively local API clients. And the debugging possibilities for developers are massive, if the Firebug console is any indication of things to come.
Data Web Integration - For semantic web services looking for an edge on Google, the expressiveness of the Awesome Bash Bar may allow for a range between powerful query model precision and simple NLP intuitiveness. This is still in early stages, but one simple platform in this space could make a huge difference. I’d keep my eye on Yahoo, Microsoft (having just acquired Powerset), Freebase, and some stealth-stage startups such as Primal Fusion.
OS Integration - If the language-based interface is run on an iPhone, it should accept drag and drop icons to help form commands. In fact, small devices and big fingers will likely be the primary catalyst for the return of the language-based interface - and I’m surprised Jono hasn’t (multi)touched on this point.
And yet, these possibilities all pale in comparison to the most important vector explaining the imminent rise of the cloud console.
It’s really very simple - mobile devices designed primarily for a cloud console can be smaller, cheaper, and require much less energy.
Let me repeat that, one more time: smaller, cheaper, and require much less energy.
For instance, the iPhone normally has about 3.5 hours of juice. Booted into its shell mode, the device can be on for more than 10 hours without being recharged. It’s easy to imagine that by incorporating the best of both the GUI and console worlds, we could end up with a device that can run for at least 6 hours without a single hardware improvement.
In fact, if a truly easy and expressive language-based interface let even a tenth of the mobile device market use half as much energy, I wonder how much power would be saved over one year…
