Blog: Archive for October, 2006

Design Pattern Conversation: What’s the Best Way to Communicate Patterns? Part Five.

This is the final article of a five-part series on communicating design patterns. When James Reffell wrote this piece, he was the pattern curator for the eBay pattern engine. For more background on design patterns, you can read an earlier five-part conversation answering the question What are Design Patterns?

Q: What’s the best way to communicate a pattern?

James Reffell

James Reffell
UI Design Manager, eBay Inc.
Curator, eBay Pattern Engine

I’m constantly amazed at the power of design patterns to communicate. I’ve found that a well-described pattern can both convey both a specific solution (which can help me solve a difficult design problem) and the core interaction principles that underly all good patterns (which can help make me a better designer).

While designers will probably always be the primary authors of and audience for design patterns, I’m finding more and more that they’re useful in communicating with all sorts of folks. These include not only the developers who are responsible for building our designs but also the business folks, product managers, and other non-designers. There’s also a big difference between talking to other designers inside an organization (as with eBay or Yahoo’s internal pattern libraries) and talking to a more general design audience (as with books or the public libraries).

The core pieces of information – What, Use When, Why, How, and Examples – are necessary to tell the story of each pattern for all audiences, and Who becomes a big deal in an internal library. Users of an internal library might also find links to internal design standards and specifications useful, as well as a list of places where the pattern appears. Additionally, as Bill points out, if the pattern will be used by a specific developer audience, the How and Examples might add sample code and implementation details. Since patterns aren’t exactly built in stone, it’s also helpful to add things like ratings, discussions, links to similar patterns, and the like.

Once you’ve added all these additional pieces of information you have something that’s grown well beyond just a design library – and that’s OK as long as it works for the intended audience, and as long as those first core pieces are in place!

So much for the parts of the whole. I think it’s also important to look at the pattern description as a whole and coherent story, however. Narrative is an important tool for communication, and I think we might not take advantage of it enough – some pattern descriptions can get a little clinical. I prefer to see the examples rounded out with some history—and maye some drama and a few laughs! There’s no harm in telling how we came to realize a given pattern was a good solve, the bumps along the road, the other things that we’ve tried and have failed entertainingly. Why can’t a design pattern also be a ripping good yarn?

Finally, the designer in me thinks we should maybe take a little of our own medicine here. Design patterns are primarily tools for designers, and we should design them accordingly. One of the things that impressed me with the Yahoo pattern group’s work is that they worked in some good design methodlogies when building the library—I’d love to see more work along those lines. Does anyone know of other examples of user testing for our pattern libraries?

- James

By Bill ScottOctober 23rd, 2006

Design Pattern Conversation: What’s the Best Way to Communicate Patterns? Part Four.

This is the fourth part of a five-part series on communicating design patterns. Martijn van Welie lives in the beautiful city of Amsterdam and has been writing interaction design patterns for a number of years. You can also read an earlier five-part conversation on What are Design Patterns?

Q: What’s the best way to communicate a pattern?

Martijn van Welie

Martijn van Welie
Senior Interaction Designer, Satama Amsterdam
Curator, Patterns in Interaction Design

Patterns communicate design solutions. Jenifer states that they communicate from “one designer to another”. Although this may be true, it may also be from designer to software developer or even to a client. As in any design problem you need to know your audience! What I have learned is that for all audiences the illustrations and examples are the most important element. They support the task of browsing through the collection for ideas and to understand in one glance what the pattern is about.

In the past people in the “pattern-enthusiasts-community” have long debated the structure and form of patterns. Jenifer and I have both taken a ‘liberal’ path and changed our formats several times over time when it seemed appropriate. What most patterns nowadays share is that they all try to answer the questions of “What?”, “Why?”, “When?” and “How?. And that is the most important thing of all.

Recently I have experimented with building a bridge to technical aspects of the patterns. This work has done with Eelke Folmer who was doing his Ph.D. on Software Architecture at the time. See the Multi-level Undo and Wizard patterns for some examples. The main idea was that we tried to add software architecture information to a pattern rather than actual code. Adding code always leads to the issue that you have to choose some particular language and assume a certain technical environment. At Yahoo!, Bill is handing out code examples and I can see the difficulty there on how to do this in a handy way.

What is of course also tricky is that not every pattern will have a technical solution with it. For example, a pattern like Alternating Row Colours will not have a technical solution to go with it. Neither does the Tabs or the Product Page pattern.

From my experience writing patterns is really difficult. The difficulty is in deciding what the problem really is and why/when the solution works. Like Jenifer says, “it is difficult avoiding tautologies.” Even in my own patterns the problem statements should be improved.

Once a collection of patterns starts to contain more than, say 50 patterns, it becomes more and more relevant to link them all together. The reasons for linking can vary: some patterns solve similar problems, or they often are used together or one pattern is actually part of another pattern, and so on. In my collection the links are gradually being added so that a network of patterns is starting to appear. But what then happens is that you discover than you need to tweak your patterns again and refine the problem statement and the use when sections so that it makes full sense again.

One interesting development in Bill’s collection is that he distinguishes between two kinds of problems. One category is “user problems” and the other is “application problems”. The user problems are the kind of problems that are easily linked to user needs while the application problems mainly make the user experience better without being linked to a specific user task. I always tried to write patterns related to user problems but I got stuck with some of them. I think Bill’s approach solves the issue very well and I hope this can be a new insight that we can all benefit from.

All in all, I have the feeling we are all converging in the format we use. What now becomes a very interesting issue is how we can link all the patterns together and form one large pattern language. Let’s see how it can be done.

- Martijn

By Bill ScottOctober 20th, 2006

Video: Douglas Crockford, “An Inconvenient API: The Theory of the Dom”

Update 20 October 2006: This video was originally posted with no link to the slide deck that Douglas uses in the talk. That deck is in PowerPoint format and can be downloaded here.

Douglas Crockford is Yahoo!’s leading JavaScript Architect. He has written extensively on JavaScript and has been among the protagonists of the JavaScript developer community for more than a decade. Douglas is the discoverer of the JSON data format and a frequent contributor to YUIBlog.

At Yahoo!, Douglas has been teaching a series of classes on the JavaScript programming language. These classes bear his unique style and perspective and benefit from the depth of his insights into the language and its application in the browser. We’re beginning to make some of this content available internally on video and thought we would share it here as well. Please note that this is “user-generated content”, not something created by the fancy and expensive studio where they make The 9 — this is the work of Yahoo! engineers simply trying to get interesting, free perspectives out there about the discipline of frontend engineering.

As always, Douglas’s ideas and perspectives are his own, and the many flaws in videographic craftsmanship are mine.

By Eric MiragliaOctober 20th, 2006

Design Pattern Conversation: What’s the Best Way to Communicate Patterns? Part Three.

This is the third part of a five-part series on communicating design patterns. Today, I (Bill) take a stab at the question.

Q: What’s the best way to communicate a pattern?

Bill Scott

Bill Scott
Ajax Evangelist, Yahoo! Inc.
Blogger, Looks Good Works Well
Former Curator, Yahoo! Design Pattern Library

The question of “What is the best way to communicate patterns?” has several dimensions.

How Will Patterns be Distributed?

In answering the main question, it is important to ask specifically “how the patterns will be distributed?” At Yahoo! the User Experience & Design (UED) team (at that time spearheaded by Erin Malone, Matt Leacock, Chanel Wheeler and others) created the pattern library using a popular open source content management system (CMS) – Drupal. This is important because one of the key benefits of a CMS is the ease in which it allows content (e.g., patterns) to be created by anyone designated as an author (in this case open to all of Yahoo! UED).

This has allowed the Yahoo! Design Pattern library to grow organically across the organization. Instead of a single pattern author controlling the library, anyone can add patterns to the library (although a review process exists to bring them to full publication.)

However, the public pattern library does not use the Drupal system. The CMS system is best suited for adding content (patterns) but not so flexible in organizing the patterns in an easily findable manner. With the public library we chose a flexible design to help solve the “findability problem.” Of course we have not solved all findability problems—but we are no longer constrained by the CMS. For the external pattern library the patterns are represented in JavaScript Object Notation (JSON) format. This will allow us to distribute patterns as web services – not just as web pages. This will make it possible to publish the patterns in different formats to different devices. And finally, other pattern sites will be able to mashup their patterns with the Yahoo! patterns into a single web site.

Why does all this matter? Patterns distributed in online format are easier to share than patterns that do not have an online presence. This does not discount that there are clear benefits to other formats (e.g., book.) Distributing patterns as web pages and web services gets them to the masses quicker yielding a higher adoption rate.

How Will Patterns be Constrained?

The next thing to consider is what legal constraints will be applied to patterns. This should not be taken lightly. At Yahoo! we chose the least restrictive Creative Commons License (by attribution.) This was on purpose. We felt this was the best way to give our patterns “wings”.

What was the result of setting our patterns free? First, we have received an enormous amount of goodwill from the design and engineering community. Second, it has exposed the concept of patterns to a much wider audience. And finally other companies have decided (or are considering) releasing some or all of their patterns to the public as a result. This can only mean good things for the design and development community at large.

Who are the Users of our Patterns?

Good design always starts with, “Who is the user?” and “What is the user’s goal?” Primarily our patterns are targeted for web designers since this is the core of Yahoo!’s business.

Knowing our target audience led us to think about how we wanted to organize our pattern library. Of course, there is no one single taxonomy for organizing a pattern library.

A year back I took all the patterns from Jenifer Tidwell, Martijn Van Welie and Sri Laakso and set out to find a good way to structure them. What an exhausting effort! I eventually experimented with Mind Mapping software to help me grapple with the complexity.

After several mind mapping sessions, I finally realized the obvious. If a designer is coming to the pattern library, they most likely have a problem and are looking for a solution (yes, that should have been obvious.) Knowing that patterns contain a problem statement and a solution, it only seemed natural to organize them in a way consistent with their problem statements. A typical problem statement might say, “The user needs needs to re-arrange the layout of modules on a web page directly.” This would fall under the category of User Needs and Customization (user needs to customize…). It turns out that a number of patterns directly satisfy user needs and the rest are driven by system constraints that the designer must account for. This means that some patterns are goal-directed, the rest are constraint-based. This led to the current organization of the public pattern library.

So What Makes up a Pattern?

I think it is important to structure the patterns in a consistent manner with a few clear, concise sections. We chose to first state the problem, next we show a sensitizing example, then we move to usage and wrap up with the solution. We also have a couple of optional sections: a rationale that can go into more detailed design nuances as well as an accessibility section.

In addition, we provide code examples with most of our patterns. These patterns include not just a design solution but also starter code to get teams moving as fast as possible. As a matter of convention, we place the code solutions in the sidebar and not in the main pattern content body. This emphasizes that while the code is related to the pattern, it is not a direct part of the pattern. I think adding code is a great solution for company-specific pattern libraries. But I also agree with Jenifer that general purpose pattern libraries should generally avoid providing code samples.

A final point of clarification is that internally we separate the Visual Design Guidelines (written as Visual Design Patterns) from the Interaction Design Patterns (like what you see on the public site.) This allows us to keep the interaction patterns more general by separating the style (spacing, fonts, colors, etc.) from the interaction.

- Bill

By Bill ScottOctober 18th, 2006

YUI: Weighing in on Pageweights

When we opened up the YUI Library in February, we talked about some of our motivations for creating an entirely new JavaScript toolkit. One of those motivations, we said, was that Yahoo!’s diverse engineering communities demanded a solution that was lightweight, one that could be applied à la carte without unnecessary k-weight overhead.

With YUI now encompassing three CSS foundation libraries, six utilities and nearly a dozen UI controls, we thought it would be a good time for a progress report on library size, page weights, and YUI’s à la carte architecture. (Note: This article focuses almost exclusively on pageweight, which itself is only one element of overall performance. Filesizes described here are based on YUI’s 0.11.4 release.)

Three Ways to Evaluate Filesize

JavaScript and CSS files exist in three different states, each with unique size profiles:

  1. Full code source, including comments and whitespace: YUI, like most open-source JavaScript libraries, includes full-source files in its distribution. These files are formatted for developer readability and include extensive function-level comments to facilitate automated generation of API documentation. These files tend to be very large.
  2. Minified source: YUI components are also distributed in minified form — minification meaning that comments, whitespace, and line breaks have been removed from the file. (Douglas Crockford’s JSMin and the Dojo Compressor are among the tools we use for this purpose.) YUI Library JavaScript files are reduced in size by more than 60% through minification alone.
  3. Minified, gzipped source sent over the wire: At Yahoo!, we evangelize the practice of serving all JavaScript and CSS files using gzip compression (a bandwidth-saving technique supported across the A-Grade browsers). Gzipping reduces overall data transmission dramatically, and it is the minified, gzipped payload that ultimately determines the file’s weight on the wire. YUI Library JavaScript files are reduced in size by more than 90% through the process of minification and gzipping combined.

Here is a filesize profile of the YUI Library JavaScript utilities’ core files in (1) full, (2) minified, and (3) minified/gzipped form.

Filesize Profile of YUI Utilities in Full, Minified and Minified/Gzipped Forms

Chart: Filesize of YUI utilies JavaScript files in full, minified, and minified/gzipped profiles.

Note: This chart does not include dependencies; the file sizes here are for each utility’s core source file only.

The data-transmission savings gained from minification and gzipping are dramatic — a document loading the entire YUI utility suite would incur 232.5KB in additional pageweight if serving the fully-commented source; that weight drops to less than 20KB when the files are minified and served with gzip compression, a savings of 91.9%. In assessing library weight, we focus primarily on filesizes after minification and gzipping, as that is the truest measure of how much data needs to be transmitted to the browser. It’s worth reiterating, however, that this is only one part of the larger performance story.

Weighing Individual YUI Components When Used à la Carte

One of the most important metrics for us in evaluating the success of YUI’s à la carte strategy is the aggregate filesize of each component, including its dependencies. All YUI JavaScript components require the Yahoo Object; most also require Event and Dom. The dependency tree beyond those foundations is more diverse. Including all JavaScript dependencies (even optional dependencies), what is the cost in transmitted filesize to include a single YUI component when serving the minified files and gzipping the payload sent to the browser?

À la Carte Pageweight of Individual YUI JavaScript Components, Including All Dependencies

Chart: Kweight of individual YUI components, including dependencies.

Note: Optional dependencies can have a significant impact on overall pageweight. Container, for example, can make use of Connection Manager for wiring Dialog Controls to the server via XHR; it can also use Drag & Drop to enable draggable Panels and Dialogs and Animation effects when showing and hiding Panels. Those three optional components account for nearly 40% of Container’s pageweight in the chart above. The Panel implementation used above to show the large-format version of the chart image omits all of these optional effects, and as a result requires only 20.8KB of transmitted YUI JavaScript. (Component filesizes represented in the chart do not include CSS resources.)

Because of YUI’s à la carte architecture, even the heaviest component is roughly half the weight of the image containing the chart above. Looking at the single dimension of weight-on-the-wire, then, we feel comfortable that YUI is succeeding in one of its core goals: allowing implementers to choose specific richly interactive elements on a page-by-page basis without unduly inflating pageweight.

The YUI CSS Foundation

This summer, we began including in YUI three core CSS resources — Reset, Fonts, and Grids — that provide a strong foundation on top of which developers can build semantic, progressively rendered, CSS-driven layouts. The YUI CSS Grids component is a toolkit from which can be assembled more than 130 different wireframes, meeting the needs of a significant subset of page layout projects. And, taken together, this CSS foundation has an aggregate k-weight of just 1.3KB on the wire (minified and gzipped).

For reference, here are the filesize profiles of the YUI CSS foundation files in (1) full, (2) minified, and (3) minified/gzipped forms.

Filesize Profile of YUI CSS Foundation Files in Full, Minified and Minified/Gzipped Forms

Chart: Filesize of YUI CSS foundation files in full, minified, and minified/gzipped profiles.

Beyond Filesize

Obviously, there’s a great deal to be said about library performance beyond raw k-weight on the wire; this single dimension is an important one, but achieving “performant richness” is a multifaceted problem. Over time, we’ll explore some of these additional dimensions here on YUIBlog.


By Eric MiragliaOctober 16th, 2006

Design Pattern Conversation: What’s the Best Way to Communicate Patterns? Part Two.

This is the second part of a five-part series on communicating design patterns. Today, Luke Wroblewski responds to the previous comments by Jenifer Tidwell.

Q: What’s the best way to communicate a pattern?

Luke Wroblewski

Luke Wroblewski
Principal Designer, Yahoo! Inc.
Founder/Principal, LukeW Interface Designs
Author, Site-Seeing: A Visual Approach to Web Usability

Jenifer makes some great points about the key ingredients of a design pattern. I’d second the importance of examples and thoughtful “problem” and “use when” descriptions. Beyond these defining elements, the right metadata for a design pattern is often dicated by your audience.

When I was working on the first iteration of eBay’s internal design pattern library, the user experience design group had been grounded in guidelines and standards. Perfectly understandable given the amount of people that were working on a single product: the eBay marketplace. Because so many different people contributed to the design and development of a single “site”, rules had to be put in place to ensure some degree of consistency.

Over time these rules evolved into high-level architecural guidelines and detailed descriptions of presentation and interaction. We called these types of rules frameworks and components. Frameworks outlined the interaction and visual structure of task flows and screen types. For example, the process of registration is a flow and a Help page is a screen type. Frameworks helped to establish where and when content and actions should be presented to users. Components described our basic user interface building blocks (menus, forms, toolbars, etc.). They were designed to optimize usability and drive consistency across all of eBay.

So we had frameworks establishing where and when UI elements should be used and we had components detailing what those elements looked like and how they behaved. But we were still struggling to deliver consistent interface designs.

To use the terminology of the IDEO crowd, creative professionals are innately curious and often apply “the mind of a child” – open to new ideas and observations – to their unique form of problem solving. We had plenty of creative designers at eBay and they approached their work in exactly this way. They strove for new ideas and solutions and were innately curious about the rationale behind the frameworks and components we were using to drive consistency. As a result, lots of new solutions were proposed, and often adopted. As you can imagine this created an interesting dynamic between the “rules” and design – a naturally iterative and abductive approach to problem solving.

To embrace the design process within our redesigned “rules”, we decided to morph our frameworks and components into a set of design patterns. Like rules, patterns could be tested, verified, and reviewed. Unlike rules, however, they were repeatable design solutions to common problems. This was a key distinction as the emphasis shifted away from “here’s how it has to be done” to “here’s a way to make your job easier.”

In order to make this transition, we modified our documentation of frameworks and components. To our initial explanations of where and what, we added:

  • Why: what opportunities or constraints helped to define this pattern? Was there any research done to support it?
  • How: in an effort to make pattern adoption as easy as possible we included direct links to visual specifications and code where possible. We also provided an indication of status to ensure proper usage: under development, required, recommend, etc.
  • Who: direct links were provided to the people that had documented, identified, or designed the pattern.

Given our audience (a central design team working on a myriad of ultimately integrated products and features), this approach afforded a lot more flexibility in how we shared and documented design best practices. That said there’s clearly some differences in our approach to the one Jenifer advocated earlier. Integration of code samples and visual specifications was important in order to make things easier for our designers and we included some fields that may be extraneous for a general-purpose audience. The basic answers our pattern documentation provide though were the same: “What, Use When, Why, How, and Examples.”

- Luke

By Bill ScottOctober 16th, 2006

Implementation Focus: PowerReviews

Periodically, we sit down with developers in the community who are implementing YUI for projects outside of Yahoo. Yesterday I met with the engineering team from PowerReviews, a company that provides free product-review services for online storefronts of all sizes, from mom-and-pop shops to Sun Microsystems. PowerReviews has been using YUI to build out the second generation of its product; you can take a sneak peak at their new reviews portal at http://sneakpeak.powerreviews.com.

Members of PowerReviews engineering team: (clockwise from top left) Martin Davidsson, Gautam Prabhu, Jim Morris, Joshua Greenough, Aamir Virani, and Vlod Kalicun

Members of the PowerReviews engineering team: (clockwise from top left) Martin Davidsson, Gautam Prabhu, Jim Morris, Joshua Greenough, Aamir Virani, and Vlod Kalicun. At their Millbrae offices.

What is PowerReviews and how long have you been around?

We’ve been around about a year and four months. The goal of the site is to become the "review engine of the web," providing a better place to research products via review data. There are enough price comparison tools on the web already. If the customer buying process is first research, then price-compare, then buy, we want PowerReviews to the place for doing the research…we call it "research on your terms."

Where does YUI fit into your needs and process? Why did you choose YUI?

We built our first generation using the Prototype library and home-brew code for some basic interactions and effects, but we’ve moved to YUI for our second-generation. We’re trying to rip out as much home-brew as we can and use YUI as much as possible. A big part of choosing YUI for us was the documentation. We also liked the ability to choose individual components, the fact that it ships with minified source, and the fact that it’s used on Yahoo…we know at least that it’s being tested at a high volume and in a lot of browsers. Fundamentally, we tend to agree with the engineering philosophies that the YUI team is espousing.

What has been the most rewarding aspect of moving to a more dynamic interface?

We like being able to make the process of creating a review more interactive and contextual. Desktop applications make this kind of thing really easy, but it’s been hard on the web. Using Ajax has for us allowed the site to take on some of those more interactive characteristics.

We’ve also used interactivity on the administrative side to improve productivity. We’re using things like inline editing for auditing and approving reviews as they come in. It can be simple things, but it’s saving pageloads and keystrokes and, ultimately, time. It’s also incremental — if one of our clients does a series of steps and the browser crashes, everything they’ve done along the way gets saved.

What, if anything, has surprised you about switching to YUI as your client-side platform?

YUI incorporates the CSS foundation we needed and provides for us a tie-in between CSS and JavaScript — it’s like we’re getting that all for free, using the YUI team as an outsource group to help us build foundations. We think there also will be leverage down the road, being able to hire engineers who are familiar with YUI and therefore can pick up our stuff and contribute faster.

What have been the pain points in adopting YUI?

The main detriment we’ve found is that YUI doesn’t have the same kinds of distilled, one-line effects that you find in Scriptaculous. We’ve looked at Jack Slocum‘s stuff, and we see some of that emerging with YUI. But there are some more complicated interactions built-in for you with Scriptaculous.

Filesize is a concern for us, too. We can control gzipping on our own site, but we distribute our solution to our customers; if they don’t enable gzipping, the library’s filesize goes up.

Have you looked at the Yahoo! Patterns library in planning your implementation of a richer client-side feature set?

Yes. That’s been a big part of our thinking, too. There are standards there, and they sound really simple at times but incorporate a lot of things that have been learned at Yahoo and elsewhere. And these are the emerging patterns on the web, so we can rely on our users tending to be familiar with these patterns.

Do you have a YUI implementation that would be of interest to the YUI community? If so, please share your link and post a message to the community forum at YDN-JavaScript, or leave us a message in the comments section below.

By Eric MiragliaOctober 13th, 2006