Section 12.3. Blueprints

12.3. Blueprints

Blueprints show the relationships between pages and other content components, and can be used to portray organization, navigation, and labeling systems. They are often referred to as "site maps," and do in fact have much in common with the other definition of "site map," a type of supplementary navigation system that we describe in Chapter 7. Both the diagram and the navigation system display the "shape" of the information space in overview, functioning as a condensed map for site developers and users respectively.

12.3.1. High-Level Architecture Blueprints

High-level blueprints are often created by information architects as part of a top-down information architecture process (and, it's worth noting, they may also be produced during a project's strategy phase) Starting with the main page, the information architect might use the process of developing a blueprint to iteratively flesh out more and more of the architecture, adding subsidiary pages, increasing levels of detail, and working out the navigation from the top down. (Blueprints can also support bottom-up design, such as displaying a content model's content chunks and relationships; we discuss these uses later in the chapter.)

The very act of shaping ideas into the more formal structure of a blueprint forces you to become realistic and practical. If brainstorming takes you to the top of the mountain, blueprinting can bring you back down to the valley of reality. Ideas that seemed brilliant on the whiteboard may not pan out when you attempt to organize them in a practical manner. It's easy to throw around concepts such as "personalization" and "adaptive information architectures." It's not so easy to define on paper exactly how these concepts will be applied to a specific web site.

During the design phase, high-level blueprints are most useful for exploring primary organization schemes and approaches. High-level blueprints map out the organization and labeling of major areas, usually beginning with a bird's-eye view from the main page of the web site. This exploration may involve several iterations as you further define the information architecture.

High-level blueprints are great for stimulating discussions focused on the organization and management of content as well as on the desired access pathways for users. These blueprints can be drawn by hand, but we prefer to use diagramming software such as Visio or OmniGraffle. These tools not only help you to quickly layout your architecture blueprints, but can also help with site implementation and administration. They also lend your work a more professional look, which, sadly, will be more important at times than the quality your actual design.

Figure 12-1 shows a high-level blueprint that includes components within pages, groups of pages, and relationships between pages. The grouping of pages can inform page layout. For example, this blueprint dictates that the three guides should be presented together, whereas Search & Browse, Feedback, and News should be presented separately.

Figure 12-1. A high-level blueprint

Let's walk through the blueprint in Figure 12-1 as if we were presenting it to clients or colleagues. The building block of this architecture is the subsite. Within this company, the ownership and management of content is distributed among many individuals in different departments. There are already dozens of small and large web sites, each with its own graphic identity and information architecture. Rather than try to enforce one standard across this collection of sites, this blueprint suggests an "umbrella architecture" approach that allows for the existence of lots of heterogeneous subsites.

Moving up from the subsites, we see a directory of subsite records. This directory serves as a "card catalog" that provides easy access to the subsites. There is a record for each subsite; each record consists of fields such as title, description, keywords, audience, format, and topic, which describe the contents of that subsite.

By creating a standardized record for each subsite, we are actually creating a database of subsite records. This database approach enables both powerful known-item searching and exploratory browsing. As you can see from the Search & Browse page, users can search and browse by title, audience, format, and topic.

The blueprint also shows three guides. These guides take the form of simple narratives or "stories" that introduce new users to the site's sponsor and selected areas with the web site.

Finally, we see a dynamic news billboard (perhaps implemented through Java or JavaScript) that rotates the display of featured news headlines and announcements. In addition to bringing some action to the main page, this billboard provides yet another way to access important content that might otherwise be buried within a subsite.

At this point in the discussion of the high-level blueprint, you are sure to face some questions. As you can see, the blueprints don't completely speak for themselves, and that's exactly what you want. High-level blueprints are an excellent tool for explaining your architectural approaches and making sure that they're challenged by your client or manager. Questions such as "Do those guides really make sense, considering the company's new plans to target customers by region?" will surface, and present an excellent opportunity to gain buy-in from the client and to fire-proof your design from similar questions much later in the process, when it'll be more expensive to make changes.

Presenting blueprints in person allows you to immediately answer questions and address concerns, as well as to explore new ideas while they're still fresh. You might also consider augmenting your blueprints with a brief text document to explain your thinking and answer the most likely questions right on the spot. At the very least, consider providing a "Notes" area (as we do in this example) to briefly explain basic concepts.

12.3.2. Digging Deeper into Blueprints

As you create blueprints, it's important to avoid getting locked into a particular type of layout. Instead, let form follow function. Notice the difference between Figures 12-2 and 12-3.

Figure 12-2. This blueprint illustrates the big picture for a consulting firm's public site

Figure 12-2 provides a holistic view of the information architecture for a global consulting firm. It's part of an initiative to build support for the overall vision of unified access to member firms' content and services. In contrast, Figure 12-3 focuses on a single aspect of navigation for the Weather Channel web site, aiming to show how users will be able to move between local and national weather reports and news. Both blueprints are high level and conceptual in nature, yet each takes on a unique form to suit its purpose.

Figure 12-3. while this one focuses on geographic hub navigation for the Weather Channel site

In Figure 12-4, we see a high-level blueprint for the online greeting card web site Egreetings.com. This blueprint focuses on the user's ability to filter cards based on format or tone at any level while navigating the primary taxonomy.

Figure 12-4. and this one demonstrates how filtering might work at Egreetings.com

It's important for information architects (particularly those of us with library science backgrounds) to remind ourselves that web sites aren't just about content; we can also contribute to the design of online applications and e-services. This work requires task-oriented blueprints, which are similar to the process flow diagrams often created by interaction designers.

For example, Figure 12-5 presents a user-centered view of the card-sending process at Egreetings.com prior to a redesign project. It allows the project team to walk through each step along the web- and email-enabled process, looking for opportunities to improve the user experience.

Figure 12-5. A task-oriented blueprint of the card-sending process

In Figure 12-6, information architect Austin Govella's blueprint demonstrates how casual browsers may become engaged in a political campaign over time by interacting with the site's content. This blueprint is as much about changes in the user's mind as it is descriptive of the site's content and navigation.

Figure 12-6. A blueprint depicting growing levels of engagement in a political candidate's campaign

You'll notice that as we dug deeper, we moved from high-level blueprints toward diagrams that isolated specific aspects of the architecture, rather than communicating the overall direction of the site. Blueprints are incredibly flexible; while boxes and connectors can't communicate everything about a design, they are simple enough that just about anyone can both develop and understand them.

You should also note that all of these blueprints leave out quite a bit of information. They focus on the major areas and structures of the site, ignoring many navigation elements and page-level details. These omissions are by design, not by accident. For blueprints, as with the web sites you design, remember the rule of thumb that less is more.

12.3.3. Keeping Blueprints Simple

As a project moves from strategy to design to implementation, blueprints become more utilitarianenabling the information architect to communicate to others involved in design and developmentand less geared toward strategy and product definition. "Lower-level" blueprints need to be produced and modified quickly and iteratively, and often draw input from an increasing number of perspectives, ranging from visual designers to editors to programmers. Those team members need to be able to understand the architecture, so it's important to develop a simple, condensed vocabulary of objects that can be explained in a brief legend. See Figure 12-7 for an example.

Figure 12-7. This blueprint legend describes an intentionally simple vocabulary

In this figure, the legend describes three levels of content granularity. The coarsest are content groups (made up of pages); these are followed by the pages themselves. Content components are the finest-grained content that makes sense to represent in a blueprint. The arrow describes a link between content objects; these can be one-way or bidirectional links.

This is a minimal set of objects; we've found that retaining a limited vocabulary helps the information architect avoid the temptation of overloading the diagram with too much information. After all, other diagrams can be used to convey other views of the architecture more effectively.

12.3.4. Detailed Blueprints

As you move deeper into the implementation stage, your focus naturally shifts from external to internal. Rather than communicating high-level architectural concepts to the client, your job is now to communicate detailed organization, labeling, and navigation decisions to your colleagues on the site development team. In the world of "physical" architecture, this shift can be likened to architecture versus construction. The architect may work closely with the client to make big-picture decisions about the layout of rooms and the location of windows; however, decisions regarding the size of nails or the routing of the plumbing typically do not involve the client. And in fact, such minutiae often need not involve the architect either.

Detailed architecture blueprints serve a very practical purpose. They map out the entire site so that the production team can implement your plans to the letter without requiring your involvement during production. The blueprints must present the complete information hierarchy from the main page to the destination pages. They must also detail the labeling and navigation systems to be implemented in each area of the site.

The blueprints will vary from project to project, depending upon the scope. On smaller projects, the primary audience for your blueprints may be one or two graphic designers responsible for integrating the architecture, design, and content. On larger projects, the primary audience may be a technical team responsible for integrating the architecture, design, and content through a database-driven process. Let's consider a few examples to see what blueprints communicate and how they might vary.

Figure 12-8 shows a blueprint from the SIGGRAPH 96 Conference that introduces several concepts (yes, we know it's an old example, but it remains useful and valid). By assigning a unique identification number (e.g., 2.2.5.1) to each component (e.g., pages and content chunks), the architect lays the groundwork for an organized production process, ideally involving a database system that populates the web site structure with content.

Figure 12-8. A blueprint of a major section of the SIGGRAPH conference web site

There is a distinction between a local and a remote page in Figure 12-8. A local page is a child of the main page on that blueprint, and inherits characteristics such as graphic identity and navigation elements from its parent. In this example, the Papers Committee page inherits its color scheme and navigation system from the Papers main page. On the other hand, a remote page belongs to another branch of the information hierarchy. The Session Room Layout page has a graphic identity and navigation system that are unique to the Maps area of the web site.

Another important concept is that of content components or chunks. To meet the needs of the production process, it is often necessary to separate the content (i.e., chunks) from the container (i.e., pages). Content chunks such as "Contact Us About Papers" and "Contact Us About This Web Site" are sections of content composed of one or more paragraphs that can stand alone as independent packages of information. (We'll discuss content chunking in more detail later in this chapter.) The rectangle that surrounds these content chunks indicates that they are closely related. By taking this approach, the architect provides the designer with flexibility in defining the layout. Depending upon the space each content chunk requires, the designer may choose to present all of these chunks on one page, or create a closely knit collection of pages.

You may also decide to communicate the navigation system using these detailed blueprints. In some cases, arrows can be used to show navigation, but these can be confusing and are easily missed by the production staff. A sidebar is often the best way of communicating both global and local navigation systems, as shown in Figure 12-8. The sidebar in the upper right of this blueprint explains how the global and local navigation systems apply to this area of the web site.

12.3.5. Organizing Your Blueprints

As the architecture is developed, it needs to accommodate more than just the site's top-level pages. The same simple notation can be used, but how can you squeeze all of these documents onto one sheet of paper? Many applications will allow you to print on multiple sheets, but you'll find yourself spending more time taping sheets together than designing. And if a diagram is too large to print on a single sheet, it's probably also too large to reasonably view and edit on a standard monitor.

Figure 12-9. A detailed blueprint illustrating several concepts

In this case, we suggest modularizing the blueprint. The top-level blueprint links to subsidiary blueprints, and so on, and so on. These diagrams are tied together through a scheme of unique IDs. For example, in the top-level diagram in Figure 12-9, major pages, such as the one representing "Committees and officers," are numbered 4.0. That page becomes the "lead page" on a new diagram (Figure 12-10), where it is also numbered 4.0. Its subsidiary pages and content components use codes starting with 4.0 in order to link them with their parent.

Figure 12-10. This subsidiary blueprint continues from the top-level blueprint

Using a unique identification scheme to tie together multiple diagrams helps us to somewhat mitigate the tyranny of the 8.5x11 sheet of paper. (Although you may still find that your architecture requires dozens of individual sheets of paper.) This scheme can also be helpful for bridging a content inventory to the architectural processcontent components can share the same IDs in both content inventory and blueprint. This means that in the production phase, adding content to the site is not much different from painting by numbers.

If you'd like to learn more about blueprints, we suggest visiting the IAwiki site for some excellent discussion on the topic (http://iawiki.net/SiteMaps).