This chapter is from the book
This chapter is from the book
This chapter is from the book
Common Combos
While pages are chunked into independent components, you may find that two (or more) adjacent components find themselves used together often. While each component may need to be divided, varied, and documented separately, it may often be positioned with others. That there is a perceived relationship isn't necessarily a bad thing. Even more, you'll want to arrange your design artifacts and reusable items to enable you to add common combinations quickly.
Duplicates
The most common case of combinations is duplicate component use. Here, a component is repeated numerous times vertically, horizontally, or even as a grid across a page.
Figure 4.7 displays a stack of frequently asked questions (FAQs), grouped into categories on a page dedicated to FAQs.
)
Figure 4.7 A frequently asked question and answer component, repeated once for every question.
Here, the FAQ component consists of two elements: question and answer. Each instance of the component is stacked down the page and includes some variations to communicate the use of bulleted and numbered lists. Communicating the structure of an FAQ is important, answering many questions: What can I include in an FAQ? How do I structure the content? How long can one be? But seeing the FAQs in layout depicts how they fit in the context of categories, anchor links, and other pieces of a page.
Similarly, suppose you were creating a high-level page that linked to a number of different product types, each featured in a separate but duplicate component (Figure 4.8). In this case, you'd repeat the component three times in the page layout. However, each instance adheres to the same guidelines: a general header, thumbnails and links for each item, exactly three features per component, etc. In this case, it may even help to include actual content in place of labels, such as [Product Types] and [Destination], if the rendered page needs to be more specific.
)
Figure 4.8 A string of feature collections across the body of the page.
Duplicates enable you to define the necessary states, behaviors, and editorial guidelines of a single instance without worrying about or trying to define exactly how many can go on a page. Avoid creating distinct variations for sets of three, four, five, and six instances of an entirely duplicated component. Instead, define it once and establish guidelines on quantity and layout arrangements.
Bundles
In other cases, instead of duplicating the same component, you may want to frequently use a component with one or more other components. A component bundle includes multiple, distinct components, such as a local navigation bar combined with promotions underneath, or a stack of components in a right rail. Such bundled use is often correlated with frequent creation of an individual page or suite of pages.
In the previous examples depicting variations of an article page, did you notice that the components in the right sidebar did not change? The display of those components—Contact Us, Sign In, and Downloads (Figure 4.9)—could be highly correlated and repeated across many pages, beyond just articles.
)
Figure 4.9 A component bundle reused frequently in a sidebar: Contact Us, Sign In, and Downloads.
Designers, stakeholders, and engineers will begin to notice such patterns, as will users who start to expect that they are always displayed together. However, clearly all three components have different purposes, different independent states (such as signed in versus not signed in), and may be reused elsewhere alone. So resist the urge to document the entire stack as a single component. Instead, note the correlation and describe when and why they should be used together.
Shells
Getting started on a new page design should be easy. Open a template, drop in the oft-reused header and footer, and then fill in the details of what makes a page unique.
Given that some of the first components you'll codify and prepare for reuse are the header, footer, and possibly local navigation, it may be worthwhile to create a composite "page shell" out of these items (Figure 4.10). That way, starting a new page doesn't require adding seven individual items, but instead dragging and dropping an entire frame.
)
Figure 4.10 A page shell that includes a header and sidebar but lacks a footer whose vertical location depends on body content.
Once you've added components to your page design, it makes sense to store them on a separate layer and lock the layer. This prohibits you from selecting the components as you work on the remainder of the page. With the layer locked, you won't mistakenly select a fixed portion of the design, whether by clicking on it with your mouse pointer or using Select All.
Page shells always contain a page header (such as site logo, utility navigation, site search, and primary navigation) and may contain a left or right sidebar that contains local navigation, contact options, or other common components.
Why not the footer? Well, the footer's location is indeterminate. Page height can vary substantially, moving the footer higher or lower on the page. That said, you could still include a footer in a page shell without locking it with the shell items above it. Footers should definitely be included in a page shell where the user interface has a fixed height.
Some designers suggest that this page shell should be integrated into the page design template. That way, you can open a file and the shell will already be placed and locked. This offers significant efficiency in page start-up time, but comes with a few drawbacks, too. What if your site design has more than one type of page shell, such as separate shells for marketing copy, ecommerce, and a member portal? Then you start embedding a lot of unnecessary artwork and the template file—which should be a lightweight starting point—starts to get bogged down.
Additionally, now you are in the business of embedding components into templates, which can become a maintenance nightmare. When components change (even a slight labeling change in a header navigation bar), you now must remember to update not just the reusable component, but every instance where it's been embedded as a starting point for a page design. Plus, other designers may assume that since they have the new header component, their template may not need updating. They may continue to use the template starting point with the now-incorrect header.
Regions
The shell concept hinges on a higher-level breakdown of pages into different, identifiable areas. Most all pages include regions for the header, footer, and body content. That said, many design systems take a regional perspective further, establishing left and/or right rails and even well-defined regions within the body of the layout.
Regions afford a well-defined and understandable way to think of a page as a bento box (Figure 4.11). The bento box is a Japanese serving tray partitioned into different areas, each intended to contain a different portion of the meal. To designers using components, the page layout serves as a bento box, with each partitioned area a destination to drop components.
)
Figure 4.11 A bento box, partitioned into areas in which different portions of a meal are contained.
(Source: http://www.fl ickr.com/photos/t_trace/2323732013/)
For many reasons, it is helpful to identify regions, such as the following:
- Containers for engineers that transform page layout into high-level markup (commonly, hierarchies of <div>s into which component code is authored)
- Identified page areas for documenting where a component can—and cannot—be used
- Visual blocks into which a designer can insert components within a layout
- Potential component categories when organizing items into a library (refer to Chapter 9, "Organize")