Hello, Ubiquity command developer community?
We need to talk.
Here is an assortment of Ubiquity verbs, that I chose semi-randomly as a representative sample. Some were developed by Mozilla Labs, and others are third-party verbs I found via the Herd. What do they all have in common?
- yahoo-search
- add-to-calendar
- command-editor
- remove-annotations
- flickr
- view-source
- foxytunes
- stumbleupon
- validate
- search
- lyrics
- link-to-wikipedia
(Answer below the fold.)
Answer: They have nothing in common. That’s the problem. The ubiquity command namespace has no consistency whatsoever. It is total anarchy. For example, why is there a “-search” suffix in the name “yahoo-search” but not in the similar command “google”? (Both
first-party commands, by the way, so there’s really no excuse.)
This anarchy is bad for users. The biggest challenge facing new users of Ubiquity is the difficulty of discovering and memorizing the names of the various commands. It certainly doesn’t make things any easier that some search commands have “search” in the name while others don’t. The more command names follow a consistent pattern, the easier it will be for new users to learn the system.
(The same goes for the way that commands use arguments, the wording of their documentation, and so on — the more consistency, the easier the overall system will be to learn.)
The current anarchy in the namespace is not the fault of the command developer community, but rather of Mozilla Labs: We imposed no standard on the naming of our own internally-developed commands, nor did we offer any naming examples or guidelines for third-party developers.
I think it’s past time to start a discussion of standards for command names. However, it’s no good proclaiming a standard if it’s not something people will actually follow. So before proposing anything, I’d like to delve into some of the difficulties of naming commands — difficulties
which push command authors towards choosing nonstandard or suboptimal names — and what improvements the parser will need in order to make better names easier.
January 16, 2009 at 2:48 am
Isn’t that (discoverablity, and to some extent consistency) a fundamental tradeoff in having a textual command oriented system that independent third parties can extend?
I mean… /usr/bin on Unix is a big sloppy mess. But in the end, people learn from others (or documentation) what’s useful.
One pattern though is the domain prefix approach, like “git diff”, “git commit” etc. But, it should be fine to claim the name “google” for doing a search. Among those, “lyrics” stands out as a pretty bad name.
I am actually writing a command-oriented system myself; one thing I did early on was separate out meta-operations (ones that operate on the system itself) from “regular” ones by requiring a special keybinding (I chose Alt-x in homage to Emacs); if “command-editor” is a Ubiquity specific one it might make sense to make it require a similar keybinding.
January 16, 2009 at 6:30 am
Maybe it would be usefull create a command providing (suggesting) a command name (herd-register-command?), using a category approach, for instance: search (-search), national service (-us, -it, etc. ), service related (-facebook, -flickr) and so on.
January 16, 2009 at 6:30 am
That’s a pet peeve of mine too.
I’d like to get ticket 134 tested (container verbs) to see of that helps.
January 16, 2009 at 3:47 pm
While having certain consistencies is nice (the Google and Yahoo-Search inconsistencies not being there for example), the English language itself doesn’t offer much in consistency either.
January 17, 2009 at 3:30 am
[…] Not The User’s Fault Open-source software needs better user-interface design in order to take over the world. Jono at Mozilla Labs. Skip to content These things I believe. « An-ar-CHY in the Name-SPACE […]
January 20, 2009 at 3:27 am
“It certainly doesn’t make things any easier that some search commands have “search” in the name while others don’t.”
You make it sound like people are typing out the whole command. :) This really makes very little difference to users, since they’re only typing as much of the command as they need to narrow down the selection to what they want.
January 20, 2009 at 4:36 am
I have been working on a design that has similar problems. One way I am considering solving this problem is to provide a method for the user to provide context. The user sets a context by selecting from a set of buttons (something like ‘Email’). Then all the Verbs used are assumed to be ‘Email’ related. Because I have some context, I can now provide real-time suggestions as the user starts to type in the Verb. This helps with discovery as well.
This is all theory at the moment as I am in the early design phase but it should help.
February 1, 2009 at 12:07 am
[…] DiCarlo posted a series of blog posts exploring a new approach to verbs in Ubiquity, culminating in a proposal for new […]
February 1, 2009 at 3:35 pm
[…] DiCarlo posted a series of blog posts exploring a new approach to verbs in Ubiquity, culminating in a proposal for new […]
April 16, 2009 at 8:56 pm
[…] about before? Jono DiCarlo, also on the Ubiquity dev team, mentions that Ubiquity commands are very inconsistent: Currently, using Ubiquity is like programming in PHP — where some standard library […]