Mouse-driven love to buyers on Firefox

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.

Ubiquity in Portugal's Portuguese

I've been keeping up with some of the stirring around Ubiquity development, and one aspect that caught my attention was the adaptation of that amazing interpreter to multiple languages. I've commented before on Aza Raskin's blog about the implications of using Ubiquity in native portuguese. Mozilla's Mitcho Erlewine and Felipe Gomes have brought up the issue again. This time things appear to be moving on in Mozilla Labs for Portuguese language in Ubiquity, which is great! But please, hear me out first for a few small — but relevant — points that need to be considered. In the remainder of this post I'd like to clear them out. Note that these will be personal opinions, and I'm not a linguistics expert, only an interested software engineer.

Felipe's entire post is clear and understandable. But his ideas work for the Brazilian variant of the Portuguese language. Being a native Portuguese (and while not having any kind of grudge against non-native Portuguese), it's somehow odd (even repulsive, pardon me!) to read some of the Brazilian syntax — it's just looks badly written. One simple example is the "gimme a map" command, that Felipe translates to Brazilian as "me dê um mapa", and native Portuguese would translate it as "dê-me um mapa". But this simple example presents other cultural divergences, like the friendly/respectful tone. The English expression "give me" can be translated into "dá-me" or "dê-me" (friendly/respectful, in that order). And the same goes to the command verb "map", that would be translated into "mapeie/mapeia".

Felipe's offers the great suggestion of detecting the word's root, e.g., "map" in "mapeie". And this will work for almost every verb. Except some crucial ones, that are irregular! (I honestly hate grammar irregularities...). Take the verb "to go" (e.g., can be used in a command to go to a specific page/tab/section/<somethingelse>). So one could say "go to gmail". In native portuguese, Felipe's suggestion fails in that the same verb translates into "ir", and is used in a commands such as "vai para o gmail", or "vá para o gmail". Note that not only these commands cannot be easily traced into their infinitive form ("ir"), but both possible tones are different (the accented "a" in "vá" is very much relevant).

I'm really sorry to be a spoil-sports, but this is won't work so simply. Obviously, the set of irregular verbs are finite, and we could add the correct usages to a syntactic rules table. I expect the final code to be optimizable into a feasible speed of interpretation. But I'm not so sure that this rules can be, as Mitcho so desires, reduced to a common denominator to all languages (again, don't get me wrong, I'd love that to be possible, I just don't have a useful knowledge-base of other languages to believe that to be feasible).

And this is why I'm so fond of using some webapps' names as commands, even in portuguese. "twitter <message>", "google <query>" or "wikipedia <expression>" will be understood perfectly in Portugal (and Brazil, for that matter). I know, Ubiquity's future is about natural language interpretation, whatever idiom you may prefer. And that's really something special. But I can't stop but to feel that every language is either going to require a complex interpreter suited for itself, or suffer from aggravated syntactic-sugar syndrome.

If any point I've covered can be countered somehow, just consider, in following blog posts/projects/etc to remember to identify what Portuguese idiom are you referring to when you discuss grammar rules. Again, it's not a matter of any kind of discrimination, but one of correctness, and everybody deserves that.

Thanks for reading!