In my previous post I pointed out the problem that is the lack of standardization in command names.
My idea when originally designing the Ubiquity parser was that each command would be named with a single word, always a verb, and that this would allow user input in something approximating natural language, without being too difficult to parse.
However, now that several months have passed and a healthy library of commands has been created, I think my original assumption was wrong. Looking over the list of built-in commands, I find that:
23 are verbs: bookmark, calculate, close, convert, define, delete, email, exit, help, hilight, map, print, redo, refresh, restart, save, search, tag, translate, undelete, underline, undo, zoom
9 are nouns, adverbs, or adjectives: back, bold, forward, fullscreen, home, italic, sparkline, tab, weather
10 are names of websites and services: bugzilla, digg, flickr, google, imdb, tinyurl, twitter, wikipedia, yelp, youtube (A few of these, especially Google, Digg, and Twitter, are starting to become verbs by common usage these days, so you could count them as verbs if you were being generous.)
32 are hyphenated phrases: add-to-calendar, amazon-search, answers-search, ask-search, check-calendar, close-related-tabs, close-tab, command-editor, command-list, desaturate-image, detect-email-provider, ebay-search, edge-detect-image, edit-page, escape-html-entities, flip-page, get-email-address, google-image-search, invert-image, last-email, link-to-wikipedia, map-these, msn-search, remove-annotations, rotate-image, share-on-delicious, skin-list, stop-editing-page, syntax-hilight, view-source, word-count, yahoo-search
(Pie chart thanks to http://chartpart.com/)
The great thing about standards is there are so many to choose from!
The lack of consistency is bad in itself, especially for new users. Say I’m new to Ubiquity, and I want to upload a selected image to my Flickr account. I don’t know whether or not there’s a command to do that. I’m going to make some guesses and type them into the command line to see if they match commands. But what shall I type?
If ubiquity stuck to one style of naming, I could immediately eliminate all but one of these. But as-is, I have to try all four before I can conclude that there’s no command matching what I want.
Currently, using Ubiquity is like programming in PHP — where some standard library functions are_like_this() and other functions areLikeThis(). I have to look up the names of functions almost every time I use them in PHP, because there’s no consistency.
Beyond the lack of consistency, the fact that so many commands — nearly half! — are named with hyphenated phrases is really bad. Hyphenated phrases have the following drawbacks:
- They have the DOS nature. Remember the bad old days when you couldn’t have spaces in your filenames on most operating systems? You had to mash words together or put hyphens or underscores in there because the OS used spaces to separate arguments? Yeah. I’m not proud of recreating that environment.
- They’re hard to type. The hyphen key is off the home row. You have to reach for it; you have to think about it. And the parser isn’t smart enough to do disjoint matches inside a verb name, so you can’t type “add to cal” and have it recognize “add-to-c alendar”. You can type “add” or “cal” and arrow-key down to the correct completion, or you can type hyphens. Either way, your fingers must leave the home row.
- They’re hard to learn. A long series of words (which must go in a certain order) is harder to remember than a single word.
- They make a mockery of the idea of natural-language input. “add-to-calendar this” is anything but natural, but that’s what the system wants you to type. The natural input would be “add this to calendar”, but Ubiquity can’t parse that because it doesn’t know how to break up the hyphenated phrase.
- They’re just plain ugly.
First of all, they’re hyphenated phrases instead of multi-word phrases because of a limitation in the parser: it assumes that the verb ends at the first space, and therefore verbs can’t contain spaces. This could be fixed, but the question then shifts to “why do we use so many multi-word phrases”?
To clearly spell out what a command does. Commands named with a single verb are usually ambiguous as to function: Without looking at the documentation or preview strings, can you tell me what “convert” is supposed to do, what “exit” exits, and what “zoom” zooms? Often the verb by itself has little meaning. If we were to enforce a rule that command names must start with verbs, think of how many dozens of commands would start with “add”, “check”, “set”, “search”, or some variant thereof. If you want to “check the weather”, most of the meaning of that phrase is in the word “weather”, not the word “check”. That leads to commands getting named either with the noun (“weather”) or with an entire phrase like “check-calendar”.
The other reason commands get named with phrases is because the verb alone is already taken. If you want to write a command that does something with email, you can’t call it “email”, because that word is already taken by a built-in command, as are many other common and widely applicable verbs. So you’re forced to go with something like “last-email” or “get-email-address”. Simple, meaningful, memorable, single-word verbs are a limited resource. That resource is already running low, and the problem will only get worse the more commands are written.
Finally, related to this, hyphenated phrases are used as a primitive version of namespacing. There is no better example than the Feedly commands:
Feed-reader service Feedly is now building a whole Ubiquity-command-based interface to their software. As you can see, they’re prefixing their commands with “feedly” to distinguish them from the built-in commands like “email”, “twitter”, etc. They’re using a hyphenated prefix to define a “Feedly namespace”.
As one of the Ubiquity developers, I find this incredibly cool, not to mention very flattering. However, at the same time, I’m cringing a little bit inside, because the limitations of the system that I helped build are forcing Feedly to choose sub-optimal names. Command names like “feedly-email” are bad for all the reasons I mentioned above: they require very un-natural language, and worse than that, they’re hard to type. You can type “email” and be offered a choice between “email” and “feedly-email”. You can type “feedly” and be offered a choice between the top five “feedly” commands. But to unambiguosly specify “feedly-email” under the current parse, you have to either type the whole thing including the hyphen or you have to use the arrow keys.
I’m not happy about this. (Can you tell?)
I don’t believe it would work to simply tell command developers “Hey! Stop using hyphens in your names!”. Instead, we need to address the limitations of the system that are currently pushing developers to choose hyphenated names. The solution will have to satisfy the need for namespacing, alleviate the scarcity of good single-verb names, and allow for more descriptive and meaningful command names, without requiring the user to enter un-natural language or to do lots of extra typing.
In the next and last post in this series, I’ll make a proposal for such a solution.