Ubiquity In Depth

Advertisement:

POWERED by FUSION

An experiment into connecting the Web with language.

Ubiquity is an experiment two parts. It’s both an interface and a development platform. Ubiquity 0.1 focuses on the platform aspects, while beginning to explore language-driven methods of controlling the browser.

Read about the release here, or download it.

In this post, we’ll talk first about the interface, and then the platform. For those who are really impatient, and just want to see how the prototype version works, check out all of the pretty screenshots and use-cases in the Ubiquity Tutorial.

The Problem: The Web is Disconnected

You’re writing an email to invite a friend to meet at a local San Francisco restaurant that neither of you has been to.  You’d like to include a map. Today, this involves the disjointed tasks of message composition on a web-mail service, mapping the address on a map site, searching for reviews on the restaurant on a search engine, and finally copying all links into the message being composed.  This familiar sequence is an awful lot of clicking, typing, searching, copying, and pasting in order to do a very simple task.  And you haven’t even really sent a map or useful reviews—only links to them.

This kind of clunky, time-consuming interaction is common on the Web. Mashups help in some cases but they are static, require Web development skills, and are largely site-centric rather than user-centric.

It’s even worse on mobile devices, where limited capability and fidelity makes this onerous or nearly impossible.

Most people do not have an easy way to manage the vast resources of the Web to simplify their task at hand. For the most part they are left trundling between web sites, performing common tasks resulting in frustration and wasted time.

A Solution: Universal Access

Ubiquity’s interface goal is to enable the user to instruct the browser (by typing, speaking, using language) what they want to do. The end goal is something like this:

We aren’t there yet. Instead, we have the rudimentary systems of structured natural language commands. You can select something and Ubiq “translate this to French”, or “email it to Jono”. In both cases, Ubiquity is smart enough to realize what “this” and “it” refers to, as well as knowing who Jono is (by talking with my web-mail’s contact list). It’s also smart enough to be able to understand commands like “map Chicago Comics” and “yelp Tapas near SF” and give you rich previews and search results to get you where you want to be quickly. Even better, both of those commands let you insert results directly into, say, an email you’re writing so that you never have to interrupt your chain of thought.

There’s a long way to go with this interface, though. We aren’t even prioritizing the command suggestions we give. The interface looks messy and is visually cluttered. We have made the ultimate faux pas of putting hyphens into what should be natural language commands. It’s hard to know what you can and can’t type. It’s certainly something I don’t think everyday users would be comfortable with. Yet kernel of the idea is right. It needs thought and a lot of refinement. We’ll need your help to shape the future in the web.

A big direction that we know we are going to move is suggestions based on data-type recognition. We should be able to select an address and Ubiquity should then suggest commands that make sense to apply to an address (like map it, get directions there, find restaurants near there, etc.). Similarly, we should be able to select a phone number and prompt actions like “call”, a time and date should prompt actions like “add to calendar”.

Although this starts to move into the into the direction of talking about the platform, the language-based method isn’t the only way of connecting the web. For example, Ubiquity also provides a context menu to access functionality. You can easily select some text, right click, and translate. Or put it on a map. Or look it up on Ebay.

The point is not that the context-menu is a great way of exposing functionality. It isn’t. The point is that with the Ubiquity platform, it is easy to expose functionality in a variety of ways. Given modular functionality, we are given a great expressiveness in how let users harness its power. Again, thinking of new types of interaction — universally available functionality — is where we need help.

The Problem: Extending the Browser is Too Hard

Being relatively new to the Mozilla world, we found it difficult and time-consuming to write extensions to Firefox. There is something largely last-decade about requiring restarts to add a new feature to your browsing experience. It’s ironic that the entire Web is on a push model, yet the browser—the most fundamental tool of interacting with the Web—is on a pull model.

The fundamental problem is that extending the browser, and hence the web, is too difficult. The closer new browser functionality can be packaged to look like standard HTML and JS, the larger and more diverse a community will create it. The desktop paradigm for extension development, while powerful, has a high cost of adoption. Right now we have a short tail of browser functionality with thousands of add-ons. There should be millions. We can get to that long tail using a more web-like model for functionality development — tools that are accessible to hobbyists and tinkerers, but that scales to professionals.

A Solution: The Ubiquity Platform

Ubiquity treats extending the browser like writing websites. It’s an experiment in lowering the barrier to fundendemental enhancing the browsing experiment.

We’ve tried to factor out all the boilerplate code into the Ubiquity core, so that writing a useful Ubiquity command is as simple as this:

CmdUtils.CreateCommand({
  name: "tinyurl",
  takes: {"url to shorten": noun_arb_text},
  preview: "Replaces the selected URL with a TinyUrl.",
  execute: function( urlToShorten ) {
    var baseUrl = "http://tinyurl.com/api-create.php";
    var params = {url: urlToShorten.text};
    jQuery.get( baseUrl, params, function( tinyUrl ) {
      CmdUtils.setTextSelection( tinyUrl );
    })
  }
})

or this

CmdUtils.CreateCommand({
  name: "insert-email",
  takes: {"person": noun_type_contact},
  preview: "Inserts an email address, by name, form your contact list.",
  execute: function( email ) {
    CmdUtils.setSelection( email.text );
  }
})

You can learn how to write commands in the Ubiquity Author Tutorial. The command development API is not carved in stone; we’re hoping to get your feedback on how to make it even more convenient. Once you’ve written a command, sharing it is as easy as putting up a web page. For the end user, getting that command is as easy as bookmarking. No downloads and no clunky updates mechanism. The hope is to empower content providers with ways of bettering the web as a whole. To empower innovation at the edges.

If you have a web-application or website that provides a service, you can easily write a small amount of JavaScript glue to expose your functionality thorugh a Ubiquity command.  Ubiquity can help you extend the reach of your service beyond the bounds of your domain to find more users in the wider Web world. Ubiquity increases the surface area of innovation for the browser many-fold, by making anyone who can write simple Javascript into an agent for bettering the browser and the open Web. You are one of those agents.

If you do write any commands, please add them to the wiki-based command repository. You can also look for them on the opt-in statistics dashboard.

Get Involved

We are a virtual lab, so there are many ways to join the team to get involved:

About this entry

You’re currently reading “Ubiquity In Depth,” an entry on Aza’s Thoughts

Published:
8.26.08 / 2pm
Category:
WEBLOG