A while ago I was amazed by the truly great work that the Mozilla Labs team did on their project Ubiquity. If I ever thought about a web-based operating system, this all-in-one launcher is anything I'd ever need: fast, useful and easy to extend. Right now the development is going towards a better integration with the "normal" browser usage, melting it's UI with the amazing toolbar.
There are, however, a huge piece of the user pie that aren't that fond of writing, or using the keyboard, unless absolutely required. I've heard about some prototypes with a mouse-driven ubiquity, but as far as I know that idea never took off. There's still time, though, and all these firefox extra-functionality are pretty much in early development stages.
So it was half surprised and half amazed that I watched as two of the master-minds behind Ubiquity (Aza Raskin and Atul Varna) releasing another revolutionary project from their labs: Mozilla Jetpacks. Jetpacks are a way to extend the browser by using a set of Javascript instructions. The main motivation is that up until now we had to grasp the XUL doctrine just to make a popup message greeting the user, and it's easily seen that the amount of Web developers that already tamed some Javascript is growing by the minute.
Wait a bit, I was babbling something about mouse-lovers getting some attention, and I was just getting carried away... That's true: Jetpacks architecture allows certain Javascript objects/functions to interact with certain browser features (statusbar, menus, making HTTP requests, etc.) One of the newcomers into the recent feature-list on its API is called the Slidebar. It's just like a Firefox sidebar, but it stays hidden unless we hover on a small arrow on the top-left corner - then it slides and shows us icons for each slidebar jetpack we have installed. The first slidebar I've seen was the Wikipedia, allowing users to select some text, click on the Wikipedia icon, and see the mobile Wikipedia page for the selection on the slidebar. Pretty sleek - specially if you don't want to fire up Ubiquity, type "wi" and watch the preview window assuming the "wikipedia it" completion and showing up the results inline. And I know there's people like that :)
I quickly thought to myself that most reference websites would be much easier to access there (as opposed to, e.g., the search-bar, where I find it clumsy to switch between search-engines). But I've also thought it would bring some advantage to Ubiquity in one simple aspect: user input. We're confined to a single sentence on Ubiquity. And despite being oh-so-cool to parse natural language and extract the right meaning out of it (because it is!), some things take more than one sentence to say clearly, and there's no way around it.
I thought about the command I've made for Ubiquity to add financial transactions to Buxfer. The syntax I accept on it is "BUXFER-SPEND <amount> in <description>", where <description> may be a set of words with arbitrary length. My problem with this is twofold. First, it's not easy to extend this with other parameters (like the date of the transaction, its tag(s) ...). Then, a technical issue makes the command keep presenting one completion suggestion per word on the description. (it has to do with not being the direct complement, i think. And doing a manual parser is *not* fun to developer on a sunny afternoon!) And that just sucks...
So my idea was to take advantage of a slidebar to show a form, already filled with the selected text on the browser. The form has the focus on an amount text field, and a submit button (extra fields are easy to add later. Just ask me if you need any particular data to be posted, and I'll look at it). I picked up my ubiquity command code out of my shelf, and used most of it to connect to Buxfer (using its API). Besides the command itself, I had to use a different message display mechanism. I was thinking about giving Yip a try, but it turns out the notification system on Jetpack is perfect as it is - Growl and toaster goodness for everyone (don't know about linux, feel free to show me screenshots with their standards notifications!). Sorry Abi, I'll keep Yip to use on web apps, for now :)
One thing that slowed me down a bit was to find out the Utils object we have on Ubiquity is not on the Jetpack API. But that's pretty much ok, since we have the jQuery framework at our disposal. This way, instead of using the JSON decoding mechanism i used on Ubiquity, I used the jQuery ajax() and getJSON() functions to return native objects instead of JSON strings. And all is good in the world!
Some conclusions out of this fun experiment - great frameworks allow doing great features easily and, more importantly, they allow to have fun when programming them.Just the Bespin being there for anyone to give it a quick test-drive is enough to capture youngster's attention (I just keep trailing back the text to my Emacs buffer using the It's All Text! addon). So I give 10/10 to the Jetpack/Ubiquity efforts (taking into account their early state of development, obviously). Also, I ask those projects developers to unify their support as much as they can. Ultimately, I think an Ubiquity command should be one of the ways a Jetpack could extend the browser!
Without further ado, you can find my command, Buxfer Jetpack here. It should "just work" if you have Firefox with Jetpack installed. If you run into any issues, tell me, so that I may learn what they are and how to fix them. And prevent their repetition!
It's running late, but it has sure been fun to do this. The best part? I may be using this jetpack myself, complementing ubiquity's command. And that makes me being feeding myself with my own dog food.
