The Encyclopedic Revolution

Written by: Alex Wright
This excerpt adapted from Chapter 9, “The Encyclopedic Revolution.”

Despite the proliferation of books in the years after Gutenberg, three hundred years later books still remained prohibitively expensive for most Europeans. By the mid-eighteenth century, a typical educated household might own at most a single book (often a popular devotional text like the Book of Hours). Only scholars, clergymen and wealthy merchants could afford to own more than a few volumes. There was no such thing as a public library. Still, writers were producing new books in ever-growing numbers, and readers found it increasingly challenging – and often financially implausible – to stay abreast of new scholarship.

At the dawn of the Age of Enlightenment, a handful of philosophers, inspired by Francis Bacon’s quest for a unifying framework of human knowledge[1], started to envision a new kind of book that would synthesize the world’s (or at least Europe’s) intellectual output into a single, accessible work: the encyclopedia. Although encyclopedias had been around in one form or another since antiquity (originating independently in both ancient Greece and China), it was only in the eighteenth century that the general-purpose encyclopedia began to assume its modern form. In 1728, Ephraim Chambers published his Cyclopedia, a compendium of information about the arts and sciences that gained an enthusiastic following among the English literati. The book eventually caught the eye of a Parisian bookseller named André Le Breton, who decided to underwrite a French translation.

Diderot

Enter Denis Diderot. A prominent but financially struggling writer and philosopher, Diderot occasionally supplemented his income by translating English works into French. When Breton approached him about the Cyclopedia, he readily accepted the commission. Soon after embarking on the translation, however, he found himself entranced by the project. He soon persuaded Breton to support him in creating more than a simple translation. He wanted to turn the work into something bigger. Much bigger. He wanted to create a “universal” encyclopedia.

Adopting Bacon’s classification as his intellectual foundation, Diderot began the monumental undertaking that would eventually become the Encyclopédie ou Dictionnaire Raisonné des Sciences, des Arts et des Métiers (“Encyclopedia or Dictionary of the Sciences, the Arts, and the Professions”), published in a succession of volumes from 1751 to 1772. A massive collection of 72,000 articles written by 160 eminent contributors (including notables like Voltaire, Rousseau, and Buffon), Diderot turned the encyclopedia into a compendium of knowledge vaster than anything that had ever been published before.

Diderot did more than just survey the universe of printed books. He took the unprecedented step of expanding the work to include “folk” knowledge gathered from (mostly illiterate) tradespeople. The encyclopedia devoted an enormous portion of its pages to operational knowledge about everyday topics like cloth dying, metalwork, and glassware, with entries accompanied by detailed illustrations explaining the intricacies of the trades. Traditionally, this kind of knowledge had passed through word of mouth from master to apprentice among the well-established trade guilds. Since most of the practitioners remained illiterate, almost none of what they knew had ever been written down – and even if it had, it would have held little interest for the powdered-wig habitués of Parisian literary salons. Diderot’s encyclopedia elevated this kind of craft knowledge, giving it equal billing with the traditional domains of literate scholarship.

Figurative System of Human Knowledge

While publishing this kind of “how-to” information may strike most of us today as an unremarkable act, in eighteenth-century France the decision marked a blunt political statement. By granting craft knowledge a status equivalent to the aristocratic concerns of statecraft, scholarship, and religion – Diderot effectively challenged the legitimacy of the aristocracy. It was an epistemological coup d’ étate.

Diderot’s editorial populism also found expression in passages like this one: “The good of the people must be the great purpose of government. By the laws of nature and of reason, the governors are invested with power to that end. And the greatest good of the people is liberty.” To the royal and papal authorities of eighteenth century France, these were not particularly welcome sentiments. Pope Clement XIII castigated Diderot and his work (in part because Diderot had chosen to classify religion as a branch of philosophy). King George III of England and Louis XV of France also condemned it. His publisher was briefly jailed. In 1759 the French government ordered Diderot to cease publication, seizing 6,000 volumes, which they deposited (appropriately enough) inside the Bastille. But it was too late.

By the time the authorities came after Diderot’s work, the encyclopedia had already found an enthusiastic audience. By 1757 it had attracted 4000 dedicated subscribers (no small feat in pre-industrial France). Despite the official ban, Diderot and his colleagues continued to write and publish the encyclopedia in secret, and the book began to circulate widely among an increasingly restive French populace.

volume

Diderot died 10 years before the revolution of 1789, but his credentials as an Enlightenment encyclopedist would serve his family well in the bloody aftermath. When his son-in-law was imprisoned during the revolution and branded an aristocrat, Diderot’s daughter pleaded with the revolutionary committee, citing her father’s populist literary pedigree. On learning of the prisoner’s connection to the great encyclopedist, the committee immediately set him free.

What can we learn from Diderot’s legacy today? His encyclopedia provides an object lesson in the power of new forms of information technology to disrupt established institutional hierarchies. In synthesizing information that had previously been dispersed in local oral traditions and trade networks, Diderot created a radically new model for gathering and distributing information that challenged old aristocratic assumptions about the boundaries of scholarship – and in so doing, helped pave the way for a revolution.

Today, we are witnessing the reemergence of the encyclopedia as a force for radical epistemology. In recent years, Wikipedia’s swift rise to cultural prominence seems to echo Diderot’s centuries-old encyclopedic revolution. With more than three million entries in more than 100 languages, Wikipedia already ranks as by far the largest (and most popular) encyclopedia ever created. And once again, questions of authority and control are swirling. Critics argue that Wikipedia’s lack of quality controls leaves it vulnerable to bias and manipulation, while its defenders insist that openness and transparency ensure fairness and ultimately will allow the system to regulate itself. Just as in Diderot’s time, a deeper tension seems to be emerging between the forces of top-down authority (manifesting as journalists, publishers and academic scholars) and the bottom-up, quasi-anarchist ethos of the Web. And while no one has yet tried to lock Wikipedia up in the Bastille, literary worthies and assorted op-ed writers have condemned the work in sometimes vicious terms, while the prophets of techno-populism celebrate its arrival with an enthusiasm often bordering on zealotry. Once again, the encyclopedia may prove the most revolutionary “book” of all.

About the Book

“Glut: Mastering Information Through the Ages”:http://www.amazon.com/Glut-Mastering-Information-Through-Ages/dp/0309102383/boxesandarrows-20
Alex Wright
2007; Joseph Henry Press
ISBN-10: 0309102383

References

fn1. cf. Bacon’s Novum Organum of 1620

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.