Travel Report: 2009 Baarn UI Sprint

I'm freshly back from attending the invitation-only Baarn User Interface Sprint, from Jan 29-Feb 1. The event was hosted with great success by the fine folks at Informaat. (For those who are curious, I believe that Baarn is pronounced as "BAH-hren".)

We spent the majority the first day talking about the current work being done on the Plone 4 UI and in other CMSs before breaking into smaller groups to tackle some of the main problem areas we'd identified: content editing, page assembly/layout, site theming, control panels, and interaction testing. Throughout the sprint, there was a large amount of discussion, some of it rather heated, about these topics.

I worked with the Blocks group. Blocks is a project which aims to simplify Plone's site skinning process through reducing the complexity of layout templates and finding a more grokkable (so to speak) alternative to viewlets and portlets. The nouns and verbs are subject to change, but as of now, this is accomplished through panels (replacable sections of the page) and tiles (content pulled into the page from elsewhere in the site).

Before getting to any actual coding, we spent time hashing out a way of defining panels and tiles in a way that was both straightforward and semantically (in HTML terms) correct. The goal is to maintain a balance between functionality and complexity; we don't want to invent a whole new programming language made up of HTML tags out of some misguided attempt to make things "easier". The solution we wound up with will use layout templates containing pure HTML, harnessing <links> and ids to define panels and tiles within the markup. Eventually, basic tiles will be created just by sticking an HTML file in a ZCML-registered tiles folder.

Denys and I spent quite a bit of time discussing the site design workflow. Blocks should definitely help to ease the transition from comp to template, HTMl received from the designer can be sliced up into panels by the integrator without turning it into anything that the designer can't read. In the case where those designer and integrator are one-and-the-same, it should be less of an effort to write HTML with Blocks in mind.

Unfortunately, I wound up wasting half a day trying to fix a broken install of lxml on OSX, before giving up and creating a new Ubuntu VM through Parallels. We may need to put some effort into cleaning up the process before this takes off.

Thanks to Lawrence and Jeroen, we managed to leave the sprint with an actual rendering engine, working in Plone 3, that pulled in our static HTML files and did the including and replacing. I was able to create tiles with the ability to display existing viewlets and portlets, which should ease the transition to Blocks for existing sites. Discussion and dissection of our work is already underway on the Blocks/Deco mailing list.

I'm satisfied that it will be possible to provide proper hooks in Blocks' output so that GloWorm or similar tools might determine how particular portions of the page are being generated. This means that UI tools built against Plone 4 won't need to jump through all of the hoops that GloWorm currently does.

Sprints are ostensibly all about generating as much code as possible in a short time, but to me, the main benefits of sprinting are the opportunities to enable face-to-face discussion amongst geographically-diverse contributors and to bring new developers into the project. At this extremely early stage of the Plone 4 development cycle, I expect that exactly none of the code I've written will survive through to any sort of release. However, having been drawn into the Blocks project, argued my opinions on the proposal, and committed code, I now have a vested interest in the future of the project.

I'll leave the details of the other working groups to others but I have to say that I'm very interested to further investigate the work of the testing group. They worked on creating a buildbot implementation of Selenium.rc. This should allow regular, automated testing of Plone's AJAX bits. By pointing it at VMs running different operating systems and browser versions (Snakebite maybe?), we'll be able to get a nightly check of how Plone works in different browsers. It will be extremely useful to me since so much of GloWorm's code relies on browser interaction. I know I'd sleep better at night knowing a report of any interaction failures would be waiting in my inbox the next morning.

Other miscellaneous thoughts:

• The US needs more pay toilets
• Amsterdam needs more wireless access points
• Cornelis' stupendous UI mockups made me feel like I've been developing using an 8-pack of Crayons. Hopefully we'll all get a copy to play with soon. (*hint* *hint*)
• We need one of those super-fancy coffee/latte/mocha/cocoa machines for our office.
• As usual, I remembered to take my camera to everything but the sprint itself. My pictures of my tromp around Amsterdam are available on Flickr, for those interested.

And finally, a huge thank you to my sponsors, Plone community members all, who chipped in to provide me with sufficient funds to cover my food costs, train fare, and a portion of my hotel bill.