Ouch!

“Mozilla Ubiquity dies an incredibly quiet death”

|:-/

 

Quick update on Ubiquity and Firefox 3.6

In this post I promised a new release of Ubiquity to be compatible with Firefox 3.6. It’s been a while so I thought I should update you on that.

The situation is a little complicated, because there are two “branches” of Ubiquity development: the 0.1 line and the 0.5 line, which differs significantly.

We’ve released an update to the 0.1 line, Ubiquity 0.1.9.1, which works with Firefox 3.6. It can be downloaded from Addons.mozilla.com.

The Ubiquity 0.5 codeline is turning out to be more difficult to update to Firefox 3.6 than we anticipated. (i.e. there are actual incompatibilities that produce parser problems; we can’t just tweak install.rdf and release.) We’re going to have to find some time to do some serious hacking and bug-fixing on it before we can release a compatible 0.5.x version.

Ultimately, I’d prefer to re-merge the codelines and have only a single version; having 2 is confusing and there’s no real reason for it.

But for now, at least you can use Ubiquity 0.1.9.1 on Firefox 3.6.

 

What’s up with Ubiquity?

If you’ve been following Ubiquity, you know we haven’t made a new release of the extension since last summer. What’s going on?

Last October, Mozilla Labs got together and had a meeting about all the things we want to get done in 2010. It became clear that there were too many things on our plate, and we had to make some hard decisions. Ubiquity was one of the things that was put onto the back burner in order to focus better on Weave, Jetpack, Bespin, and other core projects.

Everybody I’ve talked to at Mozilla loves Ubiquity and would love to see it developed further — but all have agreed that the other projects are higher priority. Ubiquity remains an exciting experiment and I personally look forward to the time when I can work on it again. But for now I’m focused full time on Test Pilot.

Does this mean Ubiquity is dead? Not at all! It’s an open source project with a fairly large installed user base, and if you look at the Mercurial repository and the mailing list you can see that the community is still active fixing bugs and answering user’s questions. It’s clear that the Ubiquity community has taken on a life of its own and is capable of further development with or without direct involvement from Mozilla Corporation employees.

We’ll probably be releasing a new version of Ubiquity sometime soon, just for the sake of maintenance. The last released version isn’t compatible with Firefox 3.6, and the lack of compatibility is harming the many people who still use Ubiquity on a daily basis. Making it compatible should not be very difficult, since the “trunk” (the latest development code) is compatible with 3.6 to the best of my knowledge. So we just need to roll up a new release and get it out to people. We should be able to get that out this week or next week.

We’re also working on analyzing the first round of Ubiquity experimentation, so that we can figure out what to approach differently when we begin the second round. Yes, I’m pretty sure there will be a second round.) I’ve been writing up my thoughts on what we learned during the first round. It’s turned into quite a long essay. Not exactly a “post-mortem”, as that would imply the project is dead; call it a “retrospective”. Look for it within the next couple of days.

 

Labs Projects Update Video

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:

• Ogg
• mp4

 

Fighting scope creep in the Ubiquity roadmap. (Also: Ubiquibot)

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

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?

 

Ubiquity 0.5 preview release – at last, the international edition!

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:

(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:

• Here’s the Labs blog post about 0.5pre. It includes the credits for the main people who contributed to the release.
• Here’s where you can download the 0.5pre extension itself.
• Here’s the release notes that list everything that’s new in this version.

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.

 

A slogan idea

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?

 

Cool Ubiquity Ad Concept

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.

 

Changing Ubiquity Starting Keystrokes

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.

 

Ubiquity User Testing Reveals Desperate Need for Better First-Run Experience

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.