Blasting the Myth of the Fold

Written by: Milissa Tarquini

The Above-the-Fold Myth

We are all well aware that web design is not an easy task. There are many variables to consider, some of them technical, some of them human. The technical considerations of designing for the web can (and do) change quite regularly, but the human variables change at a slower rate. Sometimes the human variables change at such a slow rate that we have a hard time believing that it happens.

This is happening right now in web design. There is an astonishing amount of disbelief that the users of web pages have learned to scroll and that they do so regularly. Holding on to this disbelief – this myth that users won’t scroll to see anything below the fold – is doing everyone a great disservice, most of all our users.
First, a definition: The word “fold” means a great many things, even within the discipline of design. The most common use of the term “fold” is perhaps used in reference to newspaper layout. Because of the physical dimensions of the printed page of a broadsheet newspaper, it is folded. The first page of a newspaper is where the “big” stories of the issue are because it is the best possible placement. Readers have to flip the paper over (or unfold it) to see what else is in the issue, therefore there is a chance that someone will miss it. In web design, the term “fold” means the line beyond which a user must scroll to see more contents of a page (if it exists) after the page displays within their browser. It is also referred to as a “scroll-line.”
Screen performance data and new research indicate that users will scroll to find information and items below the fold. There are established design best practices to ensure that users recognize when a fold exists and that content extends below it1. Yet during requirements gathering for design projects designers are inundated with requests to cram as much information above the fold as possible, which complicates the information design. Why does the myth continue, when we have documented evidence that the fold really doesn’t matter in certain contexts?

Once upon a time, page-level vertical scrolling was not permitted on AOL. Articles, lists and other content that would have to scroll were presented in scrolling text fields or list boxes, which our users easily used. Our pages, which used proprietary technology, were designed to fit inside a client application, and the strictest of guidelines ensured that the application desktop itself did not scroll. The content pages floated in the center of the application interface and were too far removed from the scrollbar location for users to notice if a scrollbar appeared. Even if the page appeared to be cut off, as current best practices dictate, it proved to be such an unusual experience to our users that they assumed that the application was “broken.” We had to instill incredible discipline in all areas of the organization that produced these pages – content creation, design and development – to make sure our content fit on these little pages.

AOL client application with desktop scrollbar activated

AOL client application with desktop scrollbar activated

As AOL moved away from our proprietary screen technology to an open web experience, we enjoyed the luxury of designing longer (and wider) pages. Remaining sensitive to the issues of scrolling from our history, we developed and employed practices for designing around folds:
* We chose as target screen resolutions those used by the majority of our users.
* We identified where the fold would fall in different browsers, and noted the range of pixels that would be in the fold “zone.”
* We made sure that images and text appeared “broken” or cut off at the fold for the majority of our users (based on common screen resolutions and browsers).
* We kept the overall page height to no more than 3 screens.

But even given our new larger page sizes, we were still presented with long lists of items to be placed above the fold – lists impossible to accommodate. There were just too many things for the limited amount of vertical space.
For example, for advertising to be considered valuable and saleable, a certain percentage of it must appear above the 1024×768 fold. Branding must be above the fold. Navigation must be above the fold – or at least the beginning of the list of navigational choices. (If the list is well organized and displayed appropriately, scanning the list should help bring users down the page.) Big content (the primary content of the site) should begin above the fold. Some marketing folks believe that the actual number of data points and links above the fold is a strategic differentiator critical to business success. Considering the limited vertical real estate available and the desire for multiple ad units and functionality described above, an open design becomes impossible.

And why? Because people think users don’t scroll. Jakob Nielsen wrote about the growing acceptance and understanding of scrolling in 19972, yet 10 years later we are still hearing that users don’t scroll.
Research debunking this myth is starting to pop up, and a great example of this is the report available on ClickTale.com3. In it, the researchers used their proprietary tracking software to measure the activity of 120,000 pages. Their research gives data on the vertical height of the page and the point to which a user scrolls. In the study, they found that 76% of users scrolled and that a good portion of them scrolled all the way to the bottom, despite the height of the screen. Even the longest of web pages were scrolled to the bottom. One thing the study does not capture is how much time is spent at the bottom of the page, so the argument can be made that users might just scan it and not pay much attention to any content placed there.

This is where things get interesting.

I took a look at performance data for some AOL sites and found that items at the bottom of pages are being widely used. Perhaps the best example of this is the popular celebrity gossip website TMZ.com. The most clicked on item on the TMZ homepage is the link at the very bottom of the page that takes users to the next page. Note that the TMZ homepage is often over 15000 pixels long – which supports the ClickTale research that scrolling behavior is independent of screen height. Users are so engaged in the content of this site that they are following it down the page until they get to the “next page” link.

Maybe it’s not fair to use a celebrity gossip site as an example. After all, we’re not all designing around such tantalizing guilty-pleasure content as the downfall of beautiful people. So, let’s look at some drier content.
For example, take AOL News Daily Pulse. You’ll notice the poll at the bottom of the page – the vote counts are well over 300,000 each. This means that not only did folks scroll over 2000 pixels to the bottom of the page, they actually took the time to answer a poll while they were there. Hundreds of thousands of people taking a poll at the bottom of a page can easily be called a success.

AOL News Daily Pulse with 10x7 fold line and vote count
AOL News Daily Pulse with 10×7 fold line and vote count

But, you may argue, these pages are both in blog format. Perhaps blogs encourage scrolling more than other types of pages. I’m not convinced, since blog format is of the “newest content on top” variety, but it may be true. However, looking at pages that are not in blog format, we see the same trend. On the AOL Money & Finance homepage, users find and use the modules for recent quotes and their personalized portfolios even when these modules are placed well beneath the 1024×768 fold.

Another example within AOL Money & Finance is a photo gallery entitled Top Tax Tips. Despite the fact that the gallery is almost 2500 pixels down the page, this gallery generates between 200,000 and 400,000 page views depending on promotion of the Taxes page.

It is clear that where a given item falls in relation to the fold is becoming less important. Users are scrolling to see what they want, and finding it. The key is the content – if it is compelling, users will follow where it leads.

When does the fold matter?

The most basic rule of thumb is that for every site the user should be able to understand what your site is about by the information presented to them above the fold. If they have to scroll to even discover what the site is, its success is unlikely.

Functionality that is essential to business strategy should remain (or at least begin) above the fold. For example, if your business success is dependent on users finding a particular thing (movie theaters, for example) then the widget to allow that action should certainly be above the fold.

Screen height and folds matter for applications, especially rapid-fire applications where users input variables and change the display of information. The input and output should be in very close proximity. Getting stock quotes is an example: a user may want to get four or five quotes in sequence, so it is imperative that the input field and the basic quote information display remain above the fold for each symbol entered. Imagine the frustration at having to scroll to find the input field for each quote you wanted.

Where IS the fold?

Here is perhaps the biggest problem of all. The design method of cutting-off images or text only works if you know where the fold is. There is a lot of information out there about how dispersed the location of fold line actually is. Again, a very clear picture of this problem is shown on ClickTale. In the same study of page scrolling, fold locations of viewed screens were captured, based on screen resolution and browser used. It’s a sad, sad thing, but the single highest concentration of fold location (at around 600 pixels) for users accounted for less than 10% of the distribution. This pixel-height corresponds with a screen resolution of 1024×768. Browser applications take away varying amounts of vertical real estate for their interfaces (toolbars, address fields, etc). Each browser has a slightly different size, so not all visitors running a resolution of 1024×768 will have a fold that appears in the same spot. In the ClickTale study, the three highest fold locations were 570, 590 and 600 pixels—apparently from different browsers running on 1024×768 screens. But the overall distribution of fold locations for the entire study was so varied that even these three sizes together only account for less than 26% of visits. What does all this mean? If you pick one pixel location on which to base the location of the fold when designing your screens, the best-case scenario is that you’ll get the fold line exactly right for only 10% of your visitors.

So what do we do now?

Stop worrying about the fold. Don’t throw your best practices out the window, but stop cramming stuff above a certain pixel point. You’re not helping anyone. Open up your designs and give your users some visual breathing room. If your content is compelling enough your users will read it to the end.

Advertisers currently want their ads above the fold, and it will be a while before that tide turns. But it’s very clear that the rest of the page can be just as valuable – perhaps more valuable – to contextual advertising. Personally, I’d want my ad to be right at the bottom of the TMZpage, forget the top.

The biggest lesson to be learned here is that if you use visual cues (such as cut-off images and text) and compelling content, users will scroll to see all of it. The next great frontier in web page design has to be bottom of the page. You’ve done your job and the user scrolled all the way to the bottom of the page because they were so engaged with your content. Now what? Is a footer really all we can offer them? If we know we’ve got them there, why not give them something to do next? Something contextual, a natural next step in your site, or something with which to interact (such as a poll) would be welcome and, most importantly, used.

References

fn1. Jared Spool UIE Brain Sparks, August 2, 2006:”Utilizing the Cut-off Look to Encourage Users To Scroll”:http://www.uie.com/brainsparks/2006/08/02/utilizing-the-cut-off-look-to-encourage-users-to-scroll/

fn2. Jakob Nielsen’s Alertbox, December 1, 1997: “Changes in Web Usability Since 1994”:http://www.useit.com/alertbox/9712a.html

fn3. ClickTale’s Research Blog, December 23, 2006: “Unfolding the Fold”:http://blog.clicktale.com/2006/12/23/unfolding-the-fold/

Introduction to the Building Blocks

Written by: Joe Lamantia

The Building Block System

This story continues the Introduction to Building Blocks Series.

Part 1 of this series “The Challenge of Dashboards and Portals” discussed the difficulties of creating effective information architectures for portals, dashboards, and tile-based information environments using only flat portlets, and introduced the idea of a system of standardized building blocks that can effectively support growth in content, functionality, and users over time. In enterprise and other large scale social settings, using standardized components allows for the creation of a library of tiles that can be shared across communities of users.

Part two now outlines the design principles underlying the building block system, and the simple guidelines for combining blocks together to create any type of tile-based environment.

Overview

The building block system is a packaged toolkit that offers standardization across several layers of an information environment, including the information architecture, the user experience, the functionality, and the metadata. As a potential framework for standardization, it is most important to understand that the building blocks are inclusive rather than exclusive, and that they are neutral with regard to any specific software solution, vendor, package, programming language, system architecture, development platform, business rules, enterprise environment, or user experience design guidelines.

Consequently, adopting the building block system and approach – at the right level of formality for a particular set of business, technology, and information architecture needs – can help resolve some of the many problems inherent in flat portlet-only design approaches (the box of chocolates model) regardless of the context. Potential applications or contexts of use for the building blocks include:

  • Any experience defined by stock portlets
  • Any environment assembled from custom built or customized off the shelf [COTS] tiles
  • Intranets and extranets
  • Content aggregators
  • Collaboration environments and solutions such as SharePoint, eRooms, etc.
  • Personal publishing platforms and group authoring solutions
  • Wikis and other collaboratively authored knowledge organization structures
  • Web-based personal desktop services such as Google and Netvibes
  • Mashups services and platforms such as Yahoo Pipes and Google Gears
  • Social networking platforms such as Facebook, Myspace, etc.
  • The rapidly expanding collections of public domain widgets

The building block system defines two types of information architecture components in detail – building blocks (or Containers), and navigation components (or Connectors) – as well as the supporting rules and guidelines that make it possible to assemble complex user experience architectures quickly and effectively. The block system is not a pre-packaged dashboard or portal design. Instead, it offers modular components you can rely on to work together and grow coherently as the pieces making up a finished dashboard or enterprise portal. Using the blocks will help focus design efforts on the important questions of what content to provide, how to present it to users, and how to manage it effectively.

The complete package includes:

  1. Basic principles and assumptions underlying the block system, and how it can complement other design approaches.
  2. Assembly guidelines and stacking hierarchy which shows how to combine blocks into larger units while ensuring a sound and consistent information architecture.
  3. Modular building blocks of all sizes (Containers)
  4. Modular navigation components (Connectors)
  5. Standardized Convenience Functionality for blocks, which recommends a baseline set of common capabilities such as export of building block content, printing Tiles, etc.
  6. Common Utility Functionality which captures common productivity enhancements and capabilities linking the block-based system to other enterprise systems such as calendars and document repositories.
  7. Suggested metadata attributes for blocks that support administration and management needs, as well as important classes of utility functionality including alerting, syndication, searching, collaboration, and system administration.

1. Basic Principles and Assumptions

A few basic principles inform the design of the building block system and establish its boundaries with regards to other design systems or paradigms. In sum, they outline an open, flexible, well-structured, and internally consistent system. While the building blocks are independent of many constraints for where and how they may be put into effect, they will be most effective when a limited set of assumptions about the underlying environment are true. Those assumptions include the availability of authentication functionality to verify user identities, a role-based security framework that allows security permissions to be set at the level of individual blocks, a reasonably robust network that doesn’t require design for asynchronous use, and standard service levels for source application and system hosting and maintenance to ensure the steady availability of aggregated content and functionality.

Principle:Openness

The building block system is open: using the building blocks does not mean that every piece of content must appear within a Tile (Tiles are the smallest building blocks, the de facto foundation level). In the same way that many sites supported by content management systems include considerable amounts of content that is not directly managed by the CMS, it is easy to mix block-based and free-form content in the same Dashboard or Portal, and even on the same Page. Mixing content may require you to give up some of the benefits of the building block system, depending on your platform and other infrastructure elements, but this is not sufficient reason to try and wedge everything into a poorly designed Tile.

Openness
Figure 5: Openness

Principle: Portability / Syndication

The building blocks support portability and syndication by design, under the assumption that individual building blocks or groups of blocks can and will appear outside their original context or in more than one context (if not immediately, then at some point in the future). With the right IT infrastructure and environment in place, it is possible to share defined blocks of all sizes amongst a suite of integrated dashboards/portals or other environments tailored to different audiences, or with other applications and systems. The structure, presentation, and attributes of the building blocks look ahead to the creation of a large library of assets that diverse consumers throughout the enterprise or in the broader community can use and reuse.

Portability
Figure 6: Portability / Syndication

Principle: Independence

Building blocks are wholly independent of one another, unless stacked together into a larger unit. This means that while one block may offer controls or functionality that manipulate its contents, neither those controls nor that functionality will affect neighboring blocks unless the blocks are stacked together.

Independence
Figure 7: Independence

Principle: Inheritance

The blocks follow a simple inheritance pattern, wherein nested blocks inherit the properties and behaviors of blocks with a higher stacking size stacked above them. (Keep in mind that the literal ‘size’ of a block – what kinds and how much content it can contain – is not determined by its stacking size. The purpose of the stacking size is to assist designers in creating experiences with consistent behavior and structure.) If a block at a higher level offers the ability to change its contents with a Control Bar, these changes affect all blocks stacked inside, cascading down from the highest level of the stack. If a block contains other blocks nested at several levels of the stacking hierarchy, and those blocks offer controls that change their contents, then changes affect all of the blocks nested within (or stacked below).

Inheritance
Figure 8: Inheritance

Principle: Layering

The building blocks work together as a coordinated system across multiple levels of the layer cake that comprises an information environment, from the user experience – visual design, information design, interaction design, information architecture – to functionality, metadata, business logic, and administration. It is possible to use the blocks to effect standardization at the level or layer of your choosing. For example, you could rely on just the presentation standards for identifying Container blocks to establish consistent screen layouts. Or you could put all the aspects of the block system into practice to drive the structure of a suite of integrated sites from top to bottom.

Layering
Figure 9: Layering

2. Assembly Guidelines and Stacking Hierarchy

The building block system relies on a small set of assembly guidelines and a size-based stacking hierarchy to ensure that it is easy to understand how to properly combine blocks together into larger units. The purpose of the guidelines and stacking hierarchy is to maintain the internal consistency of information architectures organized and managed via the building blocks. The hierarchy assigns each block a stacking size, ranging from one to seven, and specifies a few simple rules for stacking blocks of different sizes. To see if it is possible to stack blocks together, compare their stacking sizes in light of the rules below.

Note: The Container blocks will be defined in detail in Part 3 of the series.

Stacking Hierarchy
Figure 10: Stacking Hierarchy
This illustration shows the stacking hierarchy of the Container blocks, from the Tile – smallest, with a stacking size of 1 – to the Suite – largest, with a stacking size of 7.

Here are the assembly guidelines to determine proper block stacking:

  1. It is possible to stack blocks with a lower stacking size (“smaller” blocks) inside blocks with a higher stacking size (“larger” blocks).
  2. It is possible to stack several smaller blocks inside a larger block, for example placing three Tile Groups [size 2] inside a single View [size 3].
  3. It is not possible to stack a larger size block inside a smaller block. This means you can stack several Tiles [size 1] inside a single Tile Group [size 2], but you can’t stack a Tile Group [size 2] inside a Tile [size 1].
  4. It is possible to stack several sequential sizes of blocks together inside a single larger Container. This is the basic pattern for assembling a complex user experience.
  5. It is possible to skip a level of the stacking hierarchy when stacking several layers of blocks, for example by stacking Tiles [size 1] within a View [size 3], without placing them within a Tile Group [size 2].
  6. It is possible to stack different sizes of blocks together at the same level inside a larger Container.

As an example of the last three rules, a single Page [size 4] could include a View [size 3] and two Tiles [size 1] stacked at the same level. Inside the View are one Tile Group [size 2], with two Tiles [size 1] stacked inside the Tile Group, and two additional separate Tiles [size 1].

stacking example
Figure 11: Stacking Example

Social Building Blocks Mechanisms and Network Effects

Thanks to these largely open system principles and flexible assembly guidelines, the building blocks can provide a lightweight skeleton that allows communities and groups of any size to create and use tile-based content and functionality within coordinated structures and processes, and then benefit from the network effects and social mechanisms that common structure and architecture makes possible.

With the support of basic environmental services such as tagging, rating, linking, search or findability, syndication, notification, and clear status signals, the building blocks can enhance well-known social processes or collective effects including:

  • sharing
  • comparison and interpretation
  • synthesis
  • remixing and mashup
  • opportunistic discovery
  • the emergence of collective consensus
  • crowdsourcing
  • exchanges with affiliate networks
  • the formation of specialized sub-communities
  • functional diversification

The building blocks can support all these social and network effects across the continuum of transparency and social involvement, from fully closed enterprises, to private and semi-public forums, to fully transparent or public contexts.

In the near future, Part 3 of the series will define the building blocks in detail.

Practical Plans for Accessible Architectures

Written by: Frances Forman

If the relationship between accessibility and architectures intrigues you, see the Editors’ Note at the end of this article for more information about what we’re doing and how to get involved.

The United Nations recently commissioned the world’s first global audit on web accessibility. The study evaluated 100 websites from 20 different countries across five sectors of industry (media, finance, travel, politics, and retail). Only three sites passed basic accessibility checkpoints outlined in the Web Content Accessibility Guidelines(WCAG 1.0), and not a single site passed all checkpoints.

These guidelines are well established and were first advocated by the W3C in 1999. They simplify the knowledge required to produce accessible code and content. Despite developments in assistive technologies and web content, these guidelines are still invaluable today. They provide developers and editors with a foundation for creating accessible design, which is essential to people who have different access requirements. A second version of the WCAG is now available as a public working draft (WCAG 2.0).Nevertheless, a challenge remains in determining which members of the design team are responsible for accessibility. As more people are involved in the design, development, and editorial process, there needs to be agreement on how to best design for content management and customization, while also allowing for greater accessibility.

Accessible design requires a deeper understanding of context. It’s about providing alternative routes to information, whether that route is a different sense (seeing or hearing), a different mode, (using a tab key or a mouse), or a different journey (using an A to Z site index instead of main navigation). However, accessibility is much easier to achieve when the right foundations are put in place as prerequisites during site planning and strategy.

Approaches to Designing for Accessibility

 

Labeling and controlled vocabularies

Controlled vocabularies can have a positive impact on accessibility by supporting the development of contextually relevant navigation and consistent, understandable labeling. The WCAG 1.0 , Guideline 13 in particular, is written to ensure that navigation is meaningful to people who process information in different ways.

A person using a screen reader can call up a link summary for a given page or tab through links to obtain a general gist of the site. These browsing methods requires web developers to create navigation link descriptions that can be understood without reference to surrounding page context. For example, the purpose of a link should be clear. A user should not have to rely upon nearby visual elements or textual content to understand its meaning.

A dialog showing an automatically generated list of links over the Boxes and Arrows events page

Image 1: A link summary from a Boxes and Arrows page.

Different types of navigation taxonomies allow pages to be defined using both concise and longer contextual link names. This allows naming conventions to retain their consistency and ensures that the right amount of context is displayed across the entire site, not just in the main navigation. For A to Z indexes and site maps, more context is needed to distinguish choices presented to the user. Using contextual names in an index ensures that users are not confused by identical labels that might lead them to different destinations.

Navigation frameworks and wireframe design

When designing indexes and supplementary navigation, it is important to consider how different HTML elements can help shape information. Sometimes headings are a useful way to cluster menus, but it’s often more helpful to make headings active links to prevent important information from being lost.

An easy way to evaluate the hierarchy or order of page elements, such as headers and lists, is to use the “Firefox Accessibility Extension;”:https://addons.mozilla.org/en-US/firefox/addon/1891 its navigation tool displays the underlying semantic structure and ordering of HTML elements.

A headers dialog showing the structure of the Boxes and Arrows events page

Image 2: Selecting the navigation menu from the Firefox toolbar to display a list of page headers.

When developing a framework for navigation, it’s important to consider how users move between different menu systems. A front end developer will need to determine whether a skip link should read “skip to main menu” or “skip to content”. However, if IAs choose to use several different menu systems—perhaps to maintain organization—they should document the priority of menus and suggest practical uses for skip links. This will help developers define document structure and effectively use skip links. The structure of information elements depends on whether the page is high level and navigation-focused, or low level and content-focused.

The diagram below shows how the tab key allows users to move between links on the Boxes and Arrows events page. The heading levels serve as a guide so users can access menus (with the aid of shortcut keys). This type of semantic markup helps users of assistive technologies navigate more easily. Even if they are using a linear form of access such as audio, it’s possible to skim the page for information.

A page with styling removed and the order highlighted between different structural elements
Image 3: A wireframe illustrates page order and structure, as well as ideas for skip links

Ready deliverables

These diagrams can help web developers define and optimize page structures by organizing information elements early in the design process. Dan Brown’s page description diagrams demonstrate an effective way of communicating information elements, rather than using a set layout to display them.

When wireframing, IAs can use annotations to support designers and developers in meeting accessibility checkpoints. Nick Finck’s wireframe stencils can be used to identify Headings 1, 2, 3, etc., and illustrate how they should be ordered to display a logical hierarchy on the page. For example, the events list above is structured using the H3 tag. Describing each event as a list item conveys that the section is an index of upcoming events. This is beneficial to people who use assistive technologies, as there are commands that allow users to to skim the page from header to header or list to list.

While these approaches are helpful, they are not panaceas. There is ambiguity regarding correct semantic markup for complex pages. Consider homepages, where one may have top story headings, event listing headings, page section headings, and menu headings. How does the developer or designer determine the proper hierarchical structure for headings; how should they simplify the page so its purpose and structure are more understandable?

Widgets vs. Browser functionality

Another debate centers on how and where accessible design should be implemented. Consider text change widgets that enable users to enlarge or decrease font size. Resizing text is better left to user agents and browsers so that content displays more consistently. However, text widgets have become common page tools, as browser-based text resizing is hidden from users and most are unaware of this feature. Solutions to this problem include creating a user help page explaining how browser functionality works, or referring users to sites that explain browser customization and the benefits of assistive technologies. The BBC’s My Web My Way offers such examples. This site provides instructions on changing browser settings, text-background color, font size, and explains how to use assistive technologies.

However, one needs to consider whether its more beneficial to provide instructions, which may eventually become outdated, or direct users to an external site to learn about a particular technology.

Alternative ways to view content

An important aspect of accessibility is providing alternative ways to use and view information. Presenting information in a user’s desired format (indicated by his or her profile) would increase accessibility. Strategies to deliver alternative views include the following:

  • Reuse of information through alternative formats. For example, the ability to change the format of a document on the fly from PDF to RTF or XML is supported by some CMS systems.
  • Google Map’s HTML view conveys information about geographic locations in a format that can be read aloud by a screen reader.
  • Multimedia resources can be made more accessible through the addition of captions or transcripts. Inexpensive, “automated captioning web-based services”:http://www.automaticsync.com/ and websites that enable users to “tag video content”:http://www.viddler.com/ are making translations of this sort easier to implement.
  • Leveraging application programming interfaces (APIs), as “demonstrated by T.V. Raman”:http://googleblog.blogspot.com/2007/02/web-apis-web-mashups-and-accessibility.html of Google, can produce mashups, which offer alternative ways to view a particular data source. They enhance accessibility by providing customized views when a one-size-fits-all solution does not work. For example, services that offer map data at two times the normal magnification could be a resource for users with poor or corrected vision.

These examples demonstrate that accessibility is not just about compliant code. It requires an understanding of how information can be structured and transformed to make user interaction more flexible.

Customization strategies

Taking the idea of tailoring information access one step further, there is also scope for implementing user profiles or customization strategies to meet a specific audience’s needs. Imagine a website where navigation, search results, and content can all be accessed dynamically according to a user’s barriers to information, content needs, or disabilities.

Hildegard Rumetshofer and Johannes Kepler explore requirements (paid download) for providing comprehensive accessibility as part of a tourism information service. They illustrate how a system could deal with four distinct questions about a person’s information and service needs:

1. Does the tourism service meet individuals’ access requirements? (medium profile)
2. Is the tourism service able to meet individuals’ specific interests? (user profile)
3. Is information presented in an accessible, barrier-free format? (WAI guidelines)
4. Can search or access services be specifically tailored to individuals’ disabilities? (search and metadata strategy)

Accessibility is becoming more dependent on the design of an information system’s components, and no longer a simple question of how content is presented. This is an arena where IAs excel.

Getting started

Understanding the importance of accessibility in the design process is only the beginning. Information architects need to understand accessibility considerations so they can design practical, inclusive solutions. A good starting point is the Web Accessibility Initiative’s (WAI) website and its guidelines and techniques page. The following guidelines provide additional information and resources.

  • Web Accessibility Content Guidelines : http://www.w3.org/TR/WAI-WEBCONTENT/(WCAG 1.0, 2.0 in draft)
    Established checkpoints written for designers and developers to help them create accessible code and content.
  • Authoring Tool Accessibility Guidelines: http://www.w3.org/TR/WAI-AUTOOLS/(ATAG)
    Useful for projects that concern requirements for information management or the procurement of a new CMS.
  • User Agent Accessibility Guidelines: http://www.w3.org/TR/WAI-USERAGENT/ (UAAG)
    Intended for the developers of assistive technologies and browsers, these recommendations can help IAs understand the interplay between different sets of guidelines. For example, some information design problems are better handled by browsers and assistive technologies, while others are better handled by individual sites.

Conclusion

Accessibility audits and benchmarks remind us of the difficulties disabled people encounter when attempting to negotiate their way through today’s online media. Information architects need to think about representing pages of information as linear streams, not just wireframing a collection of adjacent menus and content.

Creating an accessible web experience requires the coordination of independent groups. Initiating, managing, and designing for accessibility starts with strategy and ends with site evolution, content creation, and quality assurance. As IAs we should be advocating, designing, and supporting teams that provide equal access to information, as well as easier access for our primary personas. We should be looking for practical, design-driven ways to make accessibility a consideration through every phase of a project, and not just an afterthought.

While accessibility requires expert web developers to maintain high levels of access (especially on larger sites), it still needs the help of IAs who understand the scope and constraints that lead to accessible design, and who are conscious of the duty to prevent discrimination when making information management decisions.

Resources

Introductions
“BBC’s My Web My Way”:http://www.bbc.co.uk/accessibility
“W3C Web Accessibility Initiative”:http://www.w3.org/WAI/
A to Z Site Indexes

“BBC”:http://www.bbc.co.uk/a-z/a.shtml
“Somerset County Council”:http://www.somerset.gov.uk/somerset/atoz/index.cfm?letter=a

Alternative Views on Content

“Google Blog: Web APIs, Mash Ups and Accessibility”:http://googleblog.blogspot.com/2007/02/web-apis-web-mashups-and-accessibility.html
“Google Video Help Center”:http://video.google.com/support/bin/answer.py?answer=26577
“RoboCal”:http://www.robocal.com/prod/robocal/main.php
“Semantic Maps and Meta-data Enhancing e-Accessibility in Tourism Information Systems, IEEE Computer Society”:http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/proceedings/dexa/&toc=comp/proceedings/dexa/2005/2424/00/2424toc.xml&DOI=10.1109/DEXA.2005.176
“Tagging Multimedia Content”:http://www.viddler.com/

Communities

“Accessify Forum”:http://www.accessifyforum.com/
“Dublin Core Accessibility Metadata Community”:http://dublincore.org/groups/access/

Debates and Futures

“Accessibility Panel, UK”:http://www.isolani.co.uk/blog/access/BarCampLondon2AccessibilityPanelThoughts
“The Great Accessibility Camp-out”:http://accessites.org/site/2006/10/the-great-accessibility-camp-out/

Standards and Guidelines


“Introduction to WCAG Samuri Errata for Web Content Accessibility Guidelines (WCAG 1.0)”:http://wcagsamurai.org/errata/intro.html
“Web Standards Project”:http://www.webstandards.org/action/atf/

 

Editors’ Note

 

Our “podcast with Derek Featherstone”:http://www.boxesandarrows.com/view/straight-from-the19 marks the start of a theme for Boxes and Arrows. Accessibility guidelines are not only beneficial to those who need special affordances to experience our products more fully. Taking these recommendations and “web standards”:http://www.webstandards.org/ into considerations will guide what you build, strengthen its inherent structure, and help to encourage the development of better products for everyone.

Over the next several months, we’re looking to further explore these ideas as they apply to designers and the designer-developer relationship. Contribute to the series by sending an idea. (Eds.)

Two Designers, Two Years, One Facelift…

Written by: Alex Chang

I can’t recall how or when I first learned of the Boxes and Arrows redesign contest. On July 5, 2004, I sent an email to a good friend, Matt Titchener, proposing that we enter the contest together. I got to know Matt while working with him at a nonprofit organization developing intranet web applications. We discovered that we shared the same appreciation and views toward usability, accessibility, web standards, and visual design. Matt is also one of those rare talents that possess great design ability as well as a keen technical understanding in web development/design. After confirming Matt’s interest in the contest, we embarked on what would become more than a two-year journey to redesign Boxes and Arrows.

The contest

From the start, Matt and I agreed to take this contest seriously, approaching it as if we were revamping a website for an actual client. We spent much time studying the existing site hierarchy and brainstorming for ways to produce better user experience. We knew that we didn’t have to convince Boxes and Arrows’ audience of all the invaluable and insightful articles and discussions on the site. It was only a matter of how to get readers to the content more effectively. We were looking to accomplish a very intuitive navigation and site structure/flow to allow the readers to reach their desired content with the fewest clicks possible. It took us roughly a month to create our initial design concept (see Figure 1 & 2), which we are still quite pleased with even to this day. Then with about four days remaining to the deadline, I revisited the contest guidelines and comments posted by the Boxes and Arrows staff. I realized that the B&A folks were looking for a fresh and entirely different look, but the design that we created still too closely resembled the existing site (with its color scheme and layout).

I became convinced that in order for us to have a better chance at winning the contest, we would have to rethink our concept. So painfully, we decided to put aside the design that we had worked so hard on, and started from scratch with a different visual approach. After a few sleepless nights, with heavy bags under our eyes, we submitted our new design concept less than two hours before the contest closing time (see Figure 3 & 4).

Then we waited…

Three months later, I received an email with the subject line “Congratulations!! You have the winning Boxes and Arrows Site Redesign Submission.” I habitually ignore and delete all email that has subject lines beginning with “Congratulations!! You have won…”, assuming spam, so I nearly missed this one! Not until I read through my inbox more carefully later that day and recognized it was from Erin Malone, did I realize that we had actually won the contest. I immediately rang up Matt in London to share the good news with him. I stopped everyone that passed my desk that day to tell them all about the contest. The announcement of our win put a fixed grin on my face for days to come.

front page
Figure 1: First iteration of the front page design

author page
Figure 2: First iteration of the author’s page design

front page contest
Figure 3: Final front page design submitted to the contest

category page contest
Figure 4: Final category page design submitted to the contest

Redesigning the redesign

In January of 2004, we began working with Christina Wodtke and Erin Malone on the implementation of the design. During one of our initial conference calls, we asked for permission to create another design concept different from the one we submitted. Since we only had a very short timeframe to put together the contest entry after our decision to start from scratch, we felt that we did not have adequate time to create a design that fully represented our capability or design vision. Christina and Erin kindly agreed to our request.

For the next nine months, we went through many rounds of brainstorming sessions, looking at ways to improve the visual presentation, the functionality, and the structural flow of the site (see Figures 5-7).

site structure proposal
Figure 5: Site structure proposal submitted with the design

issue transition
Figure 6: Idea for how articles should flow/transition through the front page from issue to issue

site map
Figure 7: Proposed sitemap

The folks at Boxes and Arrows made it clear from the onset that they would like to see B&A take on more of a magazine look instead of the blog-centric feel that it had previously. We began looking at various print magazines like Time, Wired, Newsweek, and National Geographic, trying to figure out what elements in periodical cover designs make people quickly recognize a magazine when they see one. We identified strong typography, compelling imagery, and the concept of weekly or monthly issues as the elements that we would like to bring into our site design. (“Transcending CSS”:http://www.transcendingcss.com, a book recently written by Andy Clarke, includes chapters entitled “Marking Up the World” and “Looking for Grids Outside the Web” touching upon the approach of bringing visual elements from different media to the web.) A few weeks later, we created a mockup of the front page. This mockup became the foundation of the design that you see today.

second redesign
Figure 8: First iteration of second redesign

Design ideas and solutions

Instead of a traditional navigation menu, we incorporated a tag cloud into the site’s left navigation design. Because of the variety of categories listed in the left navigation, we initially took this approach not only to highlight the categories with the higher number of articles, but we felt that different font weight distributions in the navigation menu would also draw the users’ attention to the category list. We invested much time in creating the best algorithm and rendering method to make this work effectively. At the end, B&A decided to leave this piece out after the site launch due to the arrangement of the current taxonomy on the B&A site and the evenly distributed number of articles across the categories (which negates the reason for having a tag cloud to highlight the variance between categories). Nevertheless, we still considered it a clever design approach and hope to see it implemented on the site again one day.

Two other areas that we put much thought into were the layout of the new articles on the front page and the transition/flow of the articles from issue to issue. We wanted to accommodate the different number of articles being published and at the same time create a dynamic layout that provides a fresh look to the front page in every issue, much like a print magazine. We proposed a template system that will allow the editors to easily choose the layout with the best fit each time they publish new articles (see Figure 9 and 10). I believe as the PublicSquare CMS continues to mature, a future plug-in can make this workflow even more automated.

Regarding the transition of articles on the front page, as you can see in Figure 6, we created a flow that will smoothly bring the articles from the new article spots at the top of the front page down to the “Previously” section whenever new articles are published. Eventually, the older articles will be moved out of the front page and will be found in the archived story section of the site. This helps to provide our readers a good sense of continuity each time when they visit the site and enables them to quickly locate the most recent issues.

Anther finer touch was the use of the font-embedding feature in Internet Explorer to apply a more attractive type (Helvetica Neue Medium 67) to the article titles and the issue header, while making sure it degrades gracefully with a similar core web font in other browsers with the help of CSS.

page layout creation process
Figure 9: Proposed process for creating different front page layouts for publication

article transition
Figure 10: Examples of different front page layouts based on the number of new articles

After several iterations of changes and refinement of this magazine site concept in collaboration with Liz Danzico and Christina Wodtke over a period of two months, we arrived at a polished design concept that was ready to be implemented (see Figure 11 & 12).

final front page design
Figure 11: Final front page redesign

final article page design
Figure 12: Final article page design

A bump in the road

While we were conceiving Boxes and Arrows’ new site design, “PublicSquare”:http://publicsquarehq.com/, a new content management system (which now drives the B&A site) created by Christina and Lars Pind was in the works. We soon shared the growing pains of PublicSquare as we were met with challenges in implementing our design into this developing CMS. After failing to launch the new design prior to the 2006 IA Summit, we went back to the drawing board and the implementation phase of the design was put on hold as Lars worked hard to integrate a new theme engine/templating language (“Liquid”:http://home.leetsoft.com/liquid) into PublicSquare. You can read more about this in “Christina’s article”:http://www.boxesandarrows.com/view/are_we_there_ye.

Towards the later half of 2006, the maturing PublicSquare was ready for us to begin the implementation phase again. It took another few months for us to port over our design into the Liquid theme language with the PublicSquare API. Because of some intricacies in the design, the amount of effort and time required for this phase far exceeded our expectation. It also happened to be the busiest time of the year for our day jobs so we had a bit of a difficult time juggling the work. Nevertheless, slowly but eventually, on the evening of January 15, 2007, we raised the curtain on the new Boxes and Arrows site. I can’t begin to describe the overwhelming sense of joy and relief that we had seeing our design live on the web.

The tortoise crosses the finish line

It has been a long ride. From the day that we received Erin Malone’s email to the day that our design finally launched was almost exactly two years. On this road of redesign, there were many IM chats and Skype calls made, numerous late nights and working weekends spent, and countless cups of tea and coffee consumed. It took awhile, but we got there. Working with these folks at the forefront of the IA community has been a great learning experience. The positive responses from industry leaders in the field of web design have also been a real reward to us.

We hope to continue to contribute to Boxes and Arrows as well as the community it serves. But for now, I am going to get some much-needed sleep, so good night!

See also: Are We There Yet for more tales of the redesign.

Doing Today’s Job with Yesterday’s Tools

Written by: Patrick Dubroy

The Problem

Okay, I’ll admit it. I’m hopelessly disorganized in my digital life. My inbox is overflowing with email. My documents are scattered across a half dozen hard drives, none of them backed up. When I recently needed an up-to-date resume, I had to write it from scratch, because I couldn’t find a copy anywhere.

Most people would say that it’s my own fault. It’s true; I should take greater care in organizing my data. But honestly, I’m just too lazy to spend the time to sort all my files into the proper folders. And I’d like to think that I have more important things to worry about than when I ran my last backup.

There’s an old adage in software development that says laziness is a virtue. By laziness, we mean only avoiding unpleasant work. For a programmer, the most tedious work to do is work that could be done by a program. Rather than spend an hour on a repetitive task, a programmer will spend 59 minutes writing a program to complete the task in 30 seconds. As Abraham Lincoln said, “give me six hours to chop down a tree and I will spend the first four sharpening the axe.” In the same spirit, I justify my laziness because I think software should do most of the work of information management for me.

itunes metadata
iTunes uses formal metadata fields
flickr tagsFlickr prefers freeform “tagging”

There are plenty of great information management tools out there. Certainly, iPhoto has made it easier to organize my digital photos. Flickr and Del.icio.us have popularized tagging—organizing items by simply marking them with keywords—and created a new way to navigate large amounts of data. And iTunes is a definite improvement over manually organizing MP3s into folders.

But as helpful as these applications are, they can be frustrating to use, because each one implements a slightly different set of features, even though they are basically solving the same information management problems. For example, iPhoto allows you to tag a photo with keywords, but iTunes doesn’t allow you to do the same thing for a song. Subtle incompatibilities like this can contribute to a frustrating user experience, because the interface doesn’t behave like you expect it to.

Even worse than slight incompatibilities between applications, is that they often support entirely different data models. In The Design of Everyday Things, Donald Norman explains that when we use a tool—like a drill, a car, or a computer application—we have a mental model in mind of how the tool works, and how it will react to our actions. This mental model guides how we use the tool. With so many different applications to manage our data, we have to keep track of several different data models, and it’s easy to get confused. For instance, when I’m browsing my photos, I might see a photo that I want to send to a friend. In both Picasa and iPhoto, I can click a button that allows me to email the photo to them. But I can’t do the same thing with a song in iTunes, or a bookmark in Firefox. What’s so different about each of those things? In my mental model, they are all just objects that I want to send to my friend. Unfortunately, this data lives in a balkanized world, and what we are allowed to do with the data depends on what form it is in.

This balkanization of our data also makes it more difficult to find things. Before being able to search for something, you have to know what form the data is in, so that you can search in the right application. Did I store it as a Del.icio.us bookmark? Did someone email it to me, or was it in an instant message? Applications like Google Desktop and Apple’s Spotlight help address this problem, but they support a limited number of data formats, and they aren’t able to search across multiple machines.

Another usability problem occurs when trying to share data between applications. A really simple example: my friend Ryan asks me to email him the photos from our last trip to Mt. Washington. I have no problem finding the photos in Picasa, because I’ve got an album called “Mt. Washington Trip 2006”. I can open the album and browse through thumbnails of the photos, looking for that great one that I took from the summit. But when I try to email it to Ryan from my Yahoo! Mail account, I have to browse through the file system to find the file. Even though I have the photo up in Picasa—Right there! That one!!—I can’t communicate that in an intuitive way to the web browser. Luckily, I know how to map from a photo in Picasa to the corresponding file on disk, but many people would not. Picasa provides a great abstraction: instead of thousands of files with unintelligable names like IMG_1792.jpg, it lets us work with the pictures, captions, and albums. But Picasa’s abstraction is like a dialect private to an isolated town: as soon as we leave, we are forced to use the computer equivalent of grunts and hand signals.

All of these problems are caused by the fact that by using many different specialized applications for personal information management, the data is segregated based its form. Using the term segregated isn’t an exaggeration—in some ways, the data is literally not allowed to mix together. For example, I’d like to gather a digital scrapbook of my trip to Europe. It would have emails that I sent and received during the trip, contact information for the people that I met, bookmarks for various places that I stayed, and of course, lots of digital photos. On most systems, this is difficult, if not impossible. It can be done in a crude way by copying some files into a folder and cutting and pasting into text files. But then I would lose all the features of the specialized applications, like captions on the photos.

In short, I believe that there are several usability problems caused by the fact that we use many different specialized applications for managing our data. We can become frustrated and confused by incompatible data models and inconsistent features. It’s harder to find the information we are looking for, because we have to remember what form the data is in. Communication between applications is awkward because they don’t speak the same language. The data is stuck in silos, segregated by its type. This prevents us from using perfectly natural ways of organizing our data.

Towards a Solution

Now that we’ve established what the problem is, the question is: what can we do to fix it? Obviously we can’t expect to have a single application which will support all of our needs. We still need specialized software like iPhoto for managing photos, and GMail for email. I think that the problem is not really with the applications themselves, but with the platform they’re built upon.

In software terms, a platform is a collection of common routines, and a set of interfaces allowing applications to use the routines. Normally, an application is built directly on the routines provided by the operating system. Developers and designers have long understood that an inconsistent user interface is difficult to use, so the UI is built into the platform, resulting in applications that mostly look and feel the same. In order to achieve the same kind of consistency with information management features, we need a platform designed for the manipulation of rich information.

While the amount of information that the average person deals with has increased dramatically in the last 20 years, file systems have hardly changed at all. All modern operating systems do in fact provide a common way to manage information: the file system. Unfortunately, while the amount of information that the average person deals with has increased dramatically in the last 20 years, file systems have hardly changed at all. We are still stuck with the old file and folder model. The problem with this model is that an increasing amount of data just doesn’t fit into it. For example, a single email usually does not correspond directly to a file on the local disk. Another example is bookmarks—many people collect and organize hundreds of bookmarks, but a bookmark is not a first-class object like a file.

In a broad sense, this new information management platform that I am proposing is really just a new kind of file system, based on the needs of today’s users. We need a system that will make it easier to manage and navigate the large amounts of rich and diverse information that people deal with every day.

In the first part of this article, I identified five distinct usability problems, all caused by the fact that we use many different specialized applications for managing our data:

1. Inconsistent features between applications
2. Incompatible data models
3. Difficult to find data, because we have to know where to look based on the type of the data
4. Awkward to share data between applications
5. Inability to mix different types of data together

In the same way the user interfaces are much more consistent because applications all use the same toolkits, then having a common information management framework that other applications can build upon will go a long way towards a more consistent set of interactions. I’d like to outline what I think are the key requirements for such a framework to be successful.

Requirement 0: Be a useful and usable framework

Only if it’s actually used can an information management framework help solve the problems I’ve identified here. The framework must be easy for application developers to build upon, and it must be useful enough to be worth their effort. By building on this framework, application developers would be able to focus on the core functionality of their applications, rather than wasting their time reinventing common information management features.

Requirement 1: Extensible for new kinds of data

By having applications build upon this framework, we eliminate the problem of having incompatible data models. But the platform must be extensible to be able to handle new types of data. The reason that we have to deal with the different data models of specialized applications is because the existing platform (the file system) was not suited for managing the rich data that today’s applications require. If the framework I’m proposing is not built from the ground up to be extensible, we will quickly find ourselves in the same situation we are now: trying to do today’s job with yesterday’s tools.

Requirement 2: Comprehensive search capability

The third problem I identified was that it’s difficult to find data, because you have to know where to look depending on what form the data is in. If it’s in an email, you have to search in one place, but if it’s in a file on your hard drive, you have to search in another place.

While search is not the answer to all our information management problems, it is a very useful feature. Now that Google is a verb, most people are comfortable using search as a primary way to find data. A new platform for information management should provide advanced search capability. Apple has done the right thing by building Spotlight’s sophisticated search functionality into the operating system, and allowing applications to build upon it.

But in order for search to be truly effective, we need to be able to search all of our data at once, instead of having to search in each of the individual silos. Having a single framework for managing rich information means that it will be able to search through all different kinds of data, no matter what form it takes.

Requirement 3: All data on equal footing

One of the problems I identified with current information management systems is that it’s difficult, if not impossible, for different types of data to be mixed together. You can’t create a folder that contains an email, a photo album, and some bookmarks. This problem is also related to the problem of inconsistent features and data models. Things that can be done with one type of data, like a file on the file system, can’t necessarily be done to other kinds of data.

In other words, there is an artificial distinction between different types of data. What a bookmark, an email, and a text file all have in common is that they are distinct, discrete pieces of information. If the purpose of the file system is to allow the user to store and organize information, then it should be able to treat these kinds of items equally. All types of data must be on equal footing. Anything that can be done with a file—like copying, searching, or sorting—should be possible with other pieces of information. If all data is on equal footing, then it would be possible to have a folder containing several different types of data.

Requirement 4: Flexible organization features

The folder (or directory) is the most common organizational metaphor used on computers. Originally, this concept was designed to be analogous to a physical file folder, so a document could only ever be in one folder. But it often makes sense for a document to be in two different folders at the same time. For example, if you had tickets to take a client out to a hockey game, should you put them in the “hockey” folder, or the “work” folder?

In information architecture, it’s good practice to support several paths to a piece of information. This is generally because we need to support many different users, who might have a different mental models. But even with a single user, there are sometimes several different mental models involved. Just today I went looking for my wallet, and couldn’t find it anywhere—although I’m sure I put it somewhere that made sense at the time.

The idea that an object could exist in multiple folders is known as multiple classification, and it has recently become popular in the form of tags. Flickr, Del.icio.us, and many other web services allow you to associate several keywords with your data. By doing so, you are indicating that the data falls into various categories, with the idea that this will help you or someone else more easily find the data later.

Providing support for multiple classification is just one example, but in general, for a new information management platform to be successful, it must be flexible enough to allow you to organize your data however you want.

Conclusion

In the first half of this article, I identified several usability problems with the current state of information management software. We use many different specialized applications for dealing with different kinds of information, and the applications have inconsistent features and incompatible data models. It is harder to find our data, because we need to know what form it is in, so that we can look in the right place. It’s awkward, and sometimes impossible, to share data between applications, and to mix the data together outside of the specialized applications.

To solve these problems, I proposed a platform that could be used to build the next generation of information management applications. Having a common platform for developers to build upon would give us greater consistency between applications—they would have the features we expect, and these features would work in the same way. Integration between applications would be much easier, as they would have a lingua franca for exchanging rich information. Different kinds of data could be mixed together, allowing users to easily organize their data in a way that makes sense to them.

I proposed five requirements for such an information management framework:

  1. Be a useful and usable framework. This should go without saying, but it’s important to keep in mind that this framework can only help solve our information management problems if it is useful, and it is attractive for developers to build upon
  2. Extensible for new kinds of data. If the system is not built to be extensible, we will soon find ourselves right where we are now: doing today’s job with yesterday’s tools.
  3. Comprehensive search capability. This one should speak for itself. With the overwhelming amounts of information that we have to deal with, advanced search capability is an indispensable feature.
  4. All data on equal footing. Several of the problems I identified stem from the fact that in current systems, certain types of data are not first-class.
  5. Flexible organizational features. You should be able to organize your data in whatever way works best for you.

I believe that these requirements provide a good starting point for an information framework that application developers could build upon, and ultimately give us an easier, more usable set of information management tools.

And then I would have no more excuses for being disorganized.