jQuery Conference Wrap-up

Greetings all!

I've just returned from an amazing trip to Boston for the jQuery Conference at the Microsoft New England Research and Development Center (aka: "The MS NERD Center"). I saw amazing presentations, met awesome people, ate great, great food, and partook in a fair amount of IE bashing like only JS and CSS developers can.

I attended sessions about Javascript and Ajax best practices, improving JS speed, accessibility using the W3C's ARIA specification, some fun sessions showing how easy and exciting theming in JS can be, and sessions about what's just over the horizon for JS and jQuery. (FYI: jQuery 1.3.3 will be fantastic.) Over the following days and weeks I'll post more specifics about the sessions I attended, but for now I want to talk about some take-aways I hope to use to improve Elgg's Javascript and Ajax.

Create (and use) a JS API in Elgg

Before I joined the Elgg core team, in each plugin I wrote I had to implement Ajax functions to show loading indicators, display success, failure, and other status messages, and to handle the Ajax replies. Blech. Elgg needs a standardised API for requesting AJAX information on both the client and server sides. This encompasses showing a loading notification, fault tolerance, and special ajax views.

Goodbye, lazy loading widgets

Profile widgets in Elgg use a technique known as "lazy loading" in which the initial page loads, then multiple concurrent requests are sent via Ajax to load the rest of the page. Used properly, this can increase the perceived speed of rendering pages in the browser. Used improperly, this can wreck havoc with the user experience...not to mention what happens when Javascript is disabled because of accessibility or system policies. When loading a few widgets per page, this approach works fine. To see it really fail, load 15+ widgets set to display the max number of elements on a single page. Scary stuff! I believe the solution to this problem will be to lazy load only selected elements of widgets--the edit view, the options view, and possibly others......and *deep breath* to refactor the caching system.

Refactoring caching (views, queries, and objects)

If you've been following the the mailing lists, trac, or the community site, you have seen a few discussions about problems with Elgg's caching. Whether it is out of memory errors, or dots in usernames, Elgg's current approach to caching is beginning to fall short. Though caching isn't immediately related to Javascript, it is interconnected in Elgg: we'll have to make sure the refactored caching system can be used with the new JS/Ajax API and widgets system.

Accessibility

This is the beast that few people wanted to talk about--or indeed, hear about--at the conference. One session I attended on accessibility had fewer than 20 participants! While there are upcoming technologies and standards that will make those of us concerned with accessibility better equiped to develop accessible sites, the reality is that this was a neglected area at the conference. The jQuery UI team is taking some good steps to ensure their widgets are accessible and degrade moderately well, but not all of them are functional yet. Of all the projects on the table for Elgg, this will be the most invasive to core and likely the most time-consuming. This is important to us, but I ask for your patience (and help!) on this one.

All in all, I left the jQuery conference with fresh, new ideas of what Elgg needs to push forward with its Javascript and Ajax support. Projects are doing some awesome things with jQuery, and I aim to make Elgg soon be one of them.