Last week I recorded this video for the students at a university in India, who requested an update on Mozilla Labs projects.

It’s about 20 minutes of me showing screens and talking about Ubiquity, Weave, Jetpack, and Test Pilot. Jetpack and Test Pilot are relatively new so I explain what they’re all about; for older projects Weave and Ubiquity I just highlight a couple of new features.

Thanks to Asa Dotzler for doing the video recording and editing.

You can watch the video on Air Mozilla in either Ogg or mp4 format:

Here is a three-dimensional version of the Ubiquibot logo, based on Sebastiaan de With’s icon design.

ubiquibot

I made it out of styrofoam and paint in a burst of inspiration one Sunday afternoon. It’s my new desk mascot.

More importantly, I wanted to share the link to the Ubiquity roadmap that I wrote. It lays out the big picture of our plans for Ubiquity development and what I think should be the key features and approximate release dates for each version from 0.5 through 1.0.

It’s just a proposal; it’s not set in stone. In fact, quite the opposite of stone: it’s on a public wiki, so everyone is free to edit it. Go ahead; give it a read, and if you find a key feature that I’m missing, or you think a certain thing needs to come much earlier or much later, please leave a comment on the Discussion page, or here on this blog, or just go ahead and add something directly into the roadmap wiki page itself.

Something that I am trying to combat with this roadmap is the dread specter of Scope Creep. The thing about Ubiquity is that it’s such a general-purpose platform… tool… interface… thingy that it’s easy to think of a hundred different directions in which it could be extended. I would love to have a version of Ubiquity that was voice activated, could launch external applications, ran on my cell phone, supported Opera and Google Chrome, and accepted input in the form of questions as well as commands! But we simply don’t have the developer resources to go chasing after every cool feature. If we tried, we would lose sight of the core mission. Some tough choices are in order.

That’s why, at the start of the roadmap, I laid out the three goals that I see as core to the Ubiquity project. Those are:

  1. Experimentation with natural language input
  2. The “verbification” of the Web (making command functionality as easy to share as web pages)
  3. Saving users time on their frequently-performed Web tasks

If it’s not tightly related to one of these three things, then as cool as a proposed feature might be, I think it’s out of scope.

That doesn’t mean that we’ll never work on stuff like voice input, or making Ubiquity run in Thunderbird. (In fact, we’ve already done some experiments in those areas.) I’m just saying that when developer time is limited, those things have to come second to the core goals.

What do you think?

If I haven’t blogged much here lately, it’s because I’ve had my nose to the grindstone — along with the rest of the Ubiquity team, including our insanely dedicated volunteers — on getting the next version, 0.5, released.

Well, yesterday we released a preview version, 0.5pre. It is still somewhat buggy; we’re going to spend the next week fixing the biggest bugs and then release 0.5 for real on Tuesday, June 30.

The biggest news in Ubiquity 0.5 is that it finally supports multiple languages. At release, we have Japanese and Danish supported in addition to English; the infrastructure is in place to add more languages as rapidly as we can recruit volunteer translators.

I celebrated the first release of a Japanese Ubiquity by wearing my happi and geta to the Mozilla meeting on Monday:

ubiquity_japanese

(The headband says: 合格 (goukaku), which means to pass a test. Japanese students wear them when studying for exams. In this context, let’s just say it refers to unit tests.)

I may be wrong, but I think that Ubiquity may be the first truly global attempt at a natural-language interface, as opposed to one which targets only a single language. Does anyone reading this know of any other similar experiments? If you do, please leave me a comment — I would love to know about what other work has been done in this field.

I have already written a bunch about Ubiquity 0.5 elsewhere, so rather than repeat myself, let me just link you to the appropriate places:

I do want to talk a little more about the fact that we changed the command API. This change meant breaking commands written for older versions of Ubiquity, something I am loath to do without very good reason. But the old API was holding us back: it wasn’t extensible enough, it couldn’t support localization, and it was getting in the way of defining sane and consistent naming standards. Since our original hacky prototype, we have gained so much knowledge (about what the parser and the command API realistically need to support) that a fresh start was in order.

Since breaking backwards compatibility has a high cost, we don’t want to have to do it ever again. We tried our best to look ahead at everything that would make us change the API — and concentrate all of those changes in this one single revision, so that there is just a single “breaks everything” release rather than three or four consecutive “breaks everything” releases.

Updating commands to work with the new API is fairly easy. It mostly has to do with how your command declares arguments. If your command doesn’t take any arguments, then you don’t have to do anything. Full instructions are here: Command Conversion Tutorial. The same page also explains how to ensure that your commands are localizable.

I’ve written before about how Ubiquity needs a better experience for new users and how our marketing doesn’t communicate what Ubiquity is. So, I’m spending a couple of days re-writing the about:ubiquity pages and making a new tutorial.

Until now, the top of the about:ubiquity page has said:

UBIQUITY: AN EXPERIMENT IN CONNECTING THE WEB WITH LANGUAGE

It sounds vague, cumbersome, and academic, and it doesn’t help a user understand what Ubiquity is for. I was trying to think of a replacement, and I typed:

UBIQUITY: DON’T SURF THE WEB. COMMAND IT.

What do you guys think of that as a slogan? Anybody with marketing experience want to comment?

Speaking of marketing that better explains what Ubiquity does, student contributor Zac Lym has made a really cool Ubiquity ad concept video. I’ve gotten used to taking Ubiquity for granted, but watching this video makes me excited about it again.

WordPress tells me that the fourth most common search string that leads people to this site is “changing ubiquity starting keystrokes”. Huh. That’s interesting. The fact that it’s such a common question probably means that the feature is too hard to discover. But as long as people are asking it, maybe this site should, you know, answer it or something.

Do the “Help” command in Ubiquity. A page will open; in the upper-left corner of this page there is a widget for setting they keystroke combination that activates Ubiquity.

If you can’t bring Ubiquity up, because its default keystroke combination doesn’t work on your computer for whatever reason, then you can get to the same page by typing about:ubiquity into your URL bar.

Hope that helps.

Since the fall quarter of last year, HCI student and Ubiquity community contributor Zac Lym has been doing good work testing Ubiquity on new users. Although the study included only a small number of users, it’s an important one since it’s the first and only rigorously derived usability data we have on Ubiquity. The users in this study had no prior exposure to or preconceptions about the Ubiquity interface, and the experimenter gave them no help using it; so the problems and frustrations they encounter give us insight about the specific areas where Ubiquity needs improvement in discoverability and learnability.

The primary material resulting from the research is a series of videos of users in action. Zac has made these videos available on the Mozilla wiki along with write-ups of his methodology and his findings. These findings are well worth reading in full for anyone interested in improving the Ubiquity user experience.

(more…)

This photo has nothing to do with the article.  I just thought the blog needs more pictures.

This photo has nothing to do with the article. I just thought the blog needs more pictures.

Last night was Labs Night, a kind of show-and-tell (with pizza) that we do here once a month, open to the public. We encourage people from outside Mozilla to attend and give presentations on their own projects.

Last night was especially rewarding because we had two such community presentations. One was from Edwin Khodabakchian of Feedly, a Firefox extension which “weaves your favorite content into a magazine-like start page”. The Feedly team has developed a set of Ubiquity commands to act as a command-line interface to Feedly, which is pretty cool.

The second was from Guillaume and Sebastian, the Paris-based creators of Play!, a Java web-application framework. Among other things, they demonstrated how they’d written a bridge between Play and Bespin so that they could edit source files in Bespin and see the results of the changes instantly on the same server.

So it just so happened that both projects presented had done cool things by building upon or integrating a Mozilla Labs project in some way. It’s extremely gratifying, not to mention flattering, to see our work used in this way. Because that’s what open source is all about (well, one of the things): The ability for all of us to build on each other’s code.

Over at his blog, Mitcho has some very sharp thoughts about localizing Ubiquity to verb-final languages such as Japanese.

I talked about similar localization issues several months ago, but Mitcho takes it further than I did. He says:

In a verb-final language, however, you enter the arguments first and then the verb, making this strategy of suggesting appropriate arguments impossible.

Instead of seeing this as a disadvantage, however, let’s see what verb-final order allows us to do.

That’s the spirit!

He goes on to talk about analyzing the arguments, which are entered first, and using them to suggest a verb. I think this is exactly the right idea.

I’ve just got one thing to add: Ubiquity already does some very rudimentary suggestion of verbs based on having the nouns first. This is how we handle the case where the user selects some text and then pops up the command line — we suggest verbs based on the noun types that produce a positive match to the selection. It’s very basic right now, and could be a lot better.

The good news is that we can take the algorithm that suggests verbs based on the selection, and apply it to Mitcho’s idea of suggestions in verb-final languages. Any improvements we make in one will be applicable to the other, and vice versa. Working on the noun-first suggestion algorithms helps everybody!

Khoi Vinh has a good critique of our Ubiquity “marketing” strategy, here: Subtraction 7.1: Marketing in a Minute.

Quoth Khoi Vinh:

While I have great faith in Aza and his team’s talent, and while I’m pretty sure that the product itself is almost certainly worthwhile, I have to be honest: I have no idea what it does. As of this writing, I lack a clear understanding of its function or purpose. This is largely because, though I’ve come across references to it many times, the marketing hasn’t worked for me.

He’s got a point! The main Ubiquity project page does not clearly describe what Ubiquity does. When I try to block out my existing knowledge and read that page with fresh eyes, it sounds like some magical vaporware project that will be all things to all people, cure cancer, and make julienne fries.

(more…)

Next Page »