Re: Overlord verbs -- work in progress
Jono
I'd really like to hear your thoughts on whether the strategy I
outlined in the previous email will work or not for various other
languages.
Thanks!
--Jono
Jono
After reading over all of the feedback from the "great renaming" thread
( here: http://groups.google.com/group/ubiquity-firefox/browse_thread/thread/39693eb83725ad5b?pli=1
and here: )
I sat down on Friday to rethink my "Overlord verbs" proposal. I think
I was making a mistake in trying to have a single mechanism for every
problem. The goals, as always, are:
1. Get rid of all hyphens in command names
2. Open up the namespace so that third-party command developers have
more freedom to choose names for commands, without having name
collisions.
3. Be more flexible with the order of input, e.g. allow "Add X to
calendar" as well as "Add to calendar X".
4. Do not break the user's existing habits or increase the number of
keystrokes the user has to type.
With these things in mind, I realized that there are actually a couple
different classes of command naming problems, which will require
different solutions, rather than trying to come up with one solution
to fix everything. Here are the three solutions I see for the
different types of commands:
1. Parser 2 supports spaces in command names. So many commands that
previously had hyphens are now best represented as simply a multi-word
command name.
Example: "restart-firefox" -> "restart firefox". Simple!
2. Some commands need to be adapted to use variable "providers". For
instance, the "email" command currently uses only one provider: gmail.
It would be better if I could say "email using yahoo", "email using
hotmail", "email using gmail", etc. And if the "using (provider)"
argument was connected to a registry, so that a third-party command
author could write a new provider for the email command. The only
thing that varies between different email providers is the "execute"
function, so we want execute() to branch to an execute implementation
provided by the chosen plugin.
Other commands in the "accepts provider plugin" class would be "add to
calendar" (can use different calendar webapps), "search" (it already
has a mechanism like this), etc.
3. The third class of commands is really not suited to use provider
plugins, because they are really *different commands* that happen to
start with the same word. For example, imagine there's a command "add
to calendar" and another command "add to notes". This is
superficially similar to "search using google" and "search using
yahoo" but upon deeper examination, the commands are very different.
"add to calendar" and "add to notes" accept different numbers and
types of arguments -- for example, "add to calendar" accepts a date,
"add to notes" does not. Everything about them is different, not just
their execute method. So a plugin is not the right way to
differentiate between these commands.
The way I figured out to deal with commands in the third class is to
introduce a dummy argument which is really the suffix of the command
name. The command is now called "add (to calendar)". The part in
parenthesis is ignored by the parser -- the parser sees the command as
being called simply "add" -- but is used to uniquely identify the
command in documentation (such as in the command-list page) and to
ensure that one command does not override the other one. Therefore
two commands called "add (to calendar)" and "add (to notes)" can
coexist even though as far as the parser is concerned they are both
just called "add".
I implemented code to support parenthesized parts of command names in
https://ubiquity.mozilla.com/hg/ubiquity-firefox/rev/966b5cea7bd8
Then, I gave "add (to calendar)" a dummy argument: a goal argument
that accepts only the word "calendar". Thus, the user can input "add
X to calendar" or "add to calendar X" and they will both be accepted.
The command doesn't use this argument for anything, but if the
argument is filled, the parser can use that fact to increase the match
score of the "add (to calendar)" command. Thus, "add (to calendar)"
can be suggested when the input is just "calendar" -- it is a
noun-first match.
In https://ubiquity.mozilla.com/hg/ubiquity-firefox/rev/966b5cea7bd8
through https://ubiquity.mozilla.com/hg/ubiquity-firefox/rev/ee5d907fd8b2
I have been steadily rewriting the builtin and standard-feed commands
that fit in class 1 and class 3, so that they no longer have hyphens
in the names. I have not yet started implementing the plugin
mechanism that will be needed to handle the class 2 commands, but I
will do that very soon.
Comments? Criticism? Suggestions for renaming commands? Thoughts on
how well this would work or not work in other languages (esp. from the
i18n list) would be especially useful to me.
Thank you!
--Jono, Labs