Verb-final languages: an advantage?

Over at his blog, Mitcho has some very sharp thoughts about localizing Ubiquity to verb-final languages such as Japanese.

I talked about similar localization issues several months ago, but Mitcho takes it further than I did. He says:

In a verb-final language, however, you enter the arguments first and then the verb, making this strategy of suggesting appropriate arguments impossible.
…
Instead of seeing this as a disadvantage, however, let’s see what verb-final order allows us to do.

That’s the spirit!

He goes on to talk about analyzing the arguments, which are entered first, and using them to suggest a verb. I think this is exactly the right idea.

I’ve just got one thing to add: Ubiquity already does some very rudimentary suggestion of verbs based on having the nouns first. This is how we handle the case where the user selects some text and then pops up the command line — we suggest verbs based on the noun types that produce a positive match to the selection. It’s very basic right now, and could be a lot better.

The good news is that we can take the algorithm that suggests verbs based on the selection, and apply it to Mitcho’s idea of suggestions in verb-final languages. Any improvements we make in one will be applicable to the other, and vice versa. Working on the noun-first suggestion algorithms helps everybody!

 

Overlord Verbs: a Proposal

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:

1. Multiple words are allowed, separated by spaces.
2. The first word must be an actual verb.
3. It’s OK for more than one command to use the same initial verb.
4. The name should describe what the command actually does as specifically as possible.
5. 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:

 

Don’t make me do more typing!

To review my previous two posts:

Ubiquity needs a naming standard.

The standard must provide an attractive alternative to hyphenated-phrase-command-names. It must allow unambiguous command names, which means it must support multiple words in a command name. It must provide namespacing, and reduce competition for common verbs. The parser must be able to split up the words so you can enter them in any order that makes sense to you.

As if those weren’t tricky enough requirements, I’m adding one more: It must not increase the number of keystrokes that the user has to type to invoke a command.

For example, if part of the standard is “must start with a verb” — so that the “weather” command was renamed to “check weather” — it would be very bad if the user had to actually type “c-h-e-c-k–w-e …”. That would be forcing the user to do more typing for little or no gain. We need to make sure that the user can still type just “w-e-a” and have it complete to “check weather”.

Yes, I want a natural language interface, but that doesn’t mean I think we should be enforcing a strict grammar on people at the cost of efficiency. In real life people speak in fragments all the time, or start and stop in the middle of sentences, so a humane interface should allow the same.

 

When is a Verb not a Verb?

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:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.

 

An-ar-CHY in the Name-SPACE

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?

• google
• yahoo-search
• add-to-calendar
• command-editor
• remove-annotations
• flickr
• view-source
• foxytunes
• stumbleupon
• validate
• search
• lyrics
• link-to-wikipedia

(Answer below the fold.)

 

バビルの塔

Back in July, I was at the Mozilla summit in British Columbia, meeting with Mozillanoids from all over the world. The first question is always, “So what are you working on?”. When I explained the idea of Ubiquity to people, the most common reaction was “That’s cool, but it’s so… English-centric. How are you going to localize it?”

 

Why Verbs?

Now that I’ve blogged about Ubiquity, you should understand why I’ve been obsessing over the properties of a good linguistic UI. It’s not an academic problem: It’s one of the interfaces to the extension I’m working on right now!

Some commenters have asked me the question (if not in these exact words): Is a linguistic UI the right kind of UI for Ubiquity, and if so, why?

(“Because Jono is obsessed with linguistic UIs” isn’t a good enough reason.)

First, the really big picture of what Ubiquity is supposed to be all about: It’s a step towards a Web where verbs (i.e. functionality, i.e. commands, i.e. services) are first-class citizens. And that’s why I’m thinking it should be renamed from Ubiquity to something like “Mozilla Verbs”, maybe.

 

Language-Based Interfaces, part 1: The Problem

What would the web be like if you could tell it what you want to do as easily as you currently tell it where you want to go?

Mozilla Labs is starting to experiment with linguistic interfaces. That is, we’re playing around with interfaces where you type commands and stuff happens — in much the same way that you can type a location into the address bar in order to go somewhere.

I think this is cool because, for one thing, I think language-based interfaces are seriously under-explored compared to pointing-based interfaces. For another thing, I used to work on a project called Enso. Enso’s a language-based interface, where you type commands in and stuff happens. I think we got certain things right and certain things wrong in Enso’s UI design, so I want to take another crack at doing it better.

What makes a good linguistic UI?

Here’s my current theory.

1. It’s easy to learn.
2. It’s efficient.
3. It’s expressive.

Those are the three “E”s. Let’s unpack ’em a little.