Many commenters on my previous posts have already guessed what sort of naming standard I’m going to propose, or have suggested very similar ideas of their own. (I’ll take that as a sign that my idea is a natural evolution of the Ubiquity interface and not a controversial mutation.) Here’s the standard I propose:

  1. Multiple words are allowed, separated by spaces.
  2. The first word must be an actual verb.
  3. It’s OK for more than one command to use the same initial verb.
  4. The name should describe what the command actually does as specifically as possible.
  5. The name should not be longer than needed to fullfil these requirements.

To make this possible will require several changes in the way Ubiquity parses input and in the way it subscribes to command feeds.

I’ll get to those changes in a minute, but first, here’s a representative sample of what commands from the standard feeds would look like using this standard:

Original name New Name
amazon-search search amazon
answers-search search answers.com
bugzilla search bugzilla
youtube search youtube
(etc)
back go back
forward go forward
home go home
(etc)
bold make bold
italic make italic
(etc)
add-to-calendar add to google calendar
check-calendar check google calendar
digg add to digg
weather check weather
skin-list open skin list
command-list open command list
command-editor open command editor
close close window
close-tab close tab
word-count count words
edit-page make page editable
sparkline create sparkline

Note how certain initial verbs — such as get, check, close, open, create, make, go, send, and search — appear over and over again.

Let’s take every command starting with “check” and turn them into arguments of a single “check” verb. Let’s do the same to the commands starting with “go”, and so on. Verbs like “check” and “go” will become overlord verbs. (We could call them “meta-verbs” or “container verbs” or “verb families”, but “overlord verbs” sounds cooler.) So “go” would be a single command, having a required argument which can take values such as “back”, “forward”, “home”, etc.

Similarly, “add to calendar” is no longer a command of its own, but rather a “add” command with a “to calendar” (or better yet, “to google calendar”) modifier.

A precedent for this exists now: “search”, a command which takes the name of the search engine as an argument. We could get rid of the “yahoo-search”, “amazon-search”, etc. commands tomorrow and the “search” command would be happy to take over their jobs. What I’m proposing is that we extend the pattern of the “search” verb to as many other verbs as possible.

Advantages for the end user

Flexibility of input, mostly. Ubiquity verbs can accept their arguments in any order. Making “to calendar” an argument of “add” makes “add this to calendar” a legal input, as it should be. Input will be more natural than it is with hyphenated phrases.

It may look like we have made command names unneccessarily long, but remember that you don’t have to type the whole thing. Ubiquity already does noun-first suggestions, which means means that most of the abbreviations you’re used to using for your favorite commands will still work just fine. For example:

Input Suggestions
cal calculate, add to calendar, check calendar
add add to calendar, add to digg
wea check weather

The point is, with overlord verbs, you have more flexibility to give the arguments in any order (“search ebay for transformers” or “search for transformers (on) ebay”). You have more flexibility to start with the verb or start with the noun, whichever is more natural. We’ll be a step closer to the ideal world, where you can type whatever word first comes to mind and have Ubiquity guess correctly what you want.

Another benefit is that commands will be more clear about what services they connect to, and what providers they use. “add-to-calendar” sounds like a command that works with any calendar, but it’s not. It works only with Google Calendar. The command is privileging one service provider over all others, while masquerading as a universal command. Sneaky! But if add is an overlord verb, you can have commands like this:

  • add (this) to google calendar
  • add (this) to zimbra calendar

If you type “add this to cal”, both of these commands will be suggested and you can pick the one you want. Ideally, your favorite choice of calendars will be remembered and will be bumped to the top of the suggestion list (we’re working on this), so if you don’t specify it, it will default to whichever you use most.

Plus, you’ll never have to type hyphens again!

Finally, I expect that the long-term effect of the change will be more consistently-named commands, and I believe the consistently-named commands will be easier to learn.

The interface for command developers

I said that overlord verbs work like the “search” command, but that’s not exactly true. Overlord verbs are better than “search” in one important way: New search engines can be added to the Search command only by direct editing of the Search verb source code. It’s closed to the outside world. It can’t benefit from the contributions of third-party command developers.

Ubiquity is about the command developer interface, not just the end-user interface. We need to provide a command developer interface that makes it effortless to write a new plugin (an “underling verb”, perhaps?) for an existing top-level overlord verb.

So here’s how I think it should work. Assume “blog” has been defined as an overlord verb. One command developer writes a command named “blog on wordpress”. A second developer writes a command named “blog on blogger”. An end-user subscribes to both commands. Ubiquity detects that both of these commands start with “blog”, so it automatically modifies the “blog” verb to expect a modifier, preceded by “on”, to have a value of either “blogger” or “wordpress”. (I think it will do this by defining a custom noun-type bound to the overlord verb, but that’s an implementation detail and not important right now.) When executed, “blog” simply checks what the value of this modifier is, and dispatches execution to either the “blog on blogger” execute function or the “blog on wordpress” execute function. (The same goes for dispatching the preview function.)

Advantages for the command developer

You can use multiple words to fully describe what your command does. (“blog on wordpress” is more descriptive than just “blog” or just “wordpress”.)

You don’t have to fight other commands for common verbs, but rather can coexist with them. (You don’t have to worry whether “blog” is already taken.)

You can implement a command for a single service provider or web application, and someone else can implement the same command for a different service, and they’ll work together. You write “email using yahoo” and I’ll write “email using thunderbird”, and our commands will coexist happily even if we never look at each other’s code. The user can specify a provider (or allow it to default to their most often used provider) in the way I’ve already described.

Open Questions

Who has responsibility for making a verb into an overlord verb?

Does Mozilla Labs say “Here are the verbs that will be overlord verbs” and that’s it? It would be hard (impossible) to make an exhaustive list. But on the plus side, we could provide usage guidelines ( what types of commands should start with “open” vs. what should start with “go”, etc.) that might make things more consistent for the end-user.

Or is there a way for any command developer to define a new overlord verb? (If so, how do you allow other command developers to hook up to your overlord verb? And how will the end-user resolve the resulting dependencies?)

Or are overlord verbs created by Ubiquity, automatically, as needed? If you subscribe to two commands that both start with “travel”, will Ubiquity just create an ad-hoc “travel” overlord verb to resolve the conflict?

What exactly is the naming standard? This standard:

“Start your command name with a verb, then use as many more words (space-separated) as needed to describe its function.”

That’s a good start, and if everyone follows it I think things will be a lot better than they are now. But it leaves some things unspecified. (E.g.: my command takes you to a URL. Should I start it with “open” or with “go”? Is there a standard for that?)

How do we deal with other modifier arguments to a subordinate verb of an overlord verb?

How does this work in languages besides English?

I don’t know the answers to any of these questions yet. As always, your feedback and criticism is more than welcome.

Advertisement