Today, Mozilla Labs announced yet another new product to add to its long list of experiments and prototypes. First things first — let us pray that this experiment will fare better than its predecessors (Weave and The Coop, I’m looking at you…).
With that out of the way, let us examine precisely what it is that we so fervently wish to preserve.
To hear Aza Raskin of Mozilla explain it, you would fall under the impression that Ubiquity is essentially a dream, and that dream is to make natural language processing a reality in the context of bringing web mashups to the masses. The following ultimate example goal sums the project up fairly well:
Book a flight to Boston next Monday to Thursday, no red-eyes, the cheapest. Then email my Boston friends the itinerary, and add it to my calendar.
To which the system responds:
Leaving from SF to Chicago on March 20th at 9am. Returning on March 24th at 7pm. Itinerary will be sent to Andrew, Margaret, and Josh.
Elegant, efficient, and if done right, revolutionary. Essentially, Mozilla Labs wants to make that old Apple Newton web ad a reality.
However, the current prototype does not reflect this goal. Instead, it exists today as a launcher, a necessary menagerie of smaller plugins which connect to various different web applications and services, the composite whole of which may yet someday form this natural language beast that Aza and his team have envisioned. This shouldn’t faze anyone, however — in fact, I’m actually here to argue that the prototype is brilliant as is. First, some background.
Inarguably the most powerful utility on Mac OS X is Quicksilver. To most people, Quicksilver is simply a faster alternative to Spotlight for application launching purposes: if you need to load Word, just hit Ctrl+Spacebar to pop up Quicksilver, type “Word”, and hit enter. Much faster than going to the dock, and definitely better than the half second lag that Spotlight suffers from for the identical operation. However, Quicksilver is much more powerful than that, and represents in fact an entire philosophy, which creator Nicholas Jitkoff once detailed in a Google Tech Talk.
In the standard operating system shell paradigm, the goal of the OS browsing interface is to get you to the application. From there, you’re on your own. Thus, browsing the filesystem is the key and the model on top of which most operating system shell interfaces are developed — Windows Explorer, Nautilus, Finder, etc are all designed to let you browse through your hierarchy of files and eventually select a file or application to execute.
The key philosophy behind Quicksilver is that this barrier is an artifical construction, one that need not exist. Sure, Quicksilver will let you browse the filesystem and launch applications faster than anything else on the market, but the real beauty behind Quicksilver is how it lets you step past the filesystem. There is no need, for instance, to stop once you reach “iTunes.app” — you can, within Quicksilver, navigate straight into iTunes and browse your Library as if it iTunes were merely a folder and you were still browsing the filesystem. This far-reaching mentality is what makes Quicksilver truly powerful and flexible, and is where most power users spend their time with the utility.
The filesystem-application barrier is artificial and need not exist.
Now, let us at last take a look at the current incarnation of Ubiquity. As demonstrated in the screencast, the plugin is currently essentially a launchbar, from which contextual actions may be launched. You can, for instance, highlight an address, call Ubiquity, and tell it to “map,” which will not only load Google Maps, but let you drop it into an email you’re writing. Similar functionality exists to find things on Yelp and other web services. It also lets you do things, such as highlight foreign language text within a page and ask Ubiquity to translate it in-line, TinyURL a URL, or tweet about things that you see around the web.
Thus, I would argue that Ubiquity is currently Quicksilver for the web. And perhaps it wouldn’t be so bad to keep it that way. Essentially, Ubiquity allows Firefox to become more than a web browser, in a nonobtrusive way: it becomes an active component of the web. You can execute actions on any webpage through the browser to any supported web service.
Essentially then, the core philosophy [at the moment] is that the browser/URL-web application/services barrier is artificial and need not exist.
Ubiquity is tons of fun to play around with, and will probably become a core part of my Firefox experience before long. But does it need to be anything more? Quicksilver for the web is already an ambitious goal, and while natural language programming would be nice, this set of features and this paradigm is here now. And I think the web is ready for it.