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?

 

What the hell is this “Ubiquity” thing anyway?

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.