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:
- Multiple words are allowed, separated by spaces.
- The first word must be an actual verb.
- It’s OK for more than one command to use the same initial verb.
- The name should describe what the command actually does as specifically as possible.
- 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.
January 24, 2009 at 4:25 am
I, for one, welcome our new overlord verbs.
January 24, 2009 at 4:31 am
I do like the concept of standardizing the namespace with Ubiquity, but with some users, typing in Google is what they will type in for search. Google in some markets has become synonymous with search. In this case, Google (or another search engine) is often used as a verb in place of the proper verb.
A paradigm you need to also keep in consideration is K.I.S.S. (Keep it Simple, Silly). The more text the user needs to input (and henceforth the more work that is needed in accomplishing the task), the less likely that they will even bother to learn the functionality or continue to use it.
With that being said, I do believe that Mozilla Labs (and possibly other entities as well) come up with a logical search system. Perhaps this can be one step closer to an intelligent query and command language (as compared to SQL).
January 24, 2009 at 7:45 am
@rpn: In the case you describe, the suggestion list should be “search google”, “add to google calendar”, etc., defaulting to “search google” (since that will most likely have the higher usage count) – which sounds even better than “google it” – ubiquity gives the impression that it has a deeper understanding for slang 😉
You’re right about the relation between query length, but the proposed system isn’t worse than the old one – “s ubiquity” will still default to a google search for ubiquity.
Great stuff, Jono!
January 24, 2009 at 11:38 am
Sounds good to me! I’m going to start rewriting some of my commands now.
January 24, 2009 at 2:13 pm
@rpn
Did you actually finish reading the article??
“It may look like we have made command names unnecessarily 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:”
January 24, 2009 at 4:50 pm
A way for users to edit the names of commands they’ve installed would be useful in cases where developers haven’t followed the standard, or picked the most meaningful or concise name for a command. It could even allow users to pick shorter okeywords for commands they use frequently.
The alternate names could even be shared on herd so that a user could pick the best name for them when they install a command.
January 24, 2009 at 5:50 pm
This idea NEEDS to happen. (I’m not even close to kidding … I took a look at my mom/dad using the internet over break and they need something like a Ubiquity where they can type what they want because they’re confused by icons. We did some testing with ubiquity and they loved the idea but couldn’t remember what was valid input and couldn’t consistently put the same input for the same task.)
As far as productive ideas: I think you can add a “get” verb. I know it’d probably be overused but I for one think “get weather” “get stocks” “get e-mail” is more intuitive than “check weather” “check stocks” “open e-mail”.
Also, there’s nothing wrong with overloading in my opinion. So “get e-mail” can be an alias for “check e-mail” which can alias “open e-mail” and all be distinct from “write e-mail” “start e-mail” “compose e-mail” “send e-mail” which are further distinct from “search e-mail” and “find e-mail”
This has the added benefit of making it easier to internationalize. In Chinese, it’s “get e-mail” or “look e-mail” but “check stocks”. When you “check e-mail” it’s more like “inspect e-mail” or “search e-mail”. So there isn’t a 1-1 mapping of verbs to translations and having many verbs allows more fluidity in translation choice. (Take this with a grain of salt, I’m not hip with the Chinese internet terminology having not spoken it hardly ever but you get the idea.)
January 24, 2009 at 6:49 pm
Yet another possible usage for URLs could be “Connect to XYZ”.
January 24, 2009 at 7:56 pm
I like this idea…linguistically speaking, the transition is from lumped-together-verbs to more natural-sounding verb phrases. If this is adopted by the community, I think it would make for a more consistent and more humane interface.
One problem that might surface (at least in English) is with web services whose names are used as verbs. If you can “facebook” somebody, “digg” something, or (as rpn points out) “google” for something, who’s to say what counts as a verb versus a noun?
A consideration for other languages is that it might be just as (or more) natural to put phrases like “on wordpress” or “to google calendar” *before* the verb. I would imagine the same sort of issue occurs with the arguments as they are handled now for verb-final languages (is there a Japanese version of Ubiquity?).
January 24, 2009 at 9:26 pm
Regarding the comments about “google” (and other services) effectively being a verb, and people typing that first: the system proposed here will deal with this case. See the list of examples of input/suggestions under the “Advantages for the end user” heading.
January 24, 2009 at 11:53 pm
So, as far as I know, bold is the verb form. The verb form of italic is “italicize,” not “make italic*.”
Which, I guess, segues into another issue: what about rare verbs? Italicize doesn’t take an object, but it’s a useful verb for a particular command.
yrs–
–Ben
* Also, “make” is a really awkward general-use verb for this, isn’t it?
January 25, 2009 at 12:39 am
So google-site-search would become “search within this site using google”?
So if I want to be able to search using a search engine that’s not included in the Mozilla-authored commands, I need to copy and paste the entire command code from the Mozilla version and then modify it to include my engine? I can’t just write an execute function that plugs into the other command? I guess that would be best, since the original command could then be modified out from under my “plug-in” in a way that makes it non-functional? Why does this require that “blog” has been defined as an overlord verb? Can commands have verbs that are *not* overlord verbs? If so, how will they behave differently?
It’s a little hard to imagine how this all would work. Maybe some simple code examples would help?
January 25, 2009 at 8:21 pm
I love the idea of namespace, but I think concise is also beautiful. I’d like to suggest something about “paraphrase list”, which allow any user (not only Command Developer) to choise whether to allow for shorten representation.
Any user couldn’t only choice whether “google” means “search google”, but also add new idiom, as if “translate to russian using google-translate” be restated as “russify”. Someone might think “close” is not “close window” and should be “close tab”. Of course, the “google” substituted for “search google” is served with “search”-siblings e.g. “search yahoo”. This is mere paraphrase.
Every man after his fashion about paraphrase.
So, I just think every man should be able to choice the paraphrase.
Another problem is localization. ”グーグルで(google) 検索する(search)” is the Japanese idiom which means “search google”. On the other hand, Some Japanese prefer the term “ググる” instead of verbal “google”. They input it and intended to search google, only to fail in suggestion because the word “グーグルで 検索する” is not include “ググる” unlike with the example “check weather”. In non-English langage, shortened form is not always suggestable form. Even in this case, “paraphrase list” would be desirable solution.
January 25, 2009 at 11:02 pm
Forgive my carelessness with your encoding.
The following is the last paragraph in Romaji (http://en.wikipedia.org/wiki/R%C5%8Dmaji)
Another problem is localization. “Gu-guruDe(using google)Kensaku(search) is the Japanese idiom which means search google. On the other hand, Some Japanese prefer the term “Guguru” instead of verbal google. They input it and intended to search google, only to fail in suggestion because the word Gu-guruDeKensaku is not include Guguru unlike with the example check weather. In non-English langage, shortened form is not always suggestable form. Even in this case, paraphrase list would be desirable solution.
January 26, 2009 at 6:05 pm
> * Also, “make” is a really awkward general-use verb for this, isn’t it?
Yes, yes, it is.
January 26, 2009 at 8:09 pm
I think the best solution for this is to let ubiquity make them. Simple add in a nice little variable for overlord verb. Then ubiquity just collects all of them and sends them to the correct command. No dependencies or code for the overlord verb. (meaning its not comparable to java extend) just a name.
That would be the best way in my opinion.
January 27, 2009 at 12:22 am
Would it be possible to provide a service that a coder uses to register an overlord verb? If it doesn’t exist then Ubiquity creates it. Once created, the service provides means for attaching a subordinate command verb. Possibly make it a rule that all command verbs must be registered with at lest one overlord.
As for the ‘open’ vs ‘go’ question, suggest that coders always use ‘open’ except where it just doesn’t make sense – i.e. ‘open back’ – or better yet, allow registration with multiple overlords.
January 27, 2009 at 9:20 pm
[…] what’s up with Weave this week, and the exciting changes coming in Ubiquity with “Overlord” […]
January 27, 2009 at 10:02 pm
I think making new “alias” overlord verbs with NO programming (not even easy simplified Javascript, just clicking a button and typing in a text box or two) is absolutely essential to please everyone. No matter what convention is chosen, somebody’s not going to like it, so they need to have the option to create their own personal shortcut in a snap.
Also, by tracking what aliases are popular (either built-in or user-created), it might give some interesting statistics, not just about how to improve Ubiquity, but also about regional dialects.
January 28, 2009 at 7:55 am
Bought!
January 28, 2009 at 1:16 pm
I can’t wait for this to be implemented. I die inside a little bit every time I have to type a hyphen … so finally having true natural language will be great
Great work!
January 28, 2009 at 5:42 pm
I love this direction — I can’t wait to get rid of hyphens, am in favor of promoting consistency, and really like that this facilitates more natural phrasing without forcing people to type more.
But I have to say that the concept of overlord verbs strikes me as unnatural — more an artifact of Ubiquity’s command model than something rooted in the real world — and I think that may be a sign that there’s something wrong.
I started elaborating on this in a comment yesterday, but it started getting really long so decided to write a blog post instead. I’m still working on it, but wanted to voice my high-level concern here in the meantime. I’ll comment again when the post is done…
January 28, 2009 at 6:14 pm
“Open” could be replaced with “go to”, so everything starts with “go”: “go to skin list”, “go back”, etc
January 29, 2009 at 12:59 am
Another thing to consider about Ubiquity and its verb use is the relevance of an upcoming technology: Voice recognition.
Voice recognition technologies combined with natural language processing may be ideal as Fennec matures (and if Ubiquity is ported to it). Assuming the host mobile OS has relatively decent voice recognition, using Ubiquity and voice commands could rapidly change the face of mobile browsing.
January 31, 2009 at 5:05 pm
“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?”
I think this would be the best option, but the developers need some sort of standard for what’s what, especially between go and open. Another option for that is to make go and open both work for the same commands. Maybe just hardcode that one thing into Ubiquity, or open up the option for developers to put their commands under multiple overlords (or both).
February 1, 2009 at 12:24 am
[…] Jono DiCarlo posted a series of blog posts exploring a new approach to verbs in Ubiquity, culminating in a proposal for new Overlord Verbs. […]
February 1, 2009 at 3:36 pm
[…] Jono DiCarlo posted a series of blog posts exploring a new approach to verbs in Ubiquity, culminating in a proposal for new Overlord Verbs. […]
February 25, 2009 at 3:40 pm
I really love this idea, but the only point on which I might contest is the idea of having multiple commands that start with “blog yada yada”.
Suppose for a moment that people across the world get faster and faster internet. Perhaps then, videos will become more prominent than text. In this case, the idiom of “blog” might change to “vlog”.
Now, either all command developers must change their code from “blog” to “vlog” or Ubiquity must accept both. Coming from the world of OSGi, it seems that perhaps we should register our arguments as services with a particular “overlord verb”. This would also facilitate internationalization as the command would no longer be tied directly to the word.
After reading http://mitcho.com/blog/projects/writing-commands-with-semantic-roles/ it seems that the argument would possibly be a role.
Just some thoughts 🙂
March 5, 2009 at 7:49 am
[…] dê (literally me give) to use a verb to request a map. This is a great example of how Jono’s overlord verbs proposal may be an important aspect of our i18n efforts. The post is also timely as we’ve recently […]
March 8, 2009 at 9:54 am
[…] first problem (the biggest one) could be solved using overlord verbs (see this proposal): “google”->”search google”->”cerca in […]
March 9, 2009 at 8:43 pm
[…] the imperative form of the verbs, but that some verbs may not translate neatly, even following the overlord verbs proposal: For example, the verb “make” is quite difficult to translate (too generic): “to make” […]
March 10, 2009 at 6:36 pm
[…] Overlord Verbs: a Proposal, by Jono […]
March 11, 2009 at 3:35 am
[…] Overlord Verbs: a Proposal, by Jono […]
March 24, 2009 at 1:24 am
[…] in Ubiquity Parser: The Next Generation. The new architecture is designed to support (1) the use of overlord verbs, (2) writing verbs by semantic roles, and (3) better suggestions for verb-final languages and other […]
April 1, 2009 at 3:23 am
[…] Ubiquity parser which will bring some great new features to Ubiquity, including support for overlord verbs and semi-automatic localization of commands via semantic roles. It’s possible, though, that […]
May 30, 2009 at 12:41 am
[…] Implement a more flexible way of handling input that will allow for more consistency, and no more hyphens, in command names. (more about the proposed change here.) […]
May 30, 2009 at 9:35 pm
[…] Implement a more flexible way of handling input that will allow for more consistency, and no more hyphens, in command names. (more about the proposed change here.) […]
June 3, 2009 at 7:01 am
[…] Implement a more flexible way of handling input that will allow for more consistency, and no more hyphens, in command names. (more about the proposed change here.) […]
June 4, 2009 at 12:45 pm
I love this idea! I’ve posted my feedback in the Google Groups “forum”.
http://groups.google.com/group/ubiquity-firefox/browse_thread/thread/39693eb83725ad5b#
June 5, 2009 at 10:09 pm
[…] Overlord Verbs: a Proposal « Not The User’s Fault (tags: ubiquity localization) […]
June 23, 2009 at 6:22 pm
[…] the new parser supports spaces, we can now have much more natural command names. We’ve also standardized the command names in a way that we hope will make Ubiquity overall easier to learn. Spaces in command […]
June 24, 2009 at 3:27 pm
[…] you do want to learn the commands, though, you’ll be glad to know that they’ve now standardized those verbs to make them easier to learn. There are no more commands with hyphens, like the ugly […]
June 24, 2009 at 3:42 pm
[…] you do want to learn the commands, though, you’ll be glad to know that they’ve now standardized those verbs to make them easier to learn. There are no more commands with hyphens, like the ugly […]
June 24, 2009 at 3:50 pm
[…] you do want to learn the commands, though, you’ll be glad to know that they’ve now standardized those verbs to make them easier to learn. There are no more commands with hyphens, like the ugly […]
June 24, 2009 at 5:12 pm
[…] you do want to learn the commands, though, you’ll be glad to know that they’ve now standardized those verbs to make them easier to learn. There are no more commands with hyphens, like the ugly […]
June 24, 2009 at 5:25 pm
[…] you do want to learn the commands, though, you’ll be glad to know that they’ve now standardized those verbs to make them easier to learn. There are no more commands with hyphens, like the ugly […]
June 25, 2009 at 12:52 am
[…] enough, it couldn’t support localization, and it was getting in the way of defining sane and consistent naming standards. Since our original hacky prototype, we have gained so much knowledge (about what the parser and […]
June 25, 2009 at 2:39 am
[…] you do want to learn the commands, though, you’ll be glad to know that they’ve now standardized those verbs to make them easier to learn. There are no more commands with hyphens, like the ugly […]
June 25, 2009 at 3:02 am
[…] you do want to learn the commands, though, you’ll be glad to know that they’ve now standardized those verbs to make them easier to learn. There are no more commands with hyphens, like the ugly […]
June 25, 2009 at 5:11 am
[…] you do want to learn the commands, though, you’ll be glad to know that they’ve now standardized those verbs to make them easier to learn. There are no more commands with hyphens, like the ugly […]
June 29, 2009 at 6:22 am
sorry if I missed the relevant info regarding suggestions and commands within ubiquity. from experience and observation, similar to the customization of desktops, the FF browser is now a very personalized tool for individuals as in addons, passwords, etc.
so, i’m wondering is it possible for the suggestions interface to learn each unique user’s language tendencies? in the case of multiple users, the profiles feature of FF would take precedence and be more viable.
for example as a user types in a verb and noun command, the suggestion interface can help to specialize the command to match the user’s linguistic style based on other users linguistic trends. this is similar to the “did you mean” feature in google or amazon’s and netflix’s related items suggestions.
after repeated use the commands typed in by the user will be learned by ubiquity and be localized without the need for a major localization effort or overload verbs. in other words the overload verb feature is more of a functionality of ubiquity’s suggestions rather than a set dictionary of terms which need to be customized or constantly upgraded as the vocabulary set expands.
again in the avoidance of duplication, i apologize if my search efforts has not revealed this concept being discussed before.
lastly, congratulations on Jono’s big day — may nuptial bliss bless this new partnership of like minded souls.
July 9, 2009 at 1:32 am
[…] also standardized command names in a way that we hope will make Ubiquity overall easier to […]
July 9, 2009 at 7:56 pm
[…] dem Ziel vor Augen Ubiquity zu einer finalen Version zu führen, sind zahlreiche Kommandos normalisiert worden. Ubiquity lässt sich ohne weiteres erweitern: Für die Version 0.5 existiert ein […]
July 9, 2009 at 11:35 pm
[…] also standardized command names in a way that we hope will make Ubiquity overall easier to […]
July 10, 2009 at 1:03 pm
[…] the new parser supports spaces, we can now have much more natural command names. We’ve also standardized the command names in a way that we hope will make Ubiquity overall easier to […]
March 12, 2010 at 8:13 pm
Awesome post. There’s a lot of good info in this article, though I want to let you know something – I’m running Ubuntu with the up-to-date beta of Firefox, and the design of your web site is somewhat flaky for me. I can understand the post, but the navigation doesn’t work so well.