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 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.
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:
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.
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.
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.