The Purpose of the Ubiquity experiment

Ubiquity is really two experiments in one.

Pseudo-Natural Language

The first is an attempt to build a practical, learnable, efficient user-interface using pseudo-natural-language parsing. Parsing and understanding the semantics of natural language in the general case is extremely difficult, maybe even impossible, and IMHO best left to academic A.I. researchers. But maybe it's possible to make an interface which is similar enough to a limited subset of natural language that the user's linguistic instincts will make it easier to learn and use. That's what we're exploring.

Verbing the web

The second experiment has to do with the "verbification" of the web. Traditionally the web has been made of "locations", i.e. pages, that you "go" to using a browser. But as more and more of those locations become interactive and offer useful services, maybe it makes more sense to treat those services as things you can "pick up" and "take with you" to use elsewhere, instead of treating them as locations. These chunks of code become commands, the "verbs" of the web, as opposed to the "nouns" that are content-oriented websites.

Security plus generativity

To make this work, we need to solve the problems of how discrete chunks of code can be written and shared (as easily as web pages can) in a way that offers protection from malicious code without sacrificing generativity. Security and generativity are often at odds (c.f. "The Future of the Internet and How to Stop It" by Jonathan Zittrain) so to resolve the paradox we explore new and untested security models such as the proposed "web of trust". If we can find something that works, it could be applied to many other projects as well.

The benefit for the user is efficiency

Natural language and generativity are of interest mainly to developers. For the end-user, the benefit of installing Ubiquity is that it gives a faster way to do common web tasks. With the appropriate command installed, you can accomplish something by simply selecting text on a page and invoking a command, as opposed to copying text, going to a different website, pasting it into a form, etc. For all of the complexity going on under the surface, this efficiency boost is the reason people use Ubiquity. To drive more uptake, we should look for more opportunities to write commands that streamline repetitive tasks.

Although there are a nearly infinite number of cool new features that can be proposed for Ubiquity, we should try to stay focused on these three areas: natural language interface, verbifying the web, and increasing the efficiency of the user's internet tasks. Things that aren't closely related to one of these should be considered out-of-scope for the project.

Planned Upcoming Releases

Ubiquity 0.5: The New Parser

The big news here is the new parser, which supports internationalization. We took everything we learned from writing the original parser and used it to create a much more robust and expandable basis for future development of multiple-language pseudo-natural-language input.

Second biggest news is the new interactive tutorial. User testing showed we had a desperate need for a better first-run experience, so we created a walkthrough that takes new users by the hand and teaches them the basic concepts along with a handful of the most useful commands.

Release date: June 22 (or 23rd if we're following the tuesday-publicity theory), timed to coincide with release of Firefox 3.5. (Update: We released 0.5pre, a still-buggy preview edition, on June 22. We will release 0.5 for real, with no new features but lots of bug fixes, on June 30.)

Must support both Firefox 3.0 and 3.5.

Major new features:

• Parser version 2, which supports internationalization
• More consistent naming of standard feed commands, with no more hyphens
• New interactive tutorial
• better organized web/help content
• improved asynchronous noun suggestions
• Supports multiple languages: English, Japanese, and Danish at launch; more later.

Community building after 0.5:

• New command developer documentation
• Series of videos promoting new features that 0.5 offers to command developers and encouraging command developers to update their feeds to the new format.
• Educate command developers on locked-down feeds, encourage them to use locked-down feeds whenever possible and standard feeds only when absolutely neccessary.
• Human interface guidelines for command developers, to encourage consistency of interface between commands.
• Outreach to localization community, to solicit the help of localizers to get Ubiquity working in more languages.

Server-Side Improvements

There are three server side components to Ubiquity:

1. The command search engine ("The Herd")
2. The bug-reporting system
3. The developer support infrastructure, e.g. Hg and Trac, that run on ubiquity.mozilla.com.

All three of these have been experiencing major availability and/or performance problems. The lack of usable uptime is really starting to hold us back. As soon as 0.5 is released, we need to focus on making all three of these server-side components stable and reliable enough to support our plans for growth of the user and developer communities.

Ubiquity 0.5.1

Less than 2 weeks after the release of 0.5

Fixing high priority bugs found by the release of Ubiquity 0.5.

Ubiquity 0.5.2

Beginning of Q3, 2009

A few features that didn't make it into 0.5, along with fixes for whatever the biggest bugs are that we discover after 0.5. Notable features (which are almost done, but didn't get in to 0.5 before feature freeze) are:

• Provider plugin arguments
• Suggestion memory in parser 2

Ubiquity 0.6: Push for more End-User Benefits

Mid Q3, 2009

After the deep infrastructure work of 0.5, we need to focus on turning the new power of the platform into tangible benefits for the end-user. That means improving the implementation of the standard feed commands (and, equally importantly, their nountypes) for better stability and functionality, plus expanding the range of commands available, and attempting to expand the size of our user base.

Around this time, the Test Pilot project will have produced a usable set of policy guidelines for collecting data without compromising user privacy. These guidelines will be implemented in 0.6 so that we can start collecting usage data that we can use to scientifically improve the usability of Ubiquity from here on.

• Instrument Ubiquity for data collection according to Test Pilot standards.
• Improvements to standard feed commands and their documentation; more new commands.
• New and better default skin; Better graphics for user interface.
• User-defined command synonyms/aliases.
• Make nountypes localizable.
• Suggestion memory improved to cover noun suggestions
• Experiment with doing noun recognition in the cloud

Community Building after 0.6

We should come up with metrics to estimate the size of our user base, and set targets for the number of users we would like to have. With the higher quality of the standard commands that will be emphasized in 0.6, it will be easier to reach new users.

Increasing our user base will increase our command developer base as well as our command subscriber base, and allow us to make more realistic explorations of the scaling effects that start to affect security and trust when the network grows past critical mass. For instance, I am not aware of anyone having yet attempted to write a malicious Ubiquity command. I'm sure this is mostly because the user base is too small to be worth targeting. As the user base grows, it becomes inevitable that someone will attempt to attack our users using a malicious command. Thus, growing the community is an opportunity to test out the web-of-trust security model.

We should take a hint from the "Extend Firefox" contests and run a contest to write the best Ubiquity command -- the most useful, most innovative, and best implemented commands that conform to our security and human interface guidelines will be rewarded with publicity and swag.

Separately from any contests, we should also have a spot on the Herd / command-search front page for "Featured Commands". This can be a short, rotating list of commands that we have reviewed for security and usability and found highly useful and worthy of recommendation.

The Herd ought to offer a feature where users can give thumbs-up or thumbs-down to commands, and then view commands ranked by number of thumbs.

Good, popular third-party commands can also be considered for inclusion into future versions of the standard feeds. (But inclusion in standard feeds will never be offered as a prize for any contest; that goes against Mozilla's policies.)

Ubiquity 0.6.1

A few features that didn't make it into 0.6, along with fixes for whatever the biggest bugs are that we discover after 0.6.

Ubiquity 0.7: The Web-of-Trust Security Model

Late Q3, 2009

Because of the growing user population, this release will need to focus on security. With the growing user population, sooner or later someone will start writing malicious Ubiquity commands. We will try to combat this by using the power of networked users for good instead of evil. Our longstanding plans for a "web of trust" security model will require several improvements to the infrastructure of command subscription. First, Ubiquity will need to know who your friends are, so that it can see what commands your friends have recommended subscribing to, and what commands they've recommended avoiding.

Second, commands will no longer be able to have direct access to third-party servers through XHRs, or to the XPCOM components in the Mozilla platform. Instead, they will have to make API calls through a security layer. This security layer will identify exactly what permissions a command is requesting, so that when a user subscribes to it, Ubiquity can tell that user in a plain, human-readable way exactly what is being requested: "This command wants permission to write to your filesystem", for instance, or "This command wants to contact the site www.sendmealotofspam.com."

The security layer will make it so that users know what questions are being asked of them by a command install (which will be a big step up from the scary red screen with javascript source code); the web of trust, with recommendations from your friends, will help users decide sensible answers to these questions.

• The web-of trust: Ubiquity becomes aware of your friends and includes a system for giving feedback on commands.
• The security layer: commands get access to third-party XHRs, XPCOM components, etc. only through security-aware proxy object.
• Distributed localization infrastructure: User A should be able to subscribe to User B's localization of User C's command feed, so that localizations don't need to be centralized (bottlenecked) in the Ubiquity team.
• More locales supported, more and better built-in commands

Ubiquity 0.7.1

A few features that didn't make it into 0.7, along with fixes for whatever the biggest bugs are that we discover after 0.7.

Ubiquity 0.8: User-interface experimentation

Q4, 2009

This release will focus on opening up the Ubiquity user-interface to more experimentation.

By rebuilding Ubiquity on top of Jetpack, so that Ubiquity and Jetpack share a common runtime, we will not only make debugging of Ubiquity much easier; we will also be able to expose the library of installed Ubiquity commands through a Jetpack API, so that others can write new interfaces to take advantage of these commands.

• Ubiquity built to run on Jetpack
• Commands exposed through Jetpack
• Experimentation with different UI, such as always-on input field, or mouse-based UI.
• Command chaining, AKA pipes between commands
• Solve whatever are the most pressing usability problems discovered through Test Pilot data collection
• More locales supported, more and better built-in commands

Ubiquity 1.0: A product ready for mainstream use

Q1, 2010

This release will focus on polish. It will not have any major new features beyond 0.8, but before a release is worthy of being called 1.0 it must be much more solid than any release we have made thus far. The built-in commands and nountypes, the security model, the user interface, and the parser must all be clean and reliable, and all remaining major bugs must be fixed.

Beyond 1.0:

Experiments in these areas can be done beyond 1.0 if there are sufficient developer resources, but they are outside the core project goals.

• Weave integration
• Thunderbird integration
• Bespin integration