Proposal for Dojo in Fluid

Proposal for Recommending Dojo as a Primary JavaScript Toolkit

At the Fluid Summit in September 2007, the technical group discussed a number of JavaScript toolkits and agreed to propose the use of Dojo for development of new Fluid components. This is an issue we're still considering, and are very interested in broad feedback from the community.

Draft Recommendation

We recommend using Dojo for development of Fluid components. The primary motivation for this decision is the Dojo community's strong emphasis on comprehensive accessibility for their Dijit widget set. We currently feel that the accessibility features provided by Dojo will enable us to focus on the larger usability and accessibility challenges of cross-cutting components, saving us from having to add accessibility support to each of the individual widgets we reuse from a toolkit. Dijit accessibility support includes:

• Compatibility with assistive technologies via inclusion of Accessible Rich Internet Application (ARIA) roles and states on each widget
• Comprehensive keyboard accessibility
• Support for high contrast mode on Windows
• Comprehensive testing with screen readers (JAWS & Window Eyes) and accessibility evaluation tools

With this recommendation, Fluid will commit to playing a more active role in the Dojo community, helping to support and influence its development.

This is ultimately only a recommendation. If a compelling widget is found outside of Dojo, we should feel free to use it within a Fluid component if necessary. However, choosing another widget entails the following responsibilities:

• Consultation with the community before making the decision to use an alternative widget
• Ensuring widgets are accessible and consistent with other widgets in their behaviour

Mixing and Matching Widgets

One of the primary reasons for recommending a single JavaScript toolkit is to ensure consistency across widgets. The risk of the mix-and-match approach is that subtle, user-facing interaction details may vary between widgets in different toolkits.

Where we do choose to reuse widgets from an alternative toolkit, we need to maintain low-level interaction consistency. Drop-downs, focus and selection handling, and keyboard interactions need to be identical across widgets. Visual appearance also needs to be consistent. In the long term, we'll develop a style guide that helps to outline these expectations, but in the meantime we need to be very careful when choosing to reuse widgets from another toolkit.

Non user-facing behaviours, such as utility functions, DOM querying, and even drag and drop can likely be culled from any toolkit that best fits our needs. Obviously, reusing libraries from a single toolkit will significantly cut down our download size and number of dependencies.

Ongoing Concerns

The ongoing concerns about Dojo are centered around two main technical areas: 1) the suitability of its architectural approach within the hostile environment of a portal, and 2) its ability to sufficiently integrate with existing server-side presentation frameworks. Non technical concerns relate to the design of Dojo's widgets. Given that there are no interaction designers working in the Dojo community, are the Dojo widgets sufficiently usable and well-designed to support Fluid's design values? If not, is this an area where Fluid can productively contribute expertise?

Revisiting this Recommendation

The success of this recommendation to use Dojo hinges on the value provided by the Dijit widget set to Fluid component developers. If we find ourselves reusing a lot of Dijit widgets, and inheriting their built-in accessibility without significant modification, Dojo is clearly the right fit for our needs.

If, on the other hand, we find ourselves modifying large parts of Dojo to integrate successfully into Sakai and uPortal (as was the case with its Drag and Drop library), or we don't reuse a lot of widgets, then we will undoubtedly need to reconsider our approach. With this in mind, I'd like to suggest that we revisit our decision to use Dojo periodically over the next few milestones, assessing its success in context of the components we've built to date. Prior to the 0.3 release (scheduled for March 2008), we'll make a final call on Dojo and either fully embrace it as a platform on which to build components, or port our existing components to an alternative toolkit.