(2010-01-20) Xia Retrospective What We Learned From Ubiquity

Jono Xia: Retrospective: What We Learned from the Ubiquity extension.

1. This crazy thing can work.

A command line for the web? Why would anybody want that?

Ubiquity at one point had around half a million active users

We proved that it is possible to square the circle: to create an interface that combines the speed and power of a command line with the learnability of a graphical interface. And we proved that this interface can be part of a new way of using the Web: a task-centric model of browsing where instead of going to a service, users bring the service to where they already are.

2. This crazy thing can be localized.

Difficulty of localization is sometimes raised as an objection to doing language-based interfaces. We proved that this difficulty can be overcome.

3. Having a quick and dirty way to add browser features is hot stuff

What, it just downloads remote Javascript and runs it with full privileges? Isn’t that a terrible idea?

But it turned out to have many advantages. Unlike extensions, Ubiquity commands let you add features to the browser without having to restart. You can make changes to your code, test them, and deploy them to users without anyone ever having to restart the browser. Additionally, the simpler command-centric, Javascript-and-HTML-based API was able to expose most of the powerful features in the Mozilla platform without most of the complexity involved in learning that platform.

The idea of the Ubiquity command subscription model was spun off into its own project: Mozilla Jetpack. Jetpack isn’t just an important project in its own right; it’s a crucial part of Mozilla’s future add-on development strategy.

4. The “hit a hotkey to bring up an overlay” interface suffers from lack of visibility, non-monotony

A radical redesign of the Ubiquity interface would be to have, not a hotkey-driven overlay, but a permanent, always-visible box into which you type commands. (There could still be a hotkey to focus input to this box, so using it would be just as fast.)

4. Nountypes are very powerful… but hard to get people to use well

Standardizing onto a system of arguments with defined types was a big win. Letting the parser handle assignment of arguments meant less work for command development.

Despite their crucial role in the system, nountypes were mostly invisible to Ubiquity users. This was a chronic problem, because it meant that many command developers remained unaware of functionality available in nountypes,

I think all these problems can be solved with better communication

5. Naming standards are important… and hard to impose once people get used to just naming their commands whatever.

6. Inputs are not just strings

it can also be a selection of part of a web page, including HTML formatting and images. It could conceivably be the output of a previous command, or even some form of multimedia. Treating inputs as structured data instead of just strings is a big win because it allows commands to be more flexible in what they do with the data, and allows multiple formats or views to be passed around as a single object.

7. Switching between mouse and keyboard sucks

8. Security is critical… or is it?

Jetpack has the same inherent security vulnerabilities as Ubiquity. The difference is that in Jetpack, they are being addressed.

9. Looking at a preview of command execution can be more useful than actually doing it

If their desire was only to see some information, the preview alone was enough.

10. “Killer App” commands drive adoption

It’s not the system (platform) that is valuable to users, it’s the individual commands

11. Users need to be able to find commands somehow

We had plans to write a command search engine, but they never quite came together

12. There are too many directions for Ubiquity to grow in; we can’t follow up on all of them.