It’s often hard to remember Ubiquity’s presence and keystroke without a visual reminder—even I often forget that I could use Ubiquity and end up going to a search engine or using the search bar for some quick lookup task. What if the Ubiquity input were in the toolbar and always visible? How would that affect people’s use of Ubiquity? And what could we make that look like and how would it behave? Today we’re kicking off the Ubiquity Persistence Project, a new Ubiquity initiative to explore what a persistent Ubiquity might look like in the Firefox toolbar.
In order to facilitate this discussion, we created the Persistence tool. With the Persistence tool you can quickly try out new design and interaction ideas, mocking things up with some simple jQuery-powered JavaScript and CSS and see your changes live. The Persistence tool is bundled with our latest Ubiquity beta (install link).
I just put together a screencast introducing the initiative, demoing the Persistence tool, as well as talking about this project’s relation to the ongoing work on Taskfox. We’ll look forward to your comments and designs!
Since the dawn of time people have been asking about command chaining in Ubiquity. If you have a translate command and an email command, it would be great to be able to, for example, translate hello to Spanish and email to Juanito. This is what we call command chaining or piping: in a single complex query, specifying multiple (probably two) actions and using the first’s output as the second’s input.1
Today I hope to cover some of the technical considerations required in implementing command chaining in Ubiquity, and I will follow up soon with a blog post on the linguistic considerations required as well.
We’re going to limit our discussion here to this restriction that the two verbs are not simply two simultaneous commands, but two commands which operate successively on an input, i.e., that it is true piping. This for example rules out input such as google dogs and translate cat to Spanish, as the second command’s execution does not semantically depend on the first’s execution. This (hopefully uncontroversial) decision also affects the linguistic considerations to be made in my next post. ↩
Since we launched Ubiquity 0.5, the issue of Parser 2 performance has been brought up over and over within the community. By virtue of having a more flexible and localizable design, Parser 2 was expected to be slower than our original parser, but its current implementation felt noticeably—perhaps unnecessarily—slow compared to Parser 1. Parser 2 performance has been identified as one of the blockers for pushing Ubiquity 0.5+ to all of our 0.1.x users, and has thus been one of my recent foci.
The short story:
Inspired by some comments by Blair, yesterday I was able to make significant (roughly 100%) performance gains in Parser 2, resulting in 40-60% faster parses, depending on the query. This change has been committed and will be released as part of our forthcoming minor update, Ubiquity 0.5.4. Yay!
I uploaded Ubiquity to BabelZilla, an online community and tool for localizing Mozilla-style strings, just a couple days ago and we already have French and Polish complete.1 WOW!
Granted, these are only Ubiquity’s interface strings (for example, the about and settings pages)… the parser localization and command localization have their own processes.2 But this is still a tremendous accomplishment!
Hopefully we can roll some of these complete or almost-complete interface localizations with Ubiquity 0.5.4 which is a minor bugfix update coming soon. If you would like to get involved with localizing the Ubiquity interface strings into your language, get a BabelZilla login and sign up on the Ubiquity project page. Thanks again to our rockin’ localizers!
I received notification that the Polish localization in particular has completed testing and is now ready for release, as I was writing this blog post. ↩
Perhaps this anecdote is telling us that having a nice centralized web interface for localizers to work together and without messing with the files directly is a plus. Perhaps we should put up the builtin commands for localization on something like Pootle or Launchpad. Thoughts, anyone? ↩
I recently have spent a little time putting together a new WordPress plugin called HookPress. HookPress lets you add webhooks to WordPress, letting you easily develop push notifications or extend WordPress in languages other than PHP.
WordPress itself is built on a powerful plugin API which provides actions and filters. Actions correspond to events, so you can set a webhook to fire when a post is published or a comment is made.1 Filters let you modify some text when it is saved or displayed, so you can have your external webhook script reformat some text or insert some other content dynamically. Not all actions and filters are supported at this time, but I will continue to add more in.
There’s a webhooks meetup in San Francisco today but I unfortunately left SF this morning, so I created a video which will be played there as a lightning talk. A demo of both types of webhooks are in the video as well.
I’m really excited by this very simple but potentially high-impact plugin. I’d love to get your comments and feedback on this new plugin and hope to hear how you’re using HookPress!
It’s time for one more installment of Nountype Quirks, where I review and tweak Ubiquity’s built-in nountypes. For an introduction to this effort, please read Judging Noun Types and my updates from Day 1 and Day 2.
Today I ended up spending most of the day attempting to implement (but not yet completing) major improvements to the geolocation-related nountypes whose plans I lay out here.
Note: this blog post includes a number of graphs using HTML/CSS formatting. If you are reading this article through a feed reader or planet, I invite you to read it on my site.(more…)
Today I’m continuing the process of reviewing and tweaking all of the nountypes built-in to Ubiquity. For a more respectable introduction to this endeavor, please read my blog post from a couple days ago, Judging Noun Types and my status update from yesterday, Nountype Quirks: Day 1.
Note: this blog post includes a number of graphs using HTML/CSS formatting. If you are reading this article through a feed reader or planet, I invite you to read it on my site.
Today I began the process of going through all of the nountypes built-in to Ubiquity using the principles and criteria I laid out yesterday—a task I’ve had in planning for a while now. As I explained yesterday, improved suggestions and scoring from the built-in nountypes could directly translate to better and smarter suggestions, resulting in a better experience for all users. Here I’ll document some of the nountype quirks I’ve discovered so far and what remedy has been implemented or is planned.
Note: this blog post includes a number of graphs using HTML/CSS formatting. If you are reading this article through a feed reader or planet, I invite you to read it on my site.
Different arguments are classified into different kinds of nouns in Ubiquity using noun types.1 For example, a string like “Spanish” could be construed as a language, while “14.3” should not be. These kinds of relations are then used by the parser to introduce, for example, language-related verbs (like translate) using the former argument, and number-related verbs (like zoom or calculate) based on the latter. Ubiquity nountypes aren’t exclusive—a single string can count as valid for a number of different nountypes and in particular the “arbitrary text” nountype (noun_arb_text) will always accept any string given.
Yesterday I participated in and presented at a workshop on Information Access in a Multilingual World at ACM SIGIR in Boston. The focus of the workshop was on cross-language information retrieval (CLIR). Cross-language information retrieval systems enable users to retrieve relevant information across different languages for a certain task or query. Even if you have a budget to translate some documents from a foreign language to your language, how do you find the relevant documents to translate in the first place if you don’t speak (or read) that source language? This is the type of problem that CLIR aims to solve.
This video walks through the process of converting your Ubiquity commands to Ubiquity 0.5 with Parser 2. For more information, please consult the command conversion tutorial.
A natural language interface is only “natural” if it’s in your natural language. With this mantra in mind, we’ve been making steady progress on the challenging problem of Ubiquity localization. The first fruit of this research is in the localization of the parser and bundled commands in Ubiquity 0.5. Here today is a visual guide on command localization in Ubiquity and different options we can take in attacking the community command localization problem. (more…)
I have been accepted to present a short paper entitled “Ubiquity: Designing a Multilingual Natural Language Interface” at the ACM SIGIR Workshop on Information Access in a Multilingual World in Boston on July 23rd. I’ll probably be there in Boston a few days before or after as well in order to find an apartment for the fall. If anyone is in Boston at that time and would like to meet up, or if you’re near Cambridge and looking for an apartment-mate, please let me know.
If you would like to see a preprint of the paper, please contact me at x@x.com where x=mitcho.
