2. The Reuse Trinity
In this chapter, we take a close look at each of the three parts of the reuse so that, throughout the rest of the book, you can better see how design patterns, components, and interaction design frameworks relate to each other and work together.
The Reuse Trinity didn’t come easily, nor did it develop in an entirely logical order. The notion of patterns began way back with Christopher Alexander’s book in 1977, and has since been propagated by pattern advocates such as Luke Wroblewski, Bill Scott, Martijn van Welie, Teresa Neil, Christian Crumlish, Jenifer Tidwell, and many other industry experts whose hard work has brought patterns to the forefront of web design practices. Components—fully fleshed-out, production-ready page elements that represent the natural evolution of patterns—came much later, at least in terms of software design (as opposed to development).
In fact, components have only just begun to become standardized as a concept, thanks largely to the work of EightShapes designers Nathan Curtis (author of Modular Web Design: Creating Reusable Components for User Experience Design and Documentation (New Riders)) and Dan Brown (author of Communicating Design: Developing Web Site Documentation for Design and Planning (New Riders)), though less formalized variations of the idea have been around for years. Frameworks are the last to fill out the picture, and are being documented for the very first time in the book you now hold in your hands. In practical terms, however, frameworks should have come first, patterns second, and components third. This is how they can be most effectively used and thought about within a web design process.
Figure 2.1 Diagram of the Reuse Trinity
Design patterns are essentially production patterns that are part of larger frameworks, while components are the realization of patterns within the scope of a specific system, bringing patterns to the point where they can be interacted with online as a finished piece of a site or application screen.
As we go through each of these elements in some depth in this chapter, we’ll do so in the order in which they were conceived. Regardless of whether or not you’re already familiar with patterns and components, it will perhaps be easier to understand the big picture of frameworks with a basic understanding of the parts that comprise them.
Design Patterns
A design pattern, if you don’t already know, is a common solution to a common problem. For example, the pagination pattern gives us a standard interface for spreading search results across multiple pages simply by adding paginated links to the bottom of each results page. The design typically includes Previous and Next buttons, numbered links that provide access to each of the next several results pages, and some sort of visual indication of the current page.
Sound familiar? It should. It’s at the bottom of every Yahoo–search-results page.
Figure 2.2 Examples of pagination interfaces from the Yahoo Design Pattern Library
Yahoo may not have been the first to use the design, but Yahoo’s version is used so frequently that virtually every other search system out there features a variation of it. This makes it a pattern—a hugely successful pattern, in fact, that has been documented in countless pattern libraries, both public and private.
The primary benefit of design patterns is that they enable users to parlay their experiences from all across the web into working knowledge of any site that uses the same patterns. After using Yahoo to run a few searches, a user can easily understand the pagination interface of any other site using a similar design.
On the flip side, designers benefit greatly because patterns offer what are essentially canned solutions to a host of typical design problems. Instead of rethinking and reinventing search navigation for every new site, we can simply pull out the pagination pattern, make a few tweaks, and move on.
For years, many considered design patterns to be the building blocks of the web—for good reason—and with frameworks, we hope to build on the success of patterns.
Elements of a design pattern
To understand patterns better, let’s consider what goes into a typical design-pattern description. Jared’s company, UIE, turned up quite a few common elements:
Figure 2.3 A pattern document from Welie.com’s public pattern library
Pattern name
If we were talking about an element to log a user into the password-protected portion of a site, we might name it “Username and Password Widget,” “Two-Line Sign-in Elements,” or “Log-in Element.”
It’s important to choose the pattern name carefully. Traditionally, many elements appear in designs without having a name, leading to discussions that contain statements like, “You know, those little box thingies we always have on the left.” The goal of the pattern name is to encourage clear communication in meetings, design documents, and other places where people may want to call out a particular element.
We’ve seen that naming a pattern takes skill, creativity, and a little bit of luck. Teams may start out with one name, only to find later another name has become the common parlance.
For example, one team officially named its application’s object attribute editor the “Infobox,” only to find that nobody on the team ever referred to it that way. Instead, they all called it “Properties.”
Some teams add a list of nicknames, synonyms, and also-known-as (aka) names to a pattern’s description. This helps team members know what they’re talking about. What we call things changes over time, so it’s helpful to keep the pattern name updated to reflect the current lexicon.
Description
A description is essential for a good pattern. It helps team members who may be unfamiliar with the element to know exactly what is being talked about.
And since a picture is worth a thousand words, screen shots can also be very valuable. When a given pattern has different manifestations within a single site, multiple images can help.
A log-in element, for example, might have this description (along with appropriate screen shots):
A description doesn’t have to be a major literary work, but it should include enough information to explain why the element exists and how to distinguish it from other elements on the site.
Context of use
One of the key benefits of a design pattern over a style guide or guideline document is the heavy emphasis on each element’s context of use in a pattern library. Designers, when considering a new design, use the context description to determine if a particular pattern is appropriate.
For example, the context for our log-in element might say something like this:
Of course, this section needs to include something about the log-in element when it’s not used:
Contexts are living creatures. As a team builds more elements, develops new applications, and discovers new user requirements, the Context of Use section requires frequent updates. Ideally, at any point in the pattern’s lifetime, a designer can read through this section and immediately know whether or not the element is right for the job at hand.
Where used
Another living portion of the document, the Where Used section, points to instances of the pattern in use and is updated every time the pattern makes it into a production system. Team members can look at existing implementations of the pattern and see it in action.
How it works
Here, teams describe the mechanics of the element:
The amount of detail necessary depends on the complexity of the control and the familiarity team members have with it. (If it’s an element they personally use all the time, it probably doesn’t need as much description as one they rarely encounter on their own.) One usability team showed us how they use a video-capture utility to create short demonstration videos of the elements in action, which they reference in this section.
Mentioning other patterns that interact with this one helps the designers understand what else they’ll need to consider when they are putting their design together.
Co-requisites
It’s rare that a pattern stands alone. The presence of one pattern usually indicates that the designer will need other patterns to support it.
For example, if a design requires the log-in element pattern, then it will likely also need the following:
• A pattern for creating a new user ID
• A pattern for changing the password
• A pattern for recovering a lost password
• A pattern to log out of the password-protected portion of the site
• A pattern to display an error message when the wrong user-name/password combination is entered
All of these patterns are listed in the Co-requisites section along with any explanations as to why they might be required (if it’s not obvious).
Design-pattern documentation can also include sections on competitive approaches, pattern history, usability test results, user feedback, and discussion.
Pattern libraries
Pattern libraries, as shown in Figure 2.4, are curated collections of pattern documents, often categorized and made available either online or privately within an organization.
Figure 2.4 The Yahoo Design Pattern Library, one of the most popular public libraries
Here is a list of resources for several public pattern libraries:
• Yahoo Design Pattern Library: http://developer.yahoo.com/ypatterns
• Designing Interfaces (the support site for the book of the same name, by Jennifer Tidwell, published by O’Reilly): http://designinginterfaces.com
• Welie.com: http://www.welie.com
To start leveraging patterns, many teams turn to one of these off-the-shelf, public pattern libraries, but while these are often well-documented and free, they can’t account for a project’s specific technological constraints and business requirements, so they may be less useful for a specific project. The most helpful pattern libraries make project-specific constraints and requirements their focus.
Public pattern libraries tend to offer generic patterns—ones not specific to a given application. While they do offer low-level baseline recommendations for what are considered standard web interactions, organizations frequently individualize these patterns in their applications and sites, rendering the patterns found in public libraries too generic to be truly useful for their design teams.
That said, these generic patterns can still give great benefits. In addition to providing baseline recommendations that can serve as a great jumping-off point for the creation of customized patterns, these libraries are a fantastic resource for solo designers, either working inside an organization or consulting from outside. Since consultants tend to work on a wide range of projects for a variety of clients, public pattern libraries offer an endless supply of solutions that can be applied across many different site designs.
Internal pattern libraries, on the other hand, typically present pattern variations more specific to an organization’s sites, making them a powerful tool for design teams. The team can curate their library using a wiki or microsite on their intranet, and they can tie it to their internal style guide so other teams within the organization can take advantage of the library when implementing new designs.
The major difficulty in developing a pattern library is coordinating its launch. First, individuals or teams need to sniff out patterns already in use by an organization by identifying all the instances of their use. They then need to establish a system for posting and sharing them, document each pattern, form a plan for maintaining the library in the long term, and finally, promote the library. This is no small task for a team, whose core mission is usually to meet the deadlines of much higher-priority customer-facing projects. But the payoff of a pattern library far exceeds the effort required to launch it. A team can immediately begin pointing developers to the library to answer questions about how certain interactions should look and function. And with this core piece of the reuse strategy in place, designers can spend less time reinventing what are already common solutions and spend more time on a project’s unique challenges.
Components
Perhaps the simplest way to introduce components is to quote a page from the website of perhaps their most ardent advocate, the company EightShapes (http://unify.eightshapes.com/users-guide/what-you-get/wireframe-components/):
And to paraphrase Nathan Curtis’ presentation, “Creating a Component Library”:
Whereas a view is a complete page or page state, and an element is something on a page that can’t be broken down any further—such as a logo, header image, or button—a component is a combination of elements that creates a purposeful, reusable, and independent structure. A tabbed navigation interface. Search results. Article content.
While a pattern is a generic solution that works across sites, a component is specific to a site—very specific, in fact. While patterns are best for interaction designers and anyone else hashing out a solution using sketches, wireframes, or other low-level artifacts, components are aimed at the people who build out those designs. They’re code-complete and reusable. A developer can simply plug a component into a page (and multiple components can be derived from a single pattern), customize its content, and have a completed page area.
Elements of a component
As component libraries are not yet popular enough to survey a wide variety of resources and extrapolate a set of best practices, we pulled the following list of elements from the public component library available through the Sun Microsystems website (more on this in the Component Libraries section).
Component name
The component’s name, at least in the Sun library, is offered via the page title. As in pattern libraries, however, you can include a more explicit Component Name section that offers a list of alternative names used within your organization.
Component version number
Adjacent to both the component name and the heading for the Sample section (described below) is the component’s version number. Like release notes for any software update, the version number can be tied to a list of changes that have occurred from one version to the next. This can help get the attention of developers who need to update previous implementations, and help teams maintain consistency across systems.
Definition
A component’s Definition section, much like a pattern’s Description section, simply describes the purpose of the component. In Figure 2.5, the definition of the B01 Features component is explained as follows:
Figure 2.5 A Sun.com component document
Usage
The Usage section describes where the component is to be used, and includes any relevant notes. You’ll find this on Sun’s D05 Primary Index Nav page:
While the component is limited to index pages, it can be implemented in one of two ways: with and without the See All link. The Usage section simply details both of these points.
Sample
The Sample section offers a living, breathing version of the component. Since components are completed page elements, you can add fully functioning versions of them to their web-based documentation. This helps people throughout an organization see exactly how the component is meant to work (which, among other things, can help quality assurance teams verify the correctness of implemented versions), how it looks, and what code should be used to implement it.
Code
Along with a functioning sample, component documents should include a Code section that links to implemented versions of the component, created using various programming languages. If an organization has created one application with Ruby on Rails and another with Apple’s Cocoa, and the component can be used in both, then the Code section should include versions created with both languages.
Component libraries
Component libraries can be developed and distributed the same way pattern libraries are—by setting up a wiki, identifying finished instances of components, and documenting them.
The Sun Microsystems website, as shown in Figure 2.6, includes a public component library that can easily be used as a reference for how components are documented. You can find this library at www.sun.com/webdesign.
Most usefully, Sun offers a page about how to use components (http://www.sun.com/webdesign/structuring-pages.html); the page visually describes the different sections of a standard Sun content page template. It also offers an example of a page built using the company’s components (http://www.sun.com/software/products/mysql/index.jsp).
Additionally, Nathan Curtis has posted his slides, “Creating a Component Library,” to SlideShare.net. It’s available at http://www.slideshare.net/nathanacurtis/creating-a-component-library-298610.
Figure 2.6 Home page for the Sun.com component library, at www.sun.com/webdesign
Interaction Design Frameworks
In all, there are perhaps millions of design patterns in use every day on the web—some more prevalent than others—and as such, they are ideal candidates to be called the building blocks of the web. But they also have a very important limitation.
Design patterns solve small and specific problems—exactly what we need them to do—but they don’t tell us how those problems relate to and affect our solutions to other problems. Even the Context of Use section in the typical pattern document discusses only where a pattern fits into an application, not how it affects the application or how it relates to the rest of that system. And although the Co-requisites section lists other patterns that should be used in tandem, the list fails to illuminate the why behind the what.
Design patterns lack much of the contextual information we need to create a successful design, so they leave us with a lot of unanswered questions. How many search results do we show on each page? How do we handle errors (typos, zero-result searches, and the like)? How will users run new searches? How much information should be offered in each result? Which information is important? Patterns don’t answers these questions.
For example, while a pagination interface enables a user to navigate from one page to the next and back again, it solves exactly one problem. It supports exactly one action. But there’s much more to consider in the pursuit of usable designs.
To answer these questions, we can’t look only at the pagination interface. We have to look at the whole search system. By extension, we can’t rely exclusively on design patterns—we have to look at how the patterns make up systems, and how systems make up whole applications.
And since components are essentially the code-complete versions of an organization’s patterns, they can’t be used to answer these questions either.
To answer these questions, then, we need to look at the level above design patterns in the Reuse Trinity: interaction design frameworks.
Elements of an interaction design framework
Frameworks are structured similarly to design patterns. In fact, we consider frameworks to be the next logical evolution of design patterns—the next step in establishing a set of mature solutions. The frameworks we present in this book are exactly what we recommend you use in your own frameworks—names, descriptions, explanations of where and how they’re used, and so on. Simply, each framework includes some or all of the divisions we identify in this section.
Beyond this, we also discuss the user needs these frameworks meet and the human behaviors that led to them, and we explore how these design problems could be solved differently. We’ve done this to provide insight into what to consider when applying frameworks to your own projects and how to make full use of the design criteria you pull out of them.
Figure 2.7 The sign-up framework document from http://webanatomy.rhjr.net/signup
This does not mean, however, that we expect you to write an in-depth discourse for each of your frameworks. Rather, we recommend your framework documents be no more complicated than your pattern documents.
Stick to the following sections and you’ll be just fine.
Description
The Description section addresses not just a description of the framework—its overarching purpose—but also the question of what human needs it meets. The catalog framework, for example, covered in the next chapter, describes that people handle item-selection in a three-step process, and that this fact is the reason the catalog framework exists, as it directly supports that behavior.
We’ve done our best to include this type of information in each framework’s Description section, but we’re also sure you’ll come up with different variations on the section as you develop your own framework libraries. The important thing to get across is what the framework is meant to handle. The catalog framework supports the process of item-selection. The search framework supports the content-finding process when site navigation doesn’t cut it. The sign-up framework persuades users to convert from visitor to customer.
Context of use
This section describes the problem a user is encountering or need a user is trying to fulfill when a given framework comes into play. For example, the sign-up framework addresses questions a user is likely to have when considering the merits of a walled-garden style web application which she can’t use until after she signs up. It offers insight into the features and benefits of the application, the cost/effort of trying it out, information on how to get started, and so on.
Beyond this, this section also describes where the framework sits in a site’s information architecture. The sign-up framework, for example, most often lives among the top level marketing pages.
Task flow
Many frameworks are comprised by a series of interactions commonly experienced in a set order. Some offer pathways to information so users can answer their own questions as soon as they come up. In these cases, there is a task flow the user must follow. The Task Flow section simply describes that task flow.
The exception to this comes from frameworks that describe niche site types, such as movie sites (see Chapter 7), or any other group of patterns that are consistently, at least in some combination, used together to create a complete solution. A typical movie site includes, among other things, a trailer video, cast and crew information, and a synopsis. Movie sites don’t usually include tasks, per se (at least not in the sense that users visit them to perform some productive function), so the Task Flow section is unimportant to the movie-site framework and is therefore not included. But since these elements all work together to do the job a movie site needs to perform—the job of convincing a person to see a movie—they constitute a framework.
Co-requisites
The Co-requisites section simply lists other frameworks that are necessarily used in conjunction with the one being described. For example, an e-commerce framework would be comprised of elements specific to the sale of products or services on a site (for the purposes of this book, we’ve rolled these up into the catalog framework). To properly support the tasks in that process, however, the e-commerce framework would be used alongside the search framework, to offer a secondary path for locating items; a shopping-cart framework, to handle communication about a purchase; and a checkout framework, to handle purchases. These are all co-requisites for the e-commerce framework.
Related
Related frameworks are ones that may serve similar purposes or support similar user or business goals as the one being described. In addition to the search and shopping cart frameworks used, an e-commerce site typically includes an order-management system and a customer-account system as well. These systems can be documented as frameworks, then linked to from the Related section.
Elements
The Elements section is one of the two most important parts of a framework (the other being the Design Criteria section, which follows), because it provides a list of the design patterns that fall under its canopy. As you’ll see throughout the next five chapters, the list of elements is the meat of a framework. This is where a framework library merges with a pattern library—the list links to documentation for the patterns in the framework. It’s in this way that a framework library is like a wrapper for a pattern library (we talk about this more in ”The First Framework Library,” later in this chapter). Frameworks—unlike patterns—create context and provide guidelines for complete solutions, but again, they are largely composed of patterns.
There are no frameworks without patterns. The two work hand in hand.
Design criteria
The other most important element of a framework is the Design Criteria section, which is simply a list of guiding design principles for a framework. But while this may sound simple, it can be the most difficult part of a framework to define.
Design criteria make up a set of instructions, stated as a list of rules, that express the motivations behind a design by making crystal clear what it needs to accomplish for a site’s users.
The sign-up framework (Chapter 5), for example, includes the following design criteria:
• Communicate a clear value proposition.
• Set expectations.
• Demonstrate that it works well.
• Encourage action and enable progress.
• Associate the user to the user’s actions.
Each criterion operates as a directive for a design.
There are exactly two reasons to create this list, and they are incredibly important.
First, frameworks help you reverse-engineer human behavior, and this list of design criteria is the expression of that understanding. The very act of identifying a framework’s design criteria helps to burn the value of the framework into your mind so that you always know what to focus on when implementing one in your own project. In design, even the most subtle and seemingly meaningless details can result in significant differences in the usability, conversion rate, enjoyability, and meaning of a product. Knowing what is important about a given design ensures you can make those modifications intelligently.
Second, the ability of a framework to shed light on this human behavior enables you to then devise new solutions that meet the same purposes, so that innovations based on them continue to meet real goals and solve real problems. Simply put, the Design Criteria section of a framework tells you what needs to be accomplished should you decide to take a completely unique approach to your design.
In each of the five frameworks documented in this book, we use the Design Criteria section to show examples of how this has been done—sites that meet the goals of a standard framework in different and unique ways. We hope this helps you understand not only how to think about and apply design criteria, but also imagine the new solutions made possible as a result.
This emphasis on design criteria, however, brings us to another important point, that extrapolating these criteria from a framework can appear tricky and somewhat like an unexplainable, magical process. We don’t believe this is true.
The only real trick to determining the criteria for a design is to ask yourself what the framework does for you or a site’s other users.
Figure 2.8 The value proposition element from GetBallpark.com
By asking what the sign-up framework accomplishes, for instance, start by looking at the elements in the framework. One element is the value proposition—featured on practically every site that requires users to register. The invoicing application Ballpark (www.getballpark.com), as shown in Figure 2.8, uses the statement, “The better way to send estimates + invoices.” By asking what that statement accomplishes, it’s easy to see that its goal is to communicate the value of the application. It tells users what the application does and why it should matter to them. In this case, an element in the framework and a design criterion feature the same words. The element is called the value proposition, and the design criterion is “Communicate a clear value proposition.” In other words, the elements sometimes exist for no other reason than to satisfy one of the criteria for the design.
Another sign-up element, as we discuss in Chapter 5, is the registration form itself. A registration form enables the user to create an account. This much is obvious. But what is the design criterion to be extrapolated from this fact? To determine that, ask yourself why the user must register. Users must sign up so that the actions they take on the site can be tied to them somehow, enabling them to retrieve their data, customizations, and so on, the next time they sign in. One design criterion for the framework, then, becomes “Associate the user to the user’s actions.”
A trickier example might be the search framework, discussed in Chapter 4, because the elements in the framework don’t necessarily make their purposes clear. To determine the criteria for an effective search system design, you have to understand why people search in the first place. A user searches when other site navigation somehow fails to guide her to her desired content. To compensate for this, search provides a secondary method for finding that content. But this secondary method will fail just as easily unless the content she seeks includes at least some of the same words the user expects will help her find it. So the design criterion then becomes “Associate content to user terminology.” It would be impossible to see this without understanding why people search and what makes a search successful, but these are questions that have been well researched, and that you can usually answer yourself with a little thoughtful investigation. Ask what makes a search successful and you’ll probably answer with something that can be rephrased into a design criterion.
Yes, some criteria certainly are more difficult to sniff out than others, but hopefully these explanations show you that the process involves little more than asking questions about the framework and turning the answers into directives.
In each of the following five chapters, the Design Criteria section will help illuminate how to do this when documenting your own frameworks.
In the meantime, let’s look at the conceptual side of frameworks—the philosophical underpinnings that make frameworks tick.
Qualities of a framework
Renowned information architect Liz Danzico (Happy Cog Studios, Bobulate.com) once gave a talk titled “The Framework Age.” The presentation centered on the idea that instead of designing to support strict, scripted user behaviors, web designers have begun to design flexible platforms for user behavior. While Liz’s talk focused on a shifting web paradigm that is unrelated to our topic, along the way she labeled three qualities of frameworks that, together, form a definition.
To reveal these qualities, Liz talked about the difference between classical music and modal jazz.
In classical music, she explained, every note is inscribed. A composer painstakingly writes out each and every note of each and every section of a composition for each and every instrument. To become a master player, one must bring finesse and grace and style to the table, for sure, but at the very core, one must bring the ability and discipline to play the notes. Perfectly. Every time. In classical music, to play an incorrect note is to fail.
Jazz, however, is very different. And modal jazz is almost the polar opposite.
Before recording the groundbreaking album Kind of Blue, legendary trumpet player Miles Davis walked into the studio and handed out six pieces of paper. These pieces of paper offered just a few bits of useful information—the key of a song, its tempo, and a few other constraints that would keep the musicians moving in the same direction. They offered nothing else.
Instead of playing compositions note for note, rigidly following the rules of a laboriously inscribed stack of sheet music, Miles Davis asked these musicians to compose in real time. To write the music as they played it.
He wanted them to perform. To improvise. To bring themselves out into the music.
Despite the fact that no one in the room had ever played in quite this way before, the next step in their evolution as musicians, and indeed the next step in the evolution of jazz, was laid out before them on six little pieces of paper.
And through this simple but revolutionary request, the world was introduced to modal jazz, which is essentially music born of frameworks.
While the shell of each song—its outline, its structure—was written down, everything else was left wide open. Musicians were free to play off of the framework however they chose. To experiment. To stretch their musicallegs.
Through this analogy, Liz illuminated the three defining qualities of a framework.
Present
First, frameworks are present. In Liz’s own words, they’re “detectable, but not inscribed,” which is to say they exist and can be identified, but their manifestations are by no means set in stone. Much as frameworks can be found in every musical genre, they can be found in site designs in virtually every vertical market. This makes them incredibly easy to sniff out and document, but they remain unique in as many ways as there are manifestations. Five billion different search systems may feature an essentially identical pagination interface, but somehow, in some way, every last one of them will differ from all the others. Detectable, but not inscribed.
Additive
Second, frameworks are additive. They enable designers to build upon and scale designs in whatever way makes sense for a particular solution, as well as string together collections of frameworks to compose entire sites.
Performance enabling
Finally, frameworks are performance enablers. They enable designers to stylize their designs. Customize. Perform.
Rather than confining users to some rote set of rules, frameworks allow for improvisation. Although the elements of a framework may remain largely the same in a majority of cases, each and every implementation of a framework must, like a design pattern, be adapted to work in its environment. A search-results page, for example, may be so common that it has become a standard part of every search system, but each one must be considered and designed in the context of the larger application. This is where the designer’s aesthetic comes in. Here, the designer gets to inject style, nuance, finesse. Here, the designer gets to perform.
Informing innovation
So, while frameworks can simply serve as the starting point for a design, it’s important to understand that, as standards, they do not represent the death of innovation. In addition to essentially giving us a set of snap-together interface solutions, frameworks offer insight into how to kick things up a notch or three.
Consider the major online retailers. You may have noticed they all use an extremely similar information architecture. On Target.com, for example, if you enter through the home page, you look around for links related to the products you want (for example, sports equipment), identify categories that may offer the items you’re attempting to find, scan search results full of products, spot an item you want know more about, and then click through to the details page for a better look. (Granted, the high art of Googling has all but eliminated the need to follow this process while shopping online, but that’s a different story.) Every major retail site on the web supports this core task flow.
Why?
Because the online version of the shopping experience matches our long-established mental model of shopping—in fact, it’s practically identical to how we shop in real life. There’s nothing magical about it. Target.com, Barnesandnoble.com, Amazon.com, and many other retailers online simply support typical human behavior.
The reason this matters is that someone had to notice the behavior, decide to support it online, and then design something that offered a representation of the offline behavior that rang true for users. These retailers decided to emulate real-world shopping behavior almost note for note, but they didn’t have to. Once they understood the real-world human behavior, they could have invented wildly different solutions that solved the problem in a much more exciting way.
And therein lies your opportunity.
The very psychology that led to the design of every standardized solution out there can also lead to much more compelling designs. Put this psychology at the center of your decision-making process and you give yourself the ability to design incredible things that still work well for users.
Simply put, the point of a framework is not to limit innovation, but to inform innovation.
The first framework library
Frameworks, at the time of this writing, are in their infancy, illustrated by the fact that the book you now hold in your hands is the first to discuss them in terms of user experience rather than code. As such, we don’t yet know of any public framework libraries. (Those we’ve curated before have been private.)
So we started one. It’s at http://webanatomy.rhjr.net.
The Web Anatomy framework library includes documentation for all of the frameworks in this book and more. Our hope is to continue growing it based on your feedback, ideas, and contributions.
As you can see from the site, a framework library should be little more than a wrapper for a pattern library. This is especially easy, of course, if you’ve already created a pattern library for your organization, but even if you haven’t, you can begin both by creating the framework documents using a wiki or another solution and linking the elements listed in the Elements section to the pattern documents that describe them.
In the Web Anatomy library, we’ve linked elements whenever possible to public pattern libraries. When the elements we listed were not available in public libraries, we attempted to describe them well enough to stand alone. We hope these elements will eventually be documented in other pattern libraries so we can link to them then.
Figure 2.10 The first public framework library, at http://webanatomy.rhjr.net
As the first public framework library, we’ve made sure it reflects the practices we recommend in this book. Used in conjunction with the book, the library will help you see not only how to document frameworks, but also how to share them. On its own, we believe the library will help anyone who uses it reap the very benefits we have detailed in this and the preceding chapter.
We also certainly hope it won’t be the last public framework library, and that other individuals and organizations will open their libraries up to anyone who wishes to make use of them.
Rolling your own
As you can see, our library appears to be comprised of static web pages rather than presented via an openly editable wiki. In truth, the Web Anatomy library is built atop the popular content-management system and blogging tool WordPress, and it features a custom WordPress theme.
You can use any tool you like to create your own library. It’s important, however, that the library be available to any and all of an organization’s staff who can benefit from it, and that it be documented using a method that is efficient to update. (Trust us. For what we hope are obvious reasons, you don’t want to document your framework library in print.)
Frameworks in the Wild
One interesting question that came up after Robert gave a workshop about frameworks at Jared’s UIE Web App Summit event was in regard to whether or not frameworks would homogenize interaction design enough to put some interaction designers out of jobs.
The answer, definitively, is no.
To the contrary, one of our goals with frameworks is to enable designers to spend less time repeating tedious interface design and architecture tasks, and more time doing what these designers should be doing: focusing on user-experience vision and strategy for their organizations and clients.
Another workshop attendee asked how to prevent stringing these frameworks together in such a way that you end up with the interface equivalent of Frankenstein’s monster. Our answer:
Frameworks, just like the human anatomical systems we are relating them to, fit together remarkably well. There is so much overlap and such strong relationships between them that their divisions easily become invisible, resulting in completely seamless interactions. In many cases, a single pattern can be part of multiple frameworks at once, and play multiple roles for a user. One example of this is a button labeled Register Now that is used both as a call-to-action to entice users to sign up for a conference and also as the entry point to the account-management conversion system the event organizers will use to correspond with the registrant before the event.
No individual framework has much meaning by itself. Even Google’s search framework, clearly the dominant framework in play in the company’s core task flow, is accompanied by elements designed to orient users to the site, entice them to use more of Google’s services, and sign in to retrieve previously stored information. It’s only when woven together that frameworks constitute a complete site or application—a complete experience.
On to the frameworks
The following four chapters cover significant frameworks—catalog, search, sign-up, and About Us—in great detail. In these chapters we discuss the human behaviors that made these frameworks standard, the results from research and usability studies that relate to them, and what types of things you should consider when putting the framework to use in your own projects.
In Chapter 7, we show you a framework for a niche market—the movie industry. We don’t do this because we believe all our readers are involved in the movie industry (although you certainly may be), but rather to illustrate how to identify the elements that make up a less common framework. Practically every industry has its own set of standards—higher-education sites have application forms, stock photography sites have admin tools for photographers, financial sites have portfolio-management tools—and we use this chapter to illustrate not only how to spot these industry-specific cases, but also how they work together with other frameworks to form complete sites.
When you’re done, again, be sure to check out http://webanatomy.rhjr.net to see a living, breathing framework library as an aid to begin documenting your own frameworks and curating your own library.
On to the frameworks!