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.

ELS 2009 - my impressions

I've finally got to attend an international Lisp meeting — one more item crossed off the checklist!

The European Lisp Symposium 2009 was held in Milan, Italy, during the 27-29 of May. The program featured some interesting presentations, and while I'm not going to go a complete overview of them all, in this post I'll go over the bits that got into my head the most. This means, don't be offended or ignored if your work (or the work you were expecting to read about) isn't mentioned here. It probably means my mindset isn't properly configured, yet :)

The first day of the conference was just the reception, where I got to meet great people. Among the entire conference I got to meet people I've already read about in the web-o-sphere such as Stellian Ioanescu, Scott McKay, Mark Tarver, Nikodemus Siivola, Pascal Constanza and Christopher Rhodes. I also got to know some nice people I didn't know, including Didier Verna, Jim Newton, Claus Brod and Edward Dogde. António Leitão, my PhD supervisor and program commitee chair, introduced me to Mark Feeley, from Termite and Gambit Scheme, who told me about a Gambit package, JSS (a multithreaded javascript compiler), which I must try when I get back home. Most of all, despite some ideological divergences between some of the participants, the mood was quite pleasant, and joyful. After all, Lisp is supposed to bring happiness to those who use it.

The second day started with a Scott McKay talk on his life's experiences, and mistakes. He has grown a pretty strong aversion to incremental code fixes to correct fundamental problems. Pretty much all he's done made him believe that full rewrites gives us the opportunity to think better about the design, and that we cannot try to simplify the code by extending it. He is also concerned about the current "big thing": concurrency. May languages are addressing it, and Common Lisp is getting behind each day that passes. Clojure tackled it, but it carries the known set of burdens. Scott recognizes the great one-man effort, but wonders if it's easier to improve Clojure or to design a new Lisp and get it right from design. This could rapidly solve, for instance, the namespaces Common Lisp problem (instead of having symbols, packages, labels, macros, symbol-macros, etc, etc (Pascal counted 9 different namespaces), we could have one single namespace). The same goes to the type system, *everything* should inherit from the same root object type.

Mark Tarver gets an almost similar position, but he "strayed away" from Common Lisp, and went looking for answers on both Scheme and Python. Because he couldn't find them, he designed Qi, a language that is supposed to offer what he believes to be the best language features.

I found the presentation on hygienic macros for the unhygienic world quite motivating. By using a few helper macros, Pascal Constanza demoed how we can emulate the former on Common Lisp, which is quite useful, specially if you come from the Scheme world. All at the expense of a few extra language constructs, but not too distracting ones.

Charlotte Herzeel presented an interesting approach to implement Software Transactional Memory (STM): she implemented a (limited, not feature-complete) Scheme interpreted within Common Lisp. Doing this allowed her to have access each memory access point easily (she only has to address cell and vectors accesses. The thing is, by having her interpreter, she easily tapped to the code segments where data access is done, via reflection. So it becomes easy to experiment with STM algorithms.

I found out the industry is not sticking to widespread CL implementations. At least three different companies (mostly related to the CAD/graphics world, but I think it's a coincidence) rely on SKILL, or some adaptation of it. SKILL is a small footprint Lisp-like scripting language, and that makes it appealing for many industrial domains. However, it appears to be quite obsolete, undocumented and unsupported. It was nice, though, to see some successful uses of Lisp.

I was kinda disappointed not to see Kent Pitman, I believe he canceled at the last minute. I was also looking forward to see some Clozure CL people there, I'd like to hear about what they have in mind about Cocoa and iPhone development. They already have a great Objective C bridge, but as a Common Lisp, things are entitled to be much easier, specially in order to produce competitive small products (there's a big niche for small simple applications on MacOS, due to Apple's design principles)

Marco Antoniotti was a great host on Milan. He organized a great banquet at Osteria del Treno, where we all got to share some more insightful comments about the entire conference and more. The day after that, Marco wore the cicerone cap and took everyone that was still in Milan for a great Futurismo Exhibit, where we got to learn some amazing bits of the Italian cultural inheritance (definitely not my area of expertise, but it was quite interesting to try to interpret some works and sell my ideas to the guide, despite failing most of the times :) ). That afternoon we visited the Duomo, a massive cathedral on the center of Milan. The most impressive thing for me was to realize the wow-factor was even greater from inside of it (on it's roofs), than from the outside!

All in all, it was a memorable experience, everything went great (i wasn't even bugged with the wireless access difficulties that so many people were forced to have, since i had the eduroam credentials already set up on my machine!). Next year it'll be in Lisbon, so I'll be attending to. Meanwhile, I'll look forward to go to Italy again on July for the 6th European Lisp Workshop (within ECOOP).