Not The User's Fault

Firefox 3.5 is released today, representing almost a year’s worth of hard work and improvements over Firefox 3.0. Key features include faster Javascript, <audio> and <video< tags that allow media to play as part of a page with no plugins; and private browsing mode (Sing it with me: “The int-er-net is really really great…. for porn!”) Download Firefox 3.5, try it out, and spread the word!

This doesn’t have anything to do with Ubiquity or user-interface design, so it’s not really on-topic for this blog, but I thought I’d let you all know that I’m getting married tomorrow, to Sushu Xia! More info is on evilbrainjono.net, my personal blog.

After the wedding, I’ll be back at work for one week, then I’ll be gone on a honeymoon trip from July 4 – July 26 (and with minimal connectivity) for most of that time. So if you need anything from me, you’ll have to find me before I leave or after I come back.

Finally, Mitcho made this lovely wedding registry for us:
tinyurl.com/jonosweddingregistry.

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?

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.

For a lark, I hacked together a quick web-based piano keyboard using the <Audio> tag. The Audio tag (along with the Video tag) is part of HTML version 5, and it’s pretty cool, since it makes the audio file just another part of the HTML page rather than something that is stuck in a plug-in ghetto. That means that javascript running in the page can interact with the audio file, which is what makes this piano possible to do without Flash.

The audio files are pure sine waves (e.g. the A above middle C is 440 Hz) generated by Audacity and saved in .ogg format (an open-source encoding).

Unfortunately it will only work in a browser that supports HTML 5 the Audio tag, which as of right now is pretty much only (shameless plug) Firefox 3.5.

August 28, 2009: EDITED TO ADD: The web-based piano has been moved to evilbrainjono.net/music, where I am working on integrating it into a full web-based music composition lab.

When you’re trying to tidy up a room, there’s a right way and a wrong way.

You can pick up each thing off the floor and ask “Now where shall I put this?”

That’s the wrong way. You will have random objects stashed in hidey-holes all over your house, and when you need something you’ll have to dig through all sorts of random cruft to get to it.

The right way is to look at the room and say “What is this room used for? What things do I do here?”

If one of the things you do in the room is “pay my bills”, then you need a desk with a drawer where you keep stamps and envelopes and your checkbook, a jar of pens on top of the desk, a tray for incoming bills, and a wastepaper basket. For each thing that you do, you set up a “workstation” like this. Then, you get rid of everything that’s not part of one of your workstations.

The analogy to UI design should be obvious.

Look at some software and it’s obvious that the designer had a list of desired features, and they went through trying to find a place to put each one. This is backwards! (In especially bad cases, you can deduce the database schema of the persistence layer just by looking at the visual layout of the interface, because the latter is a reflection of the former.)

You must think in terms of supporting each task that the user will do with your software, providing an efficient workflow for each one, instead of looking at the features you’ve implemented and saying “Where shall I put this?”

I admit it: I have problems staying focused sometimes. I work on the Web all day, and the Web is full of distractions. The Firefox awesome bar doesn’t help matters — all I have to do is type a couple of letters into the awesome bar and it shows me suggestions of all sorts of fascinating, amusing, non-work-related websites. Total distraction is always just a few keystrokes away.

If only I could separate all my websites into ‘work’ websites and ‘fun’ websites, and somehow ensure that when I’m at work, Firefox only suggests the work websites, but when I’m at home, it suggests the fun websites.

Last week, I realized there’s actually a pretty easy way to do this, by splitting my Firefox profile into two profiles. It’s been working out pretty well for me so far; my random websurfing at work has gone way, way down.

Firefox profiles are an extremely powerful feature, but unfortunately many people who could make use of profiles don’t know they exist, because the interface to the feature is hidden. The rest of this post will walk you through the steps to enable profiles, split your profile into a ‘work’ and a ‘fun’ profile, and then purge all of the non-work-related stuff out of the ‘work’ profile.

(more…)