Chapter 6
Page Structure

A structure must exhibit the three qualities of solidity, usefulness, and beauty.
—Marcus Vitruvius Pollio

Two major changes have influenced the profession of web design over the past decade, one evolutionary and one that has much more profoundly affected design thinking on the web. First, the latest versions of the web markup and styling languages—especially HTML5 and CSS3—were released, bringing new capabilities to “standards-based” web design. These changes to page markup finally reflected the real-world interests and behavior of web professionals, incorporating widespread coding practices into official W3C standards and making the web a much more friendly and capable place for web-based applications and complex interactivity. As interesting as they have been, the new markup languages reflect the steady evolution and growing maturity of the craft and tools of web publishing.

It’s the burst of new hardware and usage situations for web-based content that has created the biggest paradigm change in the way we think about web-based delivery of information. Today mobile hardware like smartphones and tablets gets most of the attention in this second, much larger change in the web, but the explosion in the size ranges and sheer diversity of mobile hardware and screens just presages an even bigger change now just beginning. The combination of ever-cheaper smart devices, near-ubiquitous wireless networking, and even tinier—and larger—viewports will make today’s “mobile-first” web design seem like the simple days of yore. When everything in your environment, from wall-sized environmental monitors to smart watches and other wearables, is a web-connected computer, you won’t use the web—you’ll live within it. Many of us already do.

Basics of Page Structure

Marking up page structure

Let’s look back for a moment at the way markup languages were headed in the mid-2000s. The state of the art then was a full embrace of carefully validated semantic XHTML markup, combined with CSS for page layout, typography, and basic page graphics. To use the capabilities of CSS for page layout, designers stuffed their HTML code with dozens of generic division <div> (and <span>) containers to hang their CSS markup upon, and the resulting explosion of <div> containers sometimes made even basic page layouts absurdly complex (fig. 6.1).

As these new page design practices became widespread, many designers noticed both the complexity and the redundancy of the new coding practices, and the implicit irony: page design with CSS was supposed to help simplify page markup. But because the new capabilities of CSS inspired designers to ever greater graphic complexity, markup code was becoming more complex than ever. In 2005 Google did a study that parsed the page code of more than a billion published web pages, specifically looking at how designers were using HTML class, <div>, and id names, and discovered common semantic patterns in page code. The dominant naming patterns were pretty logical, and centered on common page regions such as “header,” “footer,” “navigation,” and “content” or “main content.”

The explosion in the coding of <div> containers wasn’t just related to styling with CSS: it was also clear that if HTML was to mature as a markup language, it would have to incorporate a richer set of semantics to describe common content containers like sections, articles, and asides or pull-quotes. Designers were increasingly using the generic <div> container to both visually style blocks of content and make specific blocks of content more amenable to content syndication schemes like RSS, in order to make up for the markup restrictions of early-2000s HTML 4.0 and XHTML. Thus it was common to see markup like <div class="article">, <div class="section">, <div class="pullquote"> as designers struggled with the semantic limitations of XHTML.

The new HTML5 that gradually emerged in the late 2000s was designed specifically to address the needs of real-world web design for more logical page structural tags, a richer set of semantic markup for content, and tools for developing web-based applications. Many of the new markup tags in HTML5 were specifically designed to “pave the cowpaths” of contemporary web practice, bringing the informal but logical improvisations of real-world coding methods into the formal specifications for HTML5. In HTML5 there are now new sets of semantic markup tags to describe page structure and provide a richer set of content semantic tags.

Page structure semantics

Page structure semantics designate common types of pages regions like headers, footers, and navigation areas. Instead of needing to create many unique <div> ids to contain these common page elements, coders can use the new elements and style them directly. This regularizing of long-standing practice in page region layout makes it much easier for automated systems like search engines and browsers for the blind to find, highlight, or skip past structural elements on the page.

In addition to longtime HTML page structural tags like <head> and <body>, in HTML5 we now have these new tags to enrich the description of page elements:

New content semantic elements in HTML5

This is a partial list of the new content semantic elements in HTML5. The new elements provide a much more detailed way to label content sections and components so that search engines and other automated page-scanning systems can “read” the pages with more intelligence. More detailed content markup also makes it easier to reuse defined blocks of content like sections and articles.

HTML5 and CMSs like Drupal and WordPress

Most sites of more than a few pages should be built within a CMS like Drupal, WordPress, or other commercial CMS software, but these complex systems are slower to adopt changes in code standards. Measured against the significant practical advantages offered by a CMS, however, the lag in adopting the very latest code standards is a relatively minor concern. Both WordPress and Drupal are steadily incorporating HTML5 and CSS3 elements into their core releases. Neither of these two popular CMSs is yet a fully HTML5-based system, but the next major releases of both Drupal and WordPress will be based on HTML5 and CSS3. In the meantime, there are many fully responsive HTML5 themes for WordPress, and Drupal offers a combination of responsive themes and module-based means to bring HTML5 and CSS3 elements into Drupal 7. The new Drupal 8 due in 2016 promises to be fully HTML5 compliant.

Designing page layouts using CSS

Cascading style sheets (CSS) have been the mainstream way to lay out and visually style web pages for well over a decade, and they now handle complex typography and provide the foundation for responsive web design. As we have become more and more dependent on CSS for almost every detail of page design, CSS has become progressively more complex. The description for the second version of CSS was more than five times the length of the original CSS specification. The most current version of CSS is CSS3, and it is still very much a work in progress, as the specification is far more massive than that of CSS 2.1. The CSS3 project is so large that the W3C working groups have divided the CSS3 specification into more than fifty modules, some of which have been broadly implemented in browsers for years. But many CSS3 modules and specifications are still unimplemented, or only sporadically supported across desktop and mobile browsers.

Luckily, the web itself is the most up-to-date reference for the current state of web browser brands, versions, and support for the many new HTML5 and CSS3 elements and features. Here are a few reference sites that should be in your core set of web resources.

Testing for and current status of HTML5 and CSS3 elements and browser support:

Current web browser statistics:

As always with CSS updates there are dozens of new graphics, animation, transition, and page layout features in CSS3, but two new features stand out as significant—even foundational—enhancements of web technology: the @media queries that are the basis of responsive web design, and the @font-face element that finally frees web typography from the limitations of “web safe” operating system fonts or gimcrack font-replacement schemes. A slew of more minor but useful CSS3 typographic elements have also brought real typographic options to web pages. We’ll discuss web fonts and the CSS3 enhancements to typography in Chapter 9, Typography.

Encoding pages for optimal accessibility and readability

HTML source order is the sequence in which elements, such as site identity, navigation, primary content, related content, and footer information, appear in the document source code. Normally a reader of a web page doesn’t see the raw HTML code; he sees at least a minimally styled version of the HTML in the web browser window, and normally a web site has additional custom CSS code that creates the layout and typography we expect from finished web pages.

Proper HTML source code order matters for several reasons:

Modern web pages use style sheets to lay out the content, graphics, and navigation elements on web pages, maintaining a clear separation of HTML content and visual styling.

Selective display of page elements

Another aspect of document design is inclusion of elements that are relevant to different contexts and coding the document to allow elements to display or not, as appropriate. For example, although they are fundamental to any screen design, navigation links are not helpful when printed on paper. With a document coded for selective display, you can use CSS in the print style sheet to hide header or sidebar navigation links in printed versions of the page.

In print, seeing the full link urls may be helpful when you want to return to the page or cite the article, and this is easy to accomplish with CSS styling for print. Print CSS style sheets often hide HTML elements like navigation links, graphic page headers, and footer information. This results in a much cleaner printed version of the page, but sometimes readers are confused when what comes out of their printers looks so different from what they see on the computer screen.

See the Recommended Reading section at the end of the chapter for the best reference books on HTML5, CSS3, and responsive web design techniques.

Responsive Design

On May 25, 2010, designer Ethan Marcotte published “Responsive Web Design” in the magazine A List Apart, and the article and subsequent book of the same title changed the web design industry. With the concept of responsive web design, Marcotte brought together the new capabilities of CSS3 media queries, the quickly expanding universe of mobile computing hardware, and the realization among everyone creating web sites that mobile users were fast becoming the majority of web users—and that mobile users did not want a stripped-down, dumbed-down experience from their phones and tablets. Responsive web design (RWD) offered both a technical approach to making web sites more usable across the huge current range of computing viewports and an overarching philosophy that melds well with “mobile-first” design and content strategies.

Responsive web designs are built around three concepts:

Building on liquid layouts and proportional measurements

Many web designers have long advocated for “liquid” layouts—that is, web page designs that expand or contract based on the width of the browser window instead of being set to a fixed width. Fixed-width layouts were the most popular form of web design until a few years ago, and they have many virtues, particularly in complex page layouts where the gestalt visual design relationships (see Chapter 8, Graphic Design) helped make sense of the information on the page. But fixed web page layouts have many disadvantages as well: big designs (for desktop screens) or small designs (for mobile screens) are fixed, and do not easily adapt to a web world where screen sizes range from wristwatches all the way up to giant conference room monitors. Responsive design offers both a means to adapt to screens of any size and a way to recover some of that design control that was lost when we moved away from fixed layouts.

Responsive layout designs begin with a liquid layout grid based on a proportional set of percentage measurements instead of fixed pixel widths. Columns, gutters, border areas, and other spaces (in multicolumn layouts) are specified as percentages of the width of the browser window, and the whole design expands or contracts as needed to “fluidly” adapt to the available space. More sophisticated fluid layout and CSS styling also makes the typography proportional to a single base type size based on em (or rem) units. However, as shown in Figure 6.3, purely proportional liquid layouts don’t entirely solve the problem of many screen sizes, because on small screens a specification of width: 100% gives you absurdly squished layouts on small screens and absurdly stretched layouts on large screens.

Em-based typographic sizes (fig. 6.6) are important for two reasons:

Proportional images and media

Pictures and embedded videos can also be sized in proportional units, either in ems or in percentages of screen width. A handy bit of CSS code aids in this process. By specifying max-width: 100% in the CSS styling of a container for images or video, you can both proportionately size the container and assure that the image within the container always fills the container (100 percent of maximum width) but never exceeds the size of the container. Thus not only does page layout fluidly change to fill the browser window, but all images also fluidly change size as space dictates.

Given the wide range in screen sizes these days, how do you avoid the inefficiency of sending desktop-sized images to small-screen devices like phones and tablets? By using the HTML5 source set (srcset) attribute of image elements, or better yet, by using the new <picture> element, you can provide multiple sizes of an image, and the minimum width size appropriate for each image, so that phones get the small version and desktop screens get the large version.

So far so good, but pure liquid layouts don’t fully solve the problem of many screen sizes, because a proportionately miniature layout on a smartphone isn’t usable without a lot of zooming to enlarge the layout text to legible size.

Media queries

The media queries introduced with CSS3 form the crucial third piece of responsive design, as media queries allow you to custom-tailor your layout, typography, and embedded media to best match the available space within the user’s browser window, or viewport.

Although they are primarily used to investigate the width of the web browser display width, media queries can deliver much more information on the nature of the user’s display device, including:

Media queries offer a means to conditionally test various aspects of the user’s display screen, then to selectively load style sheets that respond to those conditions and provide the most appropriate layout, typography, and graphics. These style sheets for specific ranges of screen sizes are normally triggered by CSS3 media queries designed to activate at certain minimum sizes, or “breakpoints.” You can see the style breakpoints easily on a responsive site like the Guardian newspaper (theguardian.com) or the Boston Globe (bostonglobe.com). On your desktop or laptop computer, gradually reduce the width of your web browser window and you’ll see the layout first squeeze to fit the frame, and then suddenly jump to a new layout style as you hit a “breakpoint” keyed to a minimum width of the browser window.

The following media query sets the width of the main content area (container) to 970 pixels when the viewport is greater than 1,200 pixels wide.

@media (min-width: 1200px) { .container { width: 970px; }}

Responsive design isn’t simply about stretching or miniaturizing a page layout—it’s about delivering a unique layout of the content and navigation that is best optimized for a particular range of screen sizes. Most responsive designs use at least three different layout style sheets keyed to viewport width breakpoints for smartphones, tablets, and larger desktop or laptop screens. We’ve shown sample breakpoint measurements here (fig. 6.9), but there are no magic or universal formulas for positioning design breakpoints. The most important factor is how your layout, content, and functionality look across the likely range of devices your audience will use. Look at your unique case and needs, and set your design breakpoints accordingly.

Responsive designs often style the primary navigation links of a site differently in each responsive style sheet—for example, a compact pop-up menu for smartphones, a compact layout of links for tablet screens, and a more expansive and conventional layout for desktop screens.

Responsive designs rarely expand to fit the entire screen of large desktop monitors and laptops. An absurdly wide page design would ruin most layout schemes, and the long line lengths for text would make the content less legible.

Resources for responsive design techniques

The coding details of responsive design are beyond the scope of this book, but we’d recommend the following references if you want to learn responsive techniques for HTML5 and CSS3. Matthew MacDonald’s HTML5: The Missing Manual is a great place to start for a solid grounding in basic responsive design. Ethan Marcotte’s Responsive Web Design is a more advanced look at responsive coding techniques, but Marcotte is a great explainer of the logic and philosophy behind RWD, and his book is a must-read even if you don’t plan to code your own responsive pages or themes. Stephen Hay’s Responsive Design Workflow is a great resource for examples of how to integrate responsive design philosophies and techniques into a comprehensive planning, design, and development project. See the Recommended Reading section at the end of this chapter for details.

Pairing responsive design and mobile-first design

Responsive design starts from a “reference resolution” and uses media queries and customized style sheets to adapt to other screens sizes. Increasingly the reference resolution is the smartphone-sized mobile version of the site, which is then scaled up to adapt to larger viewports.

Designer Luke Wroblewski first advocated the “mobile-first” design philosophy as a response to the explosive growth of mobile computing and mobile web use. Mobile web users now outnumber desktop users, and it is no longer practical to design multiple versions of a web site to separately accommodate the needs of mobile and desktop users. Mobile users want a full web experience, not a stripped-down “mobile site” with just basic information.

Prioritized content and functionality

Given the severe layout and bandwidth constraints of smartphones, a mobile-first design approach forces a development team to look hard at the central priorities and needs of all users, not just mobile users, and to create sites that have stripped away a lot of the graphic and textual bloat that adheres to designs that begin with a large desktop layout. On mobile screens there simply isn’t room for the nice-to-have stuff—only the must-have stuff will fit.

Rather than defaulting to a desktop version of the site and then later trying to cram all the content and navigation into a small format, the mobile-first approach builds up from the most critical content and functionality and gradually adds secondary material and features as space allows. This focused mobile-first approach comports well with responsive design techniques, and agile project management that emphasizes a constant focus on high-priority goals and features.

In a common mobile layout, the material in sidebar columns tends to be pushed down below the “main” content column, resulting in a tall stack designed to fit within the tight confines of a mobile screen. However, CSS layouts give you complete control over where various semantic HTML containers (<header>, <main>, <nav>, <article>, <section>, <aside>) or other <div> containers are placed on the screen for mobile breakpoints. Carefully consider the priorities for your various page elements before burying them three screens deep in your mobile layout. For example, the content or navigation material that was at the top of your sidebar column may also belong near the top of your smartphone layout. Make your layout decisions based on content and navigation priority, not on simple layout formulas.

Universal access

Perhaps the most important benefit of a mobile-first design approach—if done properly—is that even users with older browser versions, browsers with JavaScript absent or turned off, and screen reading browsers for people with vision impairments all get a basically functional single-column site with all content and links in place. Mobile-first is an elegant example of the progressive enhancement philosophy, under which no user—even one with an older or otherwise limited browser—is unable to access the core content and features of the site. Users with more up-to-date browsers, better hardware, and larger screens get an enhanced and richer experience, but no one is locked out.

Starting from content and functionality

As you might guess in looking at sophisticated, highly responsive sites, doing design work for such plastic and changeable responsive designs in static Photoshop comps can limit the design thinking needed to communicate the use experience across smartphones, tablets, and larger screens. The older methods of producing pixel-perfect Photoshop files that show all the visual details of template and content pages tend to push the development process in exactly the wrong direction: toward the old desktop-first, large-screen-first ways of thinking, with little feel for the subtle but important effects of interactivity, or the different possibilities of each responsive design breakpoint and layout.

Our advice is to make your “short list” of must-have items on the most minimal of mobile environments, and build up from there. On paper or whiteboards sketch out the core functional and content areas of your major screens, and translate those rough sketches into simple block diagrams that your page coders can use to create real responsive HTML and CSS mock-ups for study. While the responsive designs are built, your graphic designers can begin creating color palettes, logo graphics, example photos or artwork, typography sample sheets for each screen size, and perhaps style tiles to gradually introduce more sophisticated visuals after the functionality and content strategy of your interactive mock-ups have matured. At every step along the way your graphic designers should be involved as the designs mature, guiding their graphic and typographic evolution and gradually adding visual details that progressively enhance the mock-ups and early functional versions. Form follows function in mobile-first, browser-first development, and Photoshop becomes the last tool you use, not the first.

The point is to do as much design as possible in HTML and CSS, building from that foundational “mobile-first” simplicity and progressively enhancing the design as space and browser capabilities expand. Only when all important strategic, content, functional, and code decisions have been made should you invest in detailed Photoshop work, and then only to provide final polish to the finished graphic elements.

Using best practices

Responsive web design is far more than just adding media queries and a few extra style sheets to your page code; it’s a new design philosophy that provides a richer, more accessible experience to all of your audience, on whatever device each may be using when she visits your site.

Page Structure Components

Web “sites” are complete abstractions—they don’t exist, except in our heads. When we identify a site as such, what we’re really describing is a collection of individual linked pages that share a common graphic and navigational look and feel. Creating the illusion of continuity across a cohesive “site” are the design features that pages share, such as their CSS and page graphics. Individual HTML pages, including how they are designed and linked, constitute the atomic unit of web sites, and everything that characterizes site structure should appear in the page templates.

Structuring a page

As the web has matured over the past decade, the structure of web pages in text-driven information sites has become more uniform and predictable. Although not all web pages share the exact layout and features described here, most web pages incorporate some or all of these basic components, in page locations that have become familiar to web users (fig. 6.12). Recent responsive design systems have tended to simplify header and navigational frameworks, particularly for smaller mobile screens.

If you work within a larger organization, always make your relationship to the larger enterprise a clear and meaningful part of your site design. If your institution has an identity program, use it. Adopting the design standards of the larger enterprise can save you a lot of time and money. Institutions notorious for poor governance—universities, government agencies, large nonprofit agencies—also often have chaotic web sites. Large companies sometimes have the same problems, but the standards and norms of corporate identity programs are well established in the business world, and most corporate sites start with the expectation that everyone will share a common look and feel and user interface and that each discrete corporate site will project a clear relationship to the parent enterprise.

Page headers and site identity

Page headers are like miniature versions of the home page that sit atop each page and do many of the things that home pages do, but in a limited space. Headers provide site identity and global navigation, with search and perhaps other tools. The exact location and arrangement of the components vary from site to site, but the overall design pattern has become fairly consistent.

Headers are the most visible component of site identity. What seems real is real: a collection of pages that share headers will be perceived as a “site” even if the pages originate from various technical sources (blog software, portal systems, SharePoint, web applications, content management systems, and so on). One reason that complex enterprise sites get cluttered and confusing for users is that multiple enterprise software vendors are involved, with each vendor reluctant to do much to conform to local design standards. This is as much a software procurement problem as a design problem:

You’ll be pleasantly surprised to see how often “our software doesn’t really allow customization” becomes “of course we can do that” if you negotiate compliance with your enterprise design standards before signing a software vendor contract.

Home link

Placing your organization or site logo in the upper left corner of the page—and linking that logo to the home page—is probably the most widely used design convention on the web, and one you should always use, except in special instances like complex forms, “shopping cart” checkout processes, and other instances where you want the user’s intention fully engaged on the process. If you are not using a logo or graphic in your header, at least put a “home” link near the upper left corner of the page, where 99.9 percent of users will expect to find it.

Global navigation

Headers are the most frequent location for global navigation links that span the site. The ideal arrangement is to use an HTML list of links, styled with CSS appropriately for each viewport size in your responsive page designs. This gives you:

Tabs are another widely used, easily understood convention for global navigation, particularly in the desktop-sized versions of page templates. The way to implement tab-based navigation links for larger screen designs is to style an ordinary HTML list with CSS treatment to form the “tab” graphic look around each link. Be sure you get the tab graphic details right: the selected tab should be graphically unambiguous, and the remaining tabs should clearly be behind the selected tab. This type of “you are here” marker is essential in orienting users within the site. Tabs can also be used to implement a two-tiered navigation scheme, in which a secondary horizontal list of links appears under the selected tab, again as a simple HTML list with CSS styling, to keep things semantic, accessible, and search visible (see fig. 6.2).

In designs for smaller mobile viewports the common practice is to collapse the main navigation list normally within the page header into a smaller “navicon” or “trigram” symbol to save space (HTML character &#9776;). The trigram became a mainstream web navigation convention when high-profile responsive sites like Starbucks and Twitter Bootstrap adopted the symbol for navigation in their smaller viewport designs. The trigram is now so common that responsive sites like the Guardian and Slate magazine use the trigram for navigation even on their large “desktop” layouts.

Breadcrumb navigation

Breadcrumb navigation is a widely used, easily understood navigation device that is particularly useful in large sites with deep levels of content organization (see Chapter 7, Interface Design). Breadcrumbs integrated into the header are best at the top of the header, as in the Library of Congress site (see the black header bar, fig. 6.13). Another popular location for breadcrumb navigation is below the header navigation, just above the main page <h1> title and content.

Search

All sites with more than a few dozen pages should offer local site search. The upper right area of the header is the standard location for search boxes (fig. 6.13). Make sure your search box is not too small to accommodate long queries. One study showed that a box twenty-seven characters long would accommodate 90 percent of search queries. Amazon’s search box holds more than twice that (fifty-seven characters).

Shopping cart

Long ago, Amazon put its “cart” link in the upper right of the header, and that’s where virtually all other shopping sites put it now, too. Don’t buck the trend; it’s one of the most firmly rooted interface conventions on the web.

Advertising

Ad-supported sites often reserve a large area above other header components for banner advertising, and research shows that users commonly expect to see banner ads in this area of the page. This layout convention has important implications, even if your site does not use banner ads, because of the widely observed phenomenon of “banner blindness.” Readers commonly ignore areas of the screen that usually contain advertising, especially if the graphic content looks like a banner ad. Be sure your headers and other page graphics don’t use the heavily boxed and graphically loud visual vocabulary of most banner ads, or your readers may ignore important elements of your user interface.

Sidebar column

Subdividing the page field into functional regions is a fundamental characteristic of modern graphic design. Early in the web’s history, designers began using narrow sidebar columns at the edge of the page to organize navigation links and other peripheral page elements, much as scan columns have been used in print publications for a century or more. Research on web user expectations now supports the common practice of locating navigational links—particularly section or navigation—in the left column. The right sidebar is often used for advertising, so be sure that any graphic content you place there doesn’t look like an ad or your readers may ignore the area.

Sidebars are also useful as locations for web search boxes, mailing address and contact information, and other more minor but necessary page elements. Research shows that the left scan column under the local navigation links is the second place most users will look for search features, after they look in the right header area.

Basic “real-world” information about who the company responsible for the site is, where the company is, and how to contact the company is often hard to find on otherwise well-designed sites. If you sell a product or service, don’t hide from your customers. Display your contact information in a prominent location, such as the scan column, on every page.

Left or right sidebars for navigation?

Some eye-tracking and user research says that it doesn’t matter a great deal whether you use left or right navigation columns, although left sidebars are more common, and a number of studies find bias toward them probably because they are so common. Users seem to do just fine either way, as long as you are consistent about where you put things. Designers who favor left navigation often cite English-language reading habits and the Gutenberg diagram (see fig. 8.15), but the diagram shows that although the top left corner gets the most reader attention, the top right corner is not too far behind. Advertising is more common in the right sidebar, so users often overlook that area. We generally favor the left column for navigation simply because that is the most common practice, and taking advantages of established conventions is a good thing.

Main content

Web content is so multifaceted that few general rules apply, but the following common practices make content areas easier to use:

Footer

Page footers are mostly about housekeeping and legal matters, although they can sometimes be useful for nonessential navigation as well. These elements need to be on the page, but place them somewhere out of the way:

Page footers can also be used for repeating global site links. An expanded footer composed of text links adds hardly any size to the page but offers an unobtrusive place to list a carefully chosen set of links. ibm’s well-designed navigation footer is almost like a site map on the bottom of every page.

Optimizing pages for fast delivery

From about 2007 to 2010, web designers enjoyed a period during which web standards were finally coming together across the range of web browsers, the desktop view was the only consideration, and most of our audiences had enough bandwidth at home and work to enjoy web pages with lots of pictures and even video. While the picture for desktop users continues to improve every year, the rise of the mobile web has made bandwidth and constraints on web media an issue once more. Although mobile networks and wireless speeds continue to improve, mobile web computing is still quite constrained by relatively slow page load speeds. The slowness of the web on mobile devices led to the explosion of iOS and Android apps to improve performance of networked services on mobile devices.

While the web publishing and design industries have long since begun to address the needs of mobile users, our addiction to big images, huge CSS and JavaScript payloads, and audiovisual media has continued to bloat the overall size of web pages. The average size of web pages and their associated media and CSS files more than doubled between 2010 and mid-2013 (fig. 6.15).

As mobile performance challenges have become more widely understood, the rate of increase in web page size has slowed, but overall web performance continues to be a balancing act between our appetite for media-rich content and our love of fast web pages. Page performance has direct and important consequences, particularly for online merchants. Walmart found that conversion rate (the rate at which shoppers become active buyers) plunges if a page takes more than four seconds to load (fig. 6.16).

This doesn’t mean that you must remove all of the media from your pages, but it does mean that developers and designers need to squeeze every byte out of the overhead of pages, particularly those heavily used by mobile audiences. Techniques such as using the HTML5 srcset attribute or the <picture> element to specify several sizes of an image (think small, medium, large) to deliver the right-sized image depending on screen size, squeezing the compression rate of every image, using the gif format for small geometric graphics and icons that would be larger in jpeg format, avoiding the use of many twenty-four-bit transparent-background png images, using SVG graphics wherever possible, and using compact symbol fonts to efficiently deliver icon graphics are all commonly employed to squeeze unnecessary bits out of web graphics. See Chapter 11, Images for more information on web graphics.

Designing around “the fold”

In 1994, the earliest days of the World Wide Web, human interface researcher Jakob Nielsen found that users of the first web browsers and web sites seemed reluctant to scroll to see portions of web pages hidden below the bottom of their display screens, and noted the importance of positioning material at the top of web pages. Three years later Nielsen retracted his finding that “web users don’t scroll,” because his later research showed that as users adapted to the new web medium they did indeed scroll to see content on the lower parts of web pages. Unfortunately, the “users don’t scroll” dictum proved more memorable than the later retraction, and this mistaken meme has persisted in web design.

The roughly 115 square inches at the top of a home page on a standard desktop monitor constitute the most visible area of the web site. Most desktop or laptop users will be looking at your site on 19–22-inch monitors or on laptop screens, and the top 8–9 vertical inches (about 900–1,000 pixels) are all that is sure to be visible on average screens, perhaps less on the short, wide screens of most laptops. The measures for various mobile screens differ, of course, but the basic effect is the same: the top part of the typical web page is visible, and the rest of the page is not visible unless the user scrolls. The “above the fold” metaphor refers to the middle fold in classic folded broadsheet newspapers like the New York Times or Wall Street Journal. Front-page stories “above the fold” are the most important and visible in both newspapers and web pages.

Although web users do scroll when they use the web, a number of studies have shown that there is a distinct fall-off of views in the portion of web pages that users must actively scroll to see. Eye-tracking studies done by the Nielsen-Norman Group have shown that the tops of web pages get about 80 percent of the attention (strictly speaking, eye-tracking gaze fixations on the page), with only 20 percent of fixations left for page areas “below the fold” that users must scroll to reveal. Google conducted a study on the relative visibility of web advertisements on various page locations and also found that visibility drops off sharply at the fold, as did a similar study by Chartbeat (fig. 6.17). The Google study also showed a drop-off in visibility “below the fold” on smaller mobile devices, but the effect was less pronounced, especially on smaller phone screens on which users are accustomed to scrolling to see page content.

However, the Google and Chartbeat studies both showed that while attention and visibility do indeed drop at “the fold,” about half of users do see material well below the fold line (roughly 900 pixels down the page). These studies also noted something that sounds a bit counterintuitive if you assume that the tops of pages are always the most visible areas: the top of the page was not the most reliably visible part of the page. Because pages are complex and often load slowly, impatient users often begin to scroll down a page before the page top has fully rendered. Users are also well aware that the page top is commonly used for advertising, and is therefore a less rewarding place to look for information. User attention and advertising visibility seem to peak between 500 and 800 pixels down the page, quite near the roughly 900-pixel fold area on most desktop and laptop screens. Chartbeat also noticed that web readers who chose to scroll down the page often spent more time there than in the “above the fold” region, suggesting that when readers found the page content compelling, they would continue to read down the page. Taken together, these studies suggest that “the fold” is not a hard-and-fast line between full attention and no attention, that the bottom visible areas above the fold get great attention, and that the dreaded “fold line” may be less important in design than previously thought. Our own conclusions are that the fold area remains a significant transition zone, and that critical material on the page is best placed no lower than 600–700 pixels down the page to guarantee visibility on desktops and laptops.

Designing screens of information

Most web page designs can be divided vertically into zones with different functions and varying levels of graphics and text complexity. As vertical scrolling progressively reveals the page, new content appears and the upper content disappears. A new graphic context is established each time the reader scrolls down the page. Web page layouts should thus be judged not by viewing the whole page as a unit but by dividing the page into visual and functional zones and judging the suitability of each screen of information. Notice the vertical structure of the Guardian home page. The top screen of information is much denser with links because it is the only area all users will see (fig. 6.18).

Obviously, in responsive web design what constitutes a “screen’s worth” of information will vary considerably, depending on the width of the screen in use and the CSS “breakpoint” in use. Frequently assessing the effect of various screen sizes on your evolving responsive design is yet another great reason to do as much of your design work in “live” HTML and CSS within the browser window.

Page Templates

Always start your page template or CMS theming work with an internal page, because the internal page template will dominate the site. The home page is important, but the home page is inherently singular and has a unique role to play. Your internal page template will be used hundreds or thousands of times across larger sites, and the navigation, user interface, mobile responsiveness, and graphic design of the internal pages will dominate the user’s experience of your site. Get your internal page design and navigation right, and then derive your home and secondary page designs from the internal page template (fig. 6.19).

Internal page templates must establish these important functions:

Creating templates for internal pages

In larger sites containing a variety of content, your internal page template may be a set of templates that vary in details, such as the number of columns, to accommodate the range of content and user interface needs (see fig. 6.19).

Sites that incorporate web applications, blog or wiki formats, or complex forms may need a simplified template variation that strips away some of the usual site navigation elements. Applications, complex forms, large data tables, and many kinds of highly graphic content (artwork, engineering drawings, repair manual graphics, and so on) usually require as much screen space as possible.

Secondary page templates

Most sites are organized in a multitiered hierarchy, with vertical dimensions (home, secondary pages, internal pages) and a horizontal spread of distinct content regions that graphically and organizationally help the reader navigate. Secondary page templates should be closely related to the internal page template but must accommodate these additional functions:

Secondary page templates help create a concrete sense of the vertical dimension of sites and may perform varied functions in the tiers between the home page and the internal content pages, such as special-purpose “landing pages” tied to advertising campaigns or publicity, where you want the readers to arrive at your site and immediately receive information relevant to the advertising that brought them to your site.

Navigation and submenu pages

Complex, multitiered sites usually need submenu pages to provide an organizing and navigational focal point for major subsections or regions of the site. These submenu pages are effectively the home page for that block of content.

Alternate “front doors” or “landing pages”

Many marketing or communications campaigns that point to web sites require a focused, immediately recognizable page to bring in visitors. These alternate entry points must bear a clear graphic and topical relation to the marketing graphics, featured product, or communications theme, but because they also function as alternate home pages, they should orient visitors to the larger site navigation as well.

Department or program home pages

Large corporate or enterprise sites require secondary or even tertiary levels of pages that act as home pages for the local department or program. In a multitiered site your template system should establish a clear hierarchy of page header labeling and titles so that readers can see the relation of a department page to the larger enterprise.

Designing a template for the home page

Designing an effective home page can seem daunting, but if you’ve already thought through the fundamentals of your site navigation and have done the hard work of creating internal and secondary page templates, you have a great head start. Designing the home page layout last allows you to acknowledge the unique introductory role of the home page but places the design firmly within the larger navigational interface and graphic context of the site.

Home pages have four primary elements:

Good home page designs always blend these four factors. How you blend them depends on the overall goals of your site, but most good home pages do not balance all four elements equally. Home pages often have a distinctive theme in which one factor dominates. Amazon’s home page is all about navigation to products. Yale University’s home page projects identity. The Atlantic site is dominated by timeliness and content. Google’s famously lean home page is all about tools. An effective home page can’t be all things to all people. Decide what your priorities are, and build a home page that gives the user a clear sense of theme and priority.

Drop-down menus

When there is a lot of content or many merchandise categories to fit on the home page, pull-down menus can provide many choices within a small screen area. The space savings, though great, come at a cost to visibility and usability, because most choices are hidden until the user activates the menu. Careful navigation design can yield an effective hybrid strategy, in which you don’t rely on drop-down menus but rather provide them as enhanced functionality for users who choose to explore them.

Drop-down menus can be implemented well using HTML, CSS, and/or a bit of JavaScript. Although a standards-based HTML/CSS drop-down menu will be somewhat accessible and visible to search engines, the full menu functionality that users expect from their Mac and Windows interfaces is not possible to reproduce using web tools alone. Web drop-downs tend to be slower and less forgiving of errors in mouse positioning than menus on Mac or Windows operating systems. Older users and users with less hand-eye coordination often dislike drop-down menus, especially if they are implemented with small font sizes and small cursor target areas.

Topical navigation versus path-splitting

Users usually arrive at a home page with specific topical or product interests or functional goals in mind. Most home pages thus feature prominent navigation lists or visual menus of topics, products, and services. Sometimes, however, users identify their interests by their identity or role. For example, it’s common for university sites to “split paths” on the home page into prospective students, current students, parents, faculty, and other groups, and then to present various submenu pages oriented to the interests and needs of each group (fig. 6.20).

Recommended Reading

Figures from Chapter 6: Page Structure on Flickr