Two weeks ago we held the first Fluid Summit meeting here in Toronto. It was a resounding success, and I’d like to thank everyone who attended and brought their ideas and proposals to the table. We had a very full week of planning, coding, and designing. Members of the Sakai, uPortal, Moodle, and Kuali Student communities were all present.

For those of you who are interested in Sakai, if you haven’t already read Michael Korcuska’s blog entry about his impressions of the summit, I’d encourage you to take a look. He’s done a great job of outlining his perspectives on our work and Fluid’s role within the Sakai community.

We also had strong representation from the uPortal community, including Eric Dalquist from UW-Madison, Paul and Jens from UBC, and Jennifery Bourey and Susan Bramhall via videoconference from Yale.

Moodle was represented by the crew from York, who brought with them interesting results from their recent UX Walkthroughs as well as a sneak peek of the new Open VULab remote testing product. Keep an eye out for more information from Ron and his team about the VULab in the coming weeks.

It’s been a busy two weeks with lots of project coordination tasks arising from the summit, but here’s my long-awaited summary of the week:

Project Vision and Roadmap

As a whole group, we discussed the project release plan and vision. The release plan outlines the timing and deliverables for each of our quarterly release milestones, starting with a 0.1 version of the Fluid technology and UX Toolkit later this month, and culminating in a 1.0 release in March 2009. More detail needs to be fleshed out in this document based on the results coming out of our design working groups, but I think it outlines the overall structure and deliverables of the projects quite well.

The vision statement is a work in progress. In my mind, the challenge of writing a good project vision is to capture the goals and philosophy of the project at a high level, while still managing to keep it succinct and focussed. I’ll be revising this document in the coming weeks, and I’d appreciate any feedback you may have.

Architecture

The technical group discussed the latest overview of the Fluid architecture plan. One of my goals in revising the architecture overview was to provide more information about the current reality of the Fluid framework and a clearer picture of how we think the framework will evolve as we build new and more complex components. Many of the technical discussions at the summit centered around the requirements for a contract between client and server. In time for the 0.1 release, we’ll be creating comprehensive documentation about the contract of the Reorderer and other Fluid components within the wiki.

We also talked a lot about how a Fluid component is defined from the technical perspective. In short, a component is a reusable, embeddable chunk of user interface can be adapted to suit different contexts. A Fluid component is more than just a widget, embodying a larger workflow or activity within the system that may cut across multiple tools or portlets.

Technically-speaking, Fluid components are built using JavaScript, HTML, and CSS running on the client. Component logic is composed from smaller units of functionality, providing a built-in model for flexibility and adaptation. Layout handlers, keyboard bindings, and other UI behaviour can be extended or customized by setting properties of the component. A component collaborates with service logic on the server, including the request handling and markup generation capability of a server-side presentation framework.

I’ve pared back some of the fuzzier aspects of the architecture, including the component container, since we haven’t yet seen a need for strict life cycle control over components. I suspect that as we build up larger components with a lot of configurable properties, we may reintroduce the concept of a component container to handle some inversion of control functionality on the client. This will help make it easier to build a component out of parameterizable chunks of behaviour and wire them up at runtime. In the meantime, our approach to using standard markup and RESTful server-side conventions provides sufficient support for pluggable, reusable UI components without need for the container.

Client-Side JavaScript Toolkits

Joseph Scheuhammer presented an analysis of JavaScript toolkits, outlining the issues to consider when selecting a toolkit for Fluid. I think this is a very insightful analysis and is worth taking a look at.

Simon Bates presented the accessibility work his team here at the ATRC has been doing on the Dojo Toolkit. It was clear that the work invested in Dojo accessibility has the potential to provide a substantial benefit to Fluid, allowing us to adopt and reuse the Dijit widget set without having to write a lot of extra code to make them accessible. Dojo is the only toolkit to date that has made a commitment to built-in accessibility. On the other hand, the technical group at the summit raised some valid concerns about Dojo’s architectural approach, particularly in light of our desire to leverage server-generated markup where appropriate.

Ultimately, the technical team at the summit agreed to bring a draft proposal to the community recommending the use of Dojo for building Fluid components. We’re still free to use non-Dojo widgets where necessary, but there will be a greater responsibility to ensure consistency and accessibility if we do so. With this recommendation comes a commitment to get more involved in the Dojo community and help to support and influence its direction.

I’ll send out a separate email documenting this proposal soon, and we’d like lots of feedback from the community about this decision. Given the lingering concerns about Dojo’s fit with Fluid’s architecture, we’ll revisit this recommendation over the next few months to assess its success.

Server-Side Presentation Frameworks

The technical team at the summit chose not to recommend a particular server-side presentation framework at this time. Instead, our approach is to incrementally define a set of requirements that any server-side presentation framework may conform to. We’ll build these requirements up as we create more examples of Fluid components and refine their communication with the server. Ultimately this will lead to a thin binding layer between client and server that we will implement ourselves in at least RSFand uPortal’s XML-based presentation pipeline. Spring Web/Portlet MVC is being considered as well. Users of other presentation frameworks will be able to implement this binding layer in their technology of choice, and are encouraged to do so.

During the technical sessions, we all recognized the hard work that Antranig Basman and the RSF team have invested in making RSF excel at delivering the markup and bindings required to enable cross-cutting user interface components on the server-side. If you’re working on a new tool or portlet, I’d suggest giving RSF serious consideration. I think there is going to be a lot of complimentary back-and-forth between the Fluid framework and RSF, particularly around the Universal View Bus, RSF’s strategy for client-side messaging.

Coding Session and Technical Working Groups

On Thursday, the technical group broke up into smaller teams to do some coding and flesh out a few key areas for the Fluid architecture. Eric, Anastasia Cheetham, Joseph, and Antranig all worked on integrating the Reorderer with uPortal’s drag and drop layout preferences. This will provide a more accessible solution for directly rearranging portals, tabs, and columns, and is expected to be complete in time for the uPortal 3 release in December. The technical solution cooked up by this team is really quite remarkable, and you can find more discussion of their work on the uPortal-dev and fluid-work lists.

Aaron Zeckoski and Michelle D’Souza worked on a new accessible AutoComplete component based on the Dijit ComboBox widget. While in itself this is a very small component by Fluid standards, Aaron and Michelle started in on the coding work required to make all Dijit widgets bind seamlessly with RSF.

I missed out on most of the coding session, but had an opportunity instead to discuss the challenges of user experience development in open source communities with Sakai’s new ED, Michael Korcuska, and a few of the Sakai board members who were at the summit. I’m really impressed with Michael’s work so far, and am looking forward to Fluid’s involvement in the new Sakai UX initiative.

User Experience Working Groups

One of my favourite things about leading the Fluid Project is the opportunity to be involved in the design process with our UX experts. Unfortunately at the summit I wasn’t able to spend as much time in the UX meetings as I would have liked, but the team has posted a great summary of the topics they discussed and their planned next steps.

During the week, the UX group worked extremely hard to sift through a lot of raw data collected during recent UX Walkthroughs. They identified a number of problem areas that are common across all our participating projects, and prioritized them based on both the frequency and severity of the problems. Based on this, the UX group has formed a number of smaller design teams that will delve deeper into specific areas and start designing solutions for the highest-priority issues. These teams will be creating new designs in the areas of Navigation, User Feedback, File Management and Workflow. It will take a bit more time before we start to see implementable components emerging from these working groups, but I’m enthusiastic about their progress to date. If you haven’t already, please consider getting involved in one of the groups and helping to design new Fluid components.

Wrapping Up

The most remarkable part of the summit for me was the combined sessions held with the whole group of 30 or so attendees. It was clear to me that we’ve built an effective community of contributors who are dedicated to fostering usability and accessibility within our projects. Over the five days of the summit, we worked through a vast array of topics, defining solid plans and next steps for all aspects of the project.

Now’s a great time to get involved in Fluid. Join a design team, contribute to the technical development, or lend a hand preparing for the upcoming 0.1 release. If you’d like to help out, or have questions about our work, please feel free to drop a note to the fluid-work mailing list or get in touch with me directly.