Vision and Goals


jQuery UI provides developers with effects, interactions, low-level UI utilities and flexible, fuller-featured widgets that make use of these UI utilities to form common UI patterns.  We aim to provide a comprehensive set of accessible, themable UI widgets and utility plugins in a jQuery-style, event-driven architecture (find something, manipulate it).

 

Collaborative design process

 

The process for designing and planning the future of the jQuery UI library should be open, transparent and in the hands of the community. We welcome input from anyone interested in engaging with the team, from hard-core developers to visual and interaction designers, accessiblity experts, product managers, business people, end users and more. This wiki is completely public and in meant to compliment the Developing jQuery UI Forum so feel free to jump in and start participating.

 

Flexible styling and themes

Widgets should provide hooks to enable developers to customize both behavioral and presentational aspects. Transition animations should be optional and customizable. Class names used on internal elements should be meaningful to jQuery UI users and enable styling either through ThemeRoller or hand-written CSS via the jQuery UI CSS Framework. As much as possible, style attributes should be separated into the plugin's CSS, not within the scripts in order to make customization simple and clear. Widgets styles should be coded with proportional (em-based or % based) sizing and should re-flow horizontally to fill the space provided.

 

Elegant visual and interaction design

All widgets should be designed for simplicity, ease of use and aesthetics. We aim to synthesize best practice examples from mobile and desktop OS, web applications and a bit of common sense to create a robust and flexible set of UI widgets that is visually coherent and consistent in behavior. Features should be pared down to focus on what is practical and commonly needed with a system for extending features through customization.

 

Elegant API

The jQuery UI API is designed to be as simple and intuitive as the jQuery API. You find elements using a query selector, then call a succinct method on the resultant set. There are suitable defaults to cover the most common use cases, so quite often it's not necessary to specify any non-default options. All options are optional.

 

Progressive enhancement

Since we're developing non-native HTML controls, widgets should be built in such a way that users on browsers and devices that are unable to support Javascript can still interact with the website or application. Most of the current set of UI widgets follow the best practice of progressive enhancement and we're working to extend that pattern to widgets that don't. In most cases, advanced components can be generated from HTML primitives (i.e. slider from select menu, radio set, or text input), and as the UI library paired with the most popular javascript library in the world, we should lead by example in this area. Any UI widget that sits within the flow of a form should be able to store data using semantic HTML elements so the form can be submitted or serialized normally. jQuery UI components should follow the unobtrusive practices put forth by jQuery itself, and should attempt to be forward-looking in its attempts to normalize across browsers and devices (test for features/bugs, not browser sniffing).

 

Deep accessibility support

Widgets should also be accessible to JavaScript-capable users who have disabilities such as blindness or deafness (should we ever venture into the arena of audio/video integration, for instance). We attempt to make components accessible through the use of semantic HTML elements within components and following the guidelines specified in the WAI-ARIA spec. Any image-based actions within widgets should provide text equivalents (close icons, expand/collapse icons, etc. should have title attributes at the least).

 

Internationalization and localization

Given the global audience for jQuery UI, we should embrace the ability to make our plugins work in a variety of languages and cultures.  By abstracting language away from the core plugin code and providing options for supporting cultural differences (right > left reading orientation, date and currency formats, iconography, etc.) we can build in the flexibility needed for a global community. The current datepicker plugin currently implements an extensive system for supporting internationalization and localization.