Developing a JavaScript Library for Yahoo!

By YUI TeamFebruary 17, 2006

When we set out about a year ago to build the Yahoo! User Interface Library, we had a specific set of challenges to address. First and foremost, we wanted to enable our front-end engineers to spend more time working on advanced, product-specific features and less time doing cross-browser tuning of generic interactions like drag and drop. We have a deep, talented, and creative pool of developers across the company, but we hadn't done enough to develop shared libraries that normalize differences across relevant browsers. As a community, we agreed that we needed better toolkits for those rich interactions that can enhance users' experiences of Yahoo! products.

Creating the library represented a significant undertaking, and we spent a lot of time talking among the larger front-end engineering community here about how to go about doing this. Having now made the library publicly available as an open-source, open-use resource, we wanted to share with you some of the thought processes driving our engineering agenda.

Heterogeneity

We talk a lot at Yahoo! about heterogeneity, a word that describes an essential part of our company's challenge across numerous disciplines. With respect to improving our shared JavaScript libraries at Yahoo!, heterogeneity defines the problem in two important ways:

  1. Heterogeneity of the Yahoo! Product Family: Yahoo! products are diverse in terms of their size, the technologies we use, our development methodologies, and our locations geographically. More importantly, perhaps, our users and their needs vary significantly from product to product. As a result, some properties have been able to implement very rich feature sets, whereas others have proceeded more conservatively in defying the page-granular interaction paradigm that came to define the first decade of the mainstream web. Given this context, the library needed to facilitate application enhancement without dictating too much about how architecture, methodology, or coding style.
  2. Heterogeneity of client configurations: Yahoo! has, by some internal estimates, more than 10,000 different client configurations accessing its products on a regular basis. While we can distill that into more manageable groupings (like "IE 5," "Safari 1.3," "Netscape 8+," "Mac FireFox 1.5+," and so on), there remain dozens of viable browser/platform combinations in use by millions of people each. Writing JavaScript for dozens of run-time engines and accessing dozens of implementations of DOM methods can be a recipe for paralysis — it naturally leads to conservatism with respect to making commitments for advanced features. A library that serves the needs of developers facing this degree of client-side heterogeneity must first and foremost build upon a coherent philosophy of browser support. Nate Koechley has been working on this effort for several years at Yahoo!, and he shared our philosophy publicly for the first time in conjunction with the release of the library earlier this week. Growing out of that important work, our library had to provide normalized access to advanced functionality while supporting all of what we're calling the "A-grade" browsers.

In these two important ways, the creation of a JavaScript library with maximum usefulness for Yahoo! developers involved being sensitive to the heterogeneity that's at the core of the front-end engineering discipline. This led us in the direction of modular components and an à la carte implementation style, one that could be used in a lightweight, unobtrusive way as properties began to add specific rich interactions to existing pages. By the same token, the library in the aggregate should provide broad support for properties whose design ambitions were more transformative, who wanted to create extremely rich and fundamentally event-granular applications. And that support had to be relatively unconstrained in terms of development methodology and programming style. While we love Rails creator David Heinemeier Hansson's description of how "constraints will set you free," we couldn't serve well our developer population if we didn't acknowledge in the library's design that their environments were already large, complex, and not susceptible to radical change. The library had to impose few constraints and live happily in a lot of different ecosystems.

The Browser as a GUI Platform

If heterogeneity drove our decisions about how to architect the library, it was an old picture of an upside-down triangle that influenced us most in creating a roadmap and an organizational structure for our work.

The browser environment today shares significant common ground with where the desktop GUI industry was ten or fifteen years ago: Toolkits are comparatively new, platforms are awkward, and it's too hard to bridge the gap between a great interactive design and real-world, cross-platform engineering implementation. While part of the problem lies in the fundamental protocols of the web, which was never meant to be a platform for deploying desktop-like applications (at least, not without the help of a Java plugin), a significant part of it lies in the browser itself. Modern browsers are tantalizingly close to making rich application development realizable and robust, but the work is still too hard and the foundation too wobbly. Early Macintosh and Windows developers often felt just this way in the early days of the desktop.

In 1995, Alan Cooper (in About Face: The Essentials of Interaction Design) created a model for how to think about the GUI ecosystem, and that model — he wrote about the desktop, but it's enormously relevant to today's browser — provides a wonderful picture of how an in-browser toolkit serves the larger goal of creating exceptional user interfaces:

Cooper's GUI canon

For Cooper, the basic granules of interaction were called "primitives" — the mouse click is a primitive unit of input; combinations of primitives that took on more coherent units of interaction or intent were considered "compounds"; from compounds, application-specific "idioms" could be authored.

We took Cooper's model and re-cast it in terms of the browser and specifically in terms of the challenge of creating a toolkit to enable effective GUI development for web applications. Components that dealt with Cooper's "primitives," the most granular elements of interaction, we called utilities. Among our utilities, some (like Connection Manager, encapsulating XMLHttpRequest transactions) don't have any intrinsic visual characteristics and so would be, in Cooper's model, perhaps something like a "sub-primitive." But that's how we thought of that bucket.

Having built five utility components targeting the rich interactions most in demand among Yahoo! user-experience teams, we've turned our attention more recently to the level Cooper calls "compounds," to a class of components we call "controls." We consider controls to be highly recognizable visual presentations that allow users to interact with information quickly and intuitively. Controls, like Calendar, Slider and TreeView in our initial library release, should be familiar to users from the desktop world, should require virtually no discovery or learning in terms of their basic interaction, and should be easily invoked on the web page with just a few lines of code. The desktop paradigm, of course, has dozens of widgets; we don't aim to be that comprehensive, and yet it's clear that a lot of work remains for us to more fully populate our collection.

An interpretation of that canon, applied to web application design

As this foundation of utilities and widgets grows in depth and breadth, we hope that application designers will be more free to create what Cooper calls the "idiom" of the application — that set of interactions, workflows, shortcuts, and visual treatments that allow a user to get into a highly productive sense of oneness with her underlying data. Great idioms, not great libraries, toolkits or frameworks, are the essence of great applications.

Going Forward

We are early in the process of building the Yahoo! User Interface Library. Fundamentally, we see this as a body of components that maps to Cooper's inverted pyramid — utilities that normalize and add power to basic interactions in the browser and controls that provide a rich, familiar set of interactions within the interface. There is no magic pixie dust here: Good application idioms emerge only from diligent research, inspired design, and a committed engineering process that draws on all available tools at hand. This library is just one of those tools, and ultimately a small (though, we hope, useful) part of the much larger process.

Going forward, our goal is to improve the existing utilities and add new ones where we see good opportunities. At the same time, we'll work hard to diversify and improve the family of controls from which designers and developers can draw. We won't be publishing a detailed roadmap for the library, although we'll try to provide clear guidance when new work is imminent; we'll try to strike a rational balance, giving you a sense of what you can expect only when we're on really solid ground from which to do so. Stay tuned to the blog for ongoing progress updates, and if you're a developer interested in using the library please consider joining the Yahoo! Group on which we're discussing the components and their use.