Modular Web Design: Combine
This chapter is from the book
This chapter is from the book
This chapter is from the book
Up to now, there's been much talk of breaking pages apart, chunking them into component pieces. In the early phases of a design process, initial page designs suggest an array of components.
But once we've identified many chunks, it's time to use those components to construct pages. This chapter will address how to do the following:
- Assemble components into page layouts.
- Appreciate how components fit into variations of a single page as well as across the context of many different pages.
- Take advantage of component relationships, including duplicates, bundles, and page shells.
- Formulate page regions so that components can be more simply explained and consistently applied.
- Appreciate the relationship between components in layout and code.
Assembling Pages
No matter the value of components, it is the page that is rendered in a browser. Each time the browser loads a page (or even a portion of a page), a user experiences the content and interactivity of a complete, aggregated view. Sure, the user's glance may home in on and bounce between chunks of interest. But that bounce is around a layout of all the pieces arranged together.
As components evolve, vary, and mature, they must be combined and arranged into the pages serving as the cohesive whole. With components in hand, a designer is better equipped to communicate design through a wider array of page variations. Now it is time to see and confirm what works and what doesn't. Combine components in meaningful layouts, relate chunks together, relate pages together in a flow, and get a feel for what's too complex, what's too simple, and what needs to be rethought from the ground up.
Once pages are divided into sets of independent components, they are generally reassembled with one of two goals: assemble a page based on a collection of components, or convey how a component appears and varies across pages.
A Page of Components
As one communicates a design, participants in design reviews often ask the question "OK, but how would an article appear under these other circumstances?" Even if a designer has created variations that address the display state of every component in question, it's too much to expect others to be able to see the page in their mind's eye. Instead, the designer must be prepared to render additional examples to reinforce the modular nature of the design and answer that question.
For example, an article page could use many different components depending on available content (Figure 4.1). Sure, every article includes body content and framing chunks not really related to the article itself (header, footer, sidebar). But many chunks can be optionally included: different types of article titles (in the upper left); inline media, such as photos and videos (in the upper right); and related articles and tasks.
)
Figure 4.1 Numerous vital components that can be used modularly on an article page, but lack the context of use when they stand alone.
But outside the context of page layouts, so many questions go unanswered. Every article can be printed, shared, and emailed, but where does that widget go? Can the article be mapped to other related articles? If so, where would that list be placed? Can we position an inline video within the article? Where would a photo carousel go? Is that in the same place as the inline photo gallery? How would the article appear if it's part of a special event or ongoing series, like a blog?
To answer those questions, it's not enough to just design the components individually. We also need to recombine them in viable page layouts to depict applicable scenarios.
Figure 4.2 displays an article page in different circumstances and reinforces the use of all the components in concert. Notice how each article has a title, author, and key tasks, such as print and email. But the vertical location and relationship of those components varies relative to the inclusion or omission of other optional components.
)
Figure 4.2 Article pages of varying depth and component quantity.
Also implicit in the page layouts is the relative use of components. For example, you can establish the context of the article within a series by placing an additional component above the article title (see variation D, which includes a box above the page title). Additionally, you can clarify that an inline video, photo carousel, and photo gallery should not be used together; instead, you can choose one and only one to include in the upper right of the article body. Keep in mind that you cannot just rely on different pictures to convey these points; also include annotation to reinforce the distinctions.
A Component Across Pages
Additionally, a designer can communicate the range of component use through page variations that demonstrate a single component used in pages with different layout, purpose, or context. These displays reinforce what the designer may have already assumed, but stakeholders may not have realized: Components are indeed reusable!
Take the video player from the article page, with a few important states as shown in Figure 4.3. Sure, inline videos may be associated with an article as helpful, supplemental content. However, videos can be surfaced, played, and related to other content across many different page types.
)
Figure 4.3 Variations of a video player, ready to be reused in different contexts.
Therefore, reinforce the video player's flexibility by including it in page layouts across the site. Pages highlighting products, telling a story, or supporting a how-to demonstration can have very distinct layouts (Figure 4.4). But the inline video player can easily be reused in each instance.
)
Figure 4.4 A mini video player reused in different page types: article page (on the left) and product features (on the right).
Such scenarios help designers show reuse and negotiate tradeoffs. At times, stakeholders push and push to embed features and displays that limit the component reuse in other contexts. Their goals are clear and justified, but such design decisions can cost an organization more in the long run. Which makes more sense: a team building distinct video players for each scenario, or reusing one common player that ends up meeting 90 percent of everyone's needs?
Additionally, page variations establish how flexibly a component can be repurposed to fit different user needs and page types. Pagination is a common component that displays what page you're on and how many pages there are, and enables navigation across each "page" of results (Figure 4.5). Here, a page may not be a browser page, but more a set of any object type, such as search results, photographs, blog entries, users, email, or events. Pagination requires many variations, including first page, last page, and pages in the middle when there are more or fewer page links than can be displayed at one time.
)
Figure 4.5 Standard variations of a typical pagination component that reveals current page, clarifies overall set quantity, and enables navigation across pages.
Ideally, pagination is consistent across an entire site design. The use of pagination may apply to an entire page's context or to a narrower and tighter single component (such as photographs).
This flexibility is evident in the range of pages where pagination can be used (Figure 4.6). Notice how the component is displayed both above and below search results on one page, but only at the base of a sortable table on another page. Each uses the same component, omitting a few elements here and there, and juxtaposing the summary of the page ("Results 11–20 of 55") on the left against the navigation across pages on the right. Showing pagination in each context is helpful in understanding its flexibility: Overall width depends on the container it sits within, and pieces can be included or omitted based on the designer's judgment.
)
Figure 4.6 A pagination component used in two contexts: search results and data tables.