A commenter on a previous post asks,
Also, have you thought about implementing the equivalent of *ix pipes on this?
I have thought about it extensively.
Not only that, I snuck a very, very preliminary version of pipes into Ubiquity 0.1. Try this!
- Issue “trans hello to korean”. Hit Enter to execute it.
- With nothing selected, issue “email it to “.
You see what happens? The word “it” is a magic word. (And not just because “it” can defeat the Knights Who ‘Til Recently Said “Ni”). When Ubiquity finds an “it”, it looks for things the user might be referring to. If you have some text (or a chunk of a web page) selected, “it” refers to the selection. But if there’s no selection, “it” refers to the output of the previous command.
(There’s actually a whole list of magic words — “it”, “this”, “selection”, even “him” or “her” — Ubiquity treats these all the same way as it does “it”.)
Because there’s a chance that the user doesn’t want the selection or the output of the previous command, but really just wants to email the word “it” to somebody, Ubiquity also produces a literal parsing of the sentence with no interpolation. The literal interpretation appears in the suggestion list right below the one that uses the selection, so if you don’t want to use your selection, you can get the literal sentence by tapping the down-arrow key.
One problem with this feature that we’ve noticed already is that it’s too easy to accidentally get your selection, or the output of a previous command, when you don’t want it. You might be typing a long sentence with the word “it” in the middle, and not even realize that interpolation is happening until you’ve already hit “enter” and it’s too late.
So! It’s very basic, clunky to use, completely non-discoverable, easy to trigger by accident, and implemented in a terrible hacky way (”output of previous command” is literally just a single global text buffer), but at least there’s a way to send the output of command 1 to the input of command 2! So very primitive pipe-like functionality does exist.
Among other much-needed improvements, I want to make it possible to put both commands in a single line of input, using “and” as another magic word that acts like a pipe character for that pseudo-natural-language goodness:
trans hello to korean and email it to mom
Also, it’s pretty lame that you currently can’t use the pipe mechanism if you have a selection (because the selection, if there is one, always takes precedence over any previous-command-output.) You should be able to type “it” and have all three choices: the selection, the output-of-previous-command, or the literal word “it”.
Next, you should be able to use multiple, persistent, named buffers to do stuff like this:
trans this to korean and remember it as kr-textetc!
twitter kr-text
encrypt kr-text with mom's public key and remember it as kr-crypto and email it to mom
remember selection as my-address
email my-address to mom
insert kr-crypto
It’s the equivalent of redirecting output to a named file, as you *-nix mavens no doubt already noticed.
Finally, we can do a lot more with this conept than just re-implementing the Bash shell inside your browser. There’s a very simple and powerful underlying idea here: that you should be able to type a pronoun and have the interface guess what the pronoun refers to.
Sure, the interface isn’t going to guess right all the time. But that’s why we have a suggestion list: if the first guess is wrong, the user can get to the correct interpretation with a couple of down-arrow keystrokes. So guessing wrong about what a pronoun means is a very low-cost error.
There are so many data sources that Ubiquity could pull from in order to guess the referents of pronouns! We’re not limited to just the output of the previous command and the user’s current selection. We can build up a “short-term memory” in the browser that holds all the things the user has recently interacted with, because these are clues as to what the user is thinking about, and therefore clues to what the user might be referring to when they use a pronoun in a sentence.
For example, data sources that could be part of the short-term memory include:
- the current URL
- the user’s recent browsing history (potentially accessible through Weave)
- the user’s bookmarks (also accessible through Weave)
- any other data that makes it into Weave in the future, such as contact lists
- microformats embedded in the page
- the inputs and outputs of my last ten commands
- etc, etc, etc!
So for example, suppose you’re using Awesome Future Ubiquity and you type “email it to her”. Awesome Future Ubiquity should be smart enough to realize that the word “her” always refers to a person, so it looks through its short-term memory for a piece of data that might refer to a person. It could look for a microformat in the current page that describes a person, as well as looking through the people who are synchronized in your Weave account, and people you have referred to in recent commands, and come up with a list of the top five people it thinks you might mean, sorted based on your recent e-mailing history.
One of the many reasons that using computers is so annoying is because computers can’t figure out what you mean even when it would be incredibly obvious to a human. They have no ability to guess your intentions from context. It’s time to challenge the assumption that computers have to be this way.





August 27, 2008 at 10:25 pm
There is always room in my life for more awesome, and Ubiquity is rapidly confirming that.
Thanks!
August 27, 2008 at 10:54 pm
Nice post. I might have to try and teach myself proggramming just to help on this project
August 28, 2008 at 8:42 am
The prospective syntax for named buffers seems a little unwieldy to me. How about also allowing something like this (in addition to the “remember…” syntax):
kr-text: trans this to korean
That is, a string followed by a colon at the start of the input is treated as the name for a buffer. This becomes more intuitive when you consider a list of things to do:
1: trans this to korean
2: trans this to french
3: trans this to dutch
email 1 to fred, email 2 to wilma, email 1 & 3 to barney
August 28, 2008 at 10:55 am
How about making “that” a magic word which always refers to the output of the previous command?
So you have “it” as a DWIM command, but have “selection”, and “that” as more specific versions.
“trans hello to Korean and email that to Mom”
Also, you could make it refer to the output of the previous command by default if it’s the second section of an “anded” command.
August 28, 2008 at 3:49 pm
What about another magic word ‘page’?
I asked a question about this on the Satisfaction page concerning the translate command, which doesn’t play nice when trying to translate an entire page in one shot after hitting ctrl+a… so what if we could issue
trans page
or
trans this page
And all of the text on the page would be translated… this is opposed to selecting and translating individual sections ad nauseum.
August 29, 2008 at 6:09 am
[...] my must-read list, Jono’s Not The User’s Fault and Aza’s Thoughts. Here’s what you can expect: One of the many reasons that using computers is so annoying is because computers can’t figure [...]
August 29, 2008 at 9:55 am
“it” is really great; but somehow I’m more intrigued by “these”…
working on sets of objects with the flexibility and composability of a commandline could be quite fun.
eg. on a meeting page, ’stalk attendees and filter these by contact-type, map them using contact type for colour, photo for icon.’
Is that plausible?
Do you see any potential commonality with http://mqlx.com/~david/parallax/ ?
August 29, 2008 at 10:21 pm
Have you considered the challenges of complex grammatical constructs in an internationalized context? Do you think the magic words can be just “translated/replaced” in different languages?
September 1, 2008 at 3:57 am
Raziel:
Yes I have. A post about localization of the parser is upcoming. I have a proof-of-concept prototype of a parser for Japanese, which uses Japanese grammar (verb at the end, nouns marked with postfix particles).
I believe most of the magic words will have simple equivalents in other languages. The Japanese parser uses “これ” (”kore”) for “it”/”this” and I think it reads pretty naturally.
Though of course, we will run into problems there that we never anticipated.
September 1, 2008 at 9:15 am
I just realized that freebase and ubiquity could mean very cool things together. And I also saw the mention of parallax here, which was new to me, but it looks very cool.
September 2, 2008 at 2:05 pm
I really like the “and” idea as an equivalent to the | pipe character. Not only is it really powerful but it’s really natural, I’ve found myself typing it by accident as though I expect the pipe to happen by magic.
It would always be followed by a command so that should in principle limit the possibility for errors.
Absolutely loving Ubiquity, most exciting development in years.
September 4, 2008 at 7:25 pm
[...] C. Noun-first completion and interpolation of the selection are a good start. But it will be a lot better once the suggestions are sorted, and once there are a few more magic words, and once interpolation of the selection can automatically go to any argument in the sentence. Ubiquity should be able to guess what I mean from context much more often than it currently does, as I described in this post. [...]
September 8, 2008 at 3:18 am
Great work! requiring “it to” will increase the intentionality.
September 9, 2008 at 10:18 pm
Awesome! I agree that “and” would be a very natural way to concatenate commands. Looking for “it preposition” and “and verb” would be a good way to minimize the ambiguity in suggestions as well.
Another possibility for linking commands in a single line is the comma. For example, a user might try to type:
“trans Ubiquity is awesome! to japanese, bold it, and email it to mom”
In this case, Ubiquity might see the comma as an “and” and be able to figure out correctly what the user wants to do.