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?
- “flickr”?
- “upload”?
- “photo”?
- “upload-photo-to-flickr”?
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.
Hyphenated-phrases-are-awkward
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.
So-why-do-we-use-so-many-of-them?
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:
- feedly-calais
- feedly-email
- feedly-explore
- feedly-mark-as-read
- feedly-save-for-later
- feedly-share
- feedly-tweet
- feedly-view
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.
January 17, 2009 at 4:05 am
Ubiquity for Firefox: OH MY GOD THIS IS AWESOME!!!!!!!!!11111eleven…
If you only have 30 seconds to read my explosion of words, here’s the synopsis: Get Ubiquity. Now. It’s still in Alpha and therefore has some rough edges, but despite that, it is the best thing to ever happen to Firefox. And if you don……
January 17, 2009 at 4:51 am
Hi Jono. This is Edwin. I am one of the feedly developers. Thanks for this post. We are new to ubiquity and learning. We changed the names of the commands yesterday and removed the feedly- once we saw the post you had on container verbs. See http://edwink.devhd.com/2009/01/13/designing-the-feedly-ubiquity-integration/ for the new list. Please let us know if you have additional feedback and we will continue to iterate until we get it right. Thanks again and have a great week end. -Edwin
January 17, 2009 at 9:20 am
“They’re hard to type. The hyphen key is off the home row.”
I know this is going to be pretty off-topic, but please don’t make any assumptions as to what keyboard layout the user is going to use. In most cases, this is an excellent way to frustrate the non-American/non-programmer/non-QWERTY user. (Just yesterday I tried Archie, and right in the first tutorial, I needed the accent grave key, _but there was no such thing_ on my Hungarian layout) The story is similar with Unicode characters (only those that need them, worry about them enough to implement them well), but that’s another, even more unrelated topic.
I think one thing you could do is generalize the verbs: you would have one verb to ‘search’ and the modules would implement different ways to search (search FOO on google, search FOO on flickr, etc).
January 17, 2009 at 9:32 am
[…] here: When is a Verb not a Verb? Related ArticlesBookmarksTags Question Marks Instead of Non-ASCII Chars when using Get […]
January 17, 2009 at 9:40 am
Hmm, while reading your post I permanently thought about the AppleScript syntax with its “English-likeness”. If one likes (and after some experimentation) one can write programs that read just like English recipes.
And they have similar problems: You can write something like “set A to B as text”, and you can have “things” that consist of more than one word, i.e. “set A to path to me” – where the first “to” belongs to the “set” command, but the second “to” is a fixed part of “path to” (so one always has to say “path to”, because this is the property name of the path to the current script denoted by “me”; one could think about writing “set A to my path”, but that doesn’t work … but one could write “set A to path to of me” … looks weird, doesn’t it?).
So perhaps looking at AppleScript could be an interesting lesson of how to handle multi-part names.
Just my 2 cents.
January 17, 2009 at 10:08 am
Namespacing idea is very interesting. Thanks to share your thoughts.
A command could be built by two parts: the context (namespace) and the verb without using hyphens. So there would be a global context (default) where the built-in commands live – the user recall them without context – and the other commands need a syntax as
{context} {command} {noun | this} [modifiers {noun}]*
January 17, 2009 at 1:06 pm
It seems to me that Ubiquity is following an Emacs-way of command naming when the majority of commands use module-name-command-name format and only the most utilized ones could afford more readable names. I think it’s not good if your are trying to design a self-explaining interface unless your system is especially designed for old Unix hackers 🙂 More sophisticated grammar would lead to untrivial mental model but we somehow can easily deal with grammars of natural languages. So complicating the grammar in a right direction may simplify a mental model of it. But this task is incredibly complex so I’d rather avoid suggesting.
BTW Steve Yegge has written a nice post about Emacs, emacs lisp and javascript, it’s almost offtopic here but… http://steve-yegge.blogspot.com/2008/11/ejacs-javascript-interpreter-for-emacs.html
January 17, 2009 at 11:41 pm
How about allowing “command noun preposition” type commands? For example, “Search Google for *” could be allowed, and that doesn’t block a general search command that could go “Search for *”
while not as natural, why not require a preposition after each verb to signify the change from a verb to any arguments, if there are any. Some cases become unnatural like “Write” or “Read aloud”…
Also, it would be cool if there was a possibility to put things like “Using feedly, *” and any command tagged with “feedly” would show up in the suggestions box. I’m not sure what I would call the variable to tag it though…perhaps ‘namespace’ or ‘group’?
January 18, 2009 at 4:58 am
Ryan, for your last point regarding getting all the commands which belong to the same group, it can be addressed today using synonyms: we ended removing feedly- from the name of the command for for each command X, we kept feedly-X as a synonym.
January 18, 2009 at 6:12 pm
Coincidentally I was just reading about Zork and Infocom. How does this relate to Ubiquity?
“Infocom was well-known among game-players for the parser which allowed the user to type complex instructions to the game. Unlike earlier works of interactive fiction, which only understood commands of the form ‘verb noun’ (e.g. “get apple”), Infocom’s parser could understand commands like “get all apples except the green apple from the barrel.” –From http://en.wikipedia.org/wiki/Infocom#Overview
So you could in theory pull down the Dungeon (Zork Precursor) source code (1) and look at their parser to get ideas for updating the Ubiquity command parser.
(1) “Dungeon, the mainframe precursor to the commercial Zork trilogy, is generally assumed to be in the public domain and is available from The Interactive Fiction Archive as original FORTRAN source code, a Z-machine story file and as various native source ports.” http://en.wikipedia.org/wiki/Infocom#Legacy
January 18, 2009 at 8:38 pm
Introducing a common standard is important, but ergonomics from the user point of view are as much important.
I miss (in either sense, “have overlooked” or “it’s not present”) a way to rename most used commands to shorthands, much like bash’s aliases.
January 19, 2009 at 2:47 am
Namespaces are good. The problem is that they are backwards in English. Take street addresses for example. “221b Baker Street, Metropolis, CA, USA.” It’s little-endian, if you will. To make Ubiquity work like English, you will have to allow disambiguation very late in the syntax: “send this to flickr”, “search google for this”, etc. The verb “send” will have to be extensible to include any and all photo sharing, video upload, and file storage websites, and maybe even email. The verb “send” is ambiguous, and is only properly namespaced when a service is specified. The same goes for “search”, etc.
January 19, 2009 at 7:11 am
Just another idea to get the “namespace” out of the way: Something like a “target” (aka “object”) that has a list of “verbs” (aka “methods”) made known to Ubiquity. But when typing, the verb can precede the target name like “search google” (where “google” would be the target of “search”) or “search this in google”. So while typing the verb in ambiguous at first (and possible targets can be shown), but as soon as the target is typed the context (or “namespace”) is known to the parser (and the options can be narrowed).
January 19, 2009 at 2:35 pm
The solution, I think, is not to use English. Maybe Lojban?
January 19, 2009 at 11:20 pm
I’m very new to Ubiquity but already love it 🙂
Regarding the command naming problem I’m with Christian:
Treat the last two words as “provider/context”. this will allow users to write “email this to benedikt via google”, “translate this to german with leo”, “share this in feedly”. I’d vote against explicit namespaces because I think that many user will eg. either use gmail or yahoo for mailing and not care at all if the service is provided by developer A, B or C. Ubiquity might even allow users to set default contexts.
January 20, 2009 at 4:21 pm
In Feedly like a situation they can use feedly as the command & say email s the argument. It’s something similar to the gnu/linux commands I use everyday.
Things will look like
feedly email selection
highlight yellow selection etc.
I don’t know whether implementing this kind of a thing is possible. But I hope it makes sense 🙂 .
January 22, 2009 at 10:48 am
Hey, I like hyphenated phrases! But then, I also like Emacs, and I even rebound Ubiquity key to Alt-X. I believe of all non-whitespace separators, hyphen is the most readable (better than underscore, colon, semicolon, and so on). So, I would like this convention to stay.
January 22, 2009 at 5:34 pm
A solution would be to create the commands yourself. Script authors could then add their commands to verb ‘groups’ for example, and they can make custom nouns. The command structure would mainly be determined by ubiquity.
On a side note can you add auto-complete of verbs on pressing space bar? This won’t break anything, and not having it causes weird parsing errors. It is cumbersome to type the entire verb.
Thanks and waiting for your proposal..
January 22, 2009 at 10:34 pm
It seems like the original model of Ubiquity commands was to write plain English sentences and have the computer understand what you meant. “Book a flight to Chicago next Monday to Thrusday, no red-eyes, the cheapest. Then email my Chicago friends the itinerary, and add it to my calendar.”
This to me implies the ability to
1. combine multiple commands, let them call each other or send messages to each other
2. have functionality that’s associated with words rather than complete commands (“plug-ins” for each verb)
For instance, the “search” verb might have “engines” for Google and Yahoo built in, so I can type “search for searchterm with Google” or “search Yahoo for searchterm” and it would display the results all nicely in the preview. But I could also go to the Command Editor and enter information for the search URL and preview-retrieving code, so that “search searchterm on Answers.com” works, too. Then other users could publish “plug-in” code for the “search” verb that I could subscribe to, which adds additional sites to this function without actually rewriting the rest of the “search” code or the English parsing itself.
If each programmer has to write the English-parsing code in their command source, then of course no one’s going to do it, and we’re going to be stuck with hyphenated-keywords instead of real commands. Maybe instead of making the English parsing part of each command, you need to define a somewhat-rigid template for the types of sentences that can be used as commands, and then write code for nouns and verbs and subjects and objects instead of for “commands”?
Also, typing out full sentences is very tedious. I type the shortest thing I can that unambiguously identifies the action I want and then press Tab. Abbreviations are great, and this functionality should always be available, but it shouldn’t be the primary or visible way to access things. Allowing shortcuts is good, but the display should always try to show a full English sentence. If I type “wik in fr ordinateur”, it displays “wikipedia ordinateur in french”. This is wonderful, and it should even be extended explicitly to “Search for ‘ordinateur’ on French Wikipedia”. We shouldn’t have to create “aliases” to act as typing shortcuts like a crappy CLI. (Please don’t duplicate all the awful, braindead functionality of command line interfaces. No punctuation, no piping, and no cats, tars, or xfvzs, please.)
Oh, and Ubiquity is not Emacs. Get rid of the hyphens.
January 23, 2009 at 6:52 am
Very interesting conversation. One criteria to keep in mind I think is that the user wants to as soon as possible select a verb so that it gets hints from the system as to what the right structure is and the noun suggestions can kick in as well. I am raising this because I think that the via XXX at the end of the sentence is nice English wise but I am not sure it helps usability wise.
January 23, 2009 at 4:03 pm
I definitely recommend looking to games for ideas on parsing. Emily Short, a pillar of the Interactive Fiction community, is curating an open, collaboratively-developed game called Alabaster (http://emshort.home.mindspring.com/Alabaster/). This includes some really horrendous parsing issues (http://emshort.wordpress.com/2008/12/20/conversation-and-orders/), including pronouns and compound commands. At least she might be able to point out pitfalls ahead of time, or give some feedback on which kinds of syntax are easy, which are hard, and which are impossible.
January 25, 2009 at 5:58 pm
I believe that Microsoft’s PowerShell is operating in similar problem space. They are also trying to overcome the command naming issues from unix legacy. Have a look at how they approach it:
http://msdn.microsoft.com/en-us/library/ms714428.aspx
http://www.powershellpro.com/powershell-tutorial-introduction/tutorial-powershell-cmdlet/
February 1, 2009 at 12:09 am
[…] DiCarlo posted a series of blog posts exploring a new approach to verbs in Ubiquity, culminating in a proposal for new Overlord […]
March 3, 2009 at 11:57 pm
[…] would work well for most of the verbs commands from Jono’s list. Most of those verbs would be written in imperative form, in a direct interpretation of giving a […]
March 8, 2009 at 9:54 am
[…] the verbs in this Jono’s post. 23 are verbs: bookmark, calculate, close, convert, define, delete, email, exit, help, hilight, […]
June 23, 2009 at 6:22 pm
[…] “close-all-tabs”, etc. These hyphens were ugly, hard to type, and not very natural-language. Thanks to the fact that the new parser supports spaces, we can now have much more natural command […]
June 24, 2009 at 1:28 am
[…] “close-all-tabs”, etc. These hyphens were ugly, hard to type, and not very natural-language. Thanks to the fact that the new parser supports spaces, we can now have much more natural command […]
July 9, 2009 at 1:32 am
[…] “close-all-tabs”, etc. These hyphens were ugly, hard to type, and not very natural-language. Thanks to the fact that the new parser supports spaces, we can now have much more natural command […]
July 9, 2009 at 11:35 pm
[…] “close-all-tabs”, etc. These hyphens were ugly, hard to type, and not very natural-language. Thanks to the fact that the new parser supports spaces, we can now have much more natural command […]
August 21, 2009 at 10:23 pm
aliases and symlinks
and, if necessary, change the argument vectors in the code
“Those who do not understand UNIX are doomed to reimplement it, poorly.” – [I’ll bet you don’t know who said this. You should.]
I would go further and say that those who understand UNIX, like it. Those who do not understand it, do not like it.
Stop trying to jam everything into the browser. Without UNIX there is no internet.
May 31, 2010 at 5:39 pm
[…] “add-to-calendar”, “close-all-tabs”, etc. These hyphens were ugly, hard to type, and not very natural-language. Thanks to the fact that the new parser supports spaces, we can now have much more natural command […]