No Section...

VIII.5 Sept./Oct. 2001
Page: 19
Digital Citation


K. Ehrlich, A. Henderson

back to top 

In order to provide value to these end users, designers of Web pages are changing their approach from designing static Web pages with content that seldom changes to designing templates into which new information can be frequently added. It is not enough to design templates that structure navigation and visual identity. Truly dynamic presentation of information will take a modular approach, and templates will need to include a rule structure that specifies how content and interactions are combined. As content management and other systems enable and demand such modular approaches, the role of the information architect becomes more challenging.

This article will provide a brief overview of some of the design imperatives and implications of using templates to create a modular Web design. It will review the contribution of content management systems and the means by which template rules can be used to create customized, personalized experiences.

The emergence of templates and modular design has clear implications for Web interface designers: Site maps and interactive wireframes are not sufficient to capture the essential features of an interaction experience. Instead, designers will need to adopt a rule-based approach and become comfortable with creating placeholders for content and interactions.

back to top  Content Management Systems: Pointing the Way to Modular Design

Content management systems allow businesses to create, manage, and publish content to the Internet (or other electronic venues). The power of such systems lies in the fact that people outside an information technology (IT) department can perform daily workflow tasks to publish content into templates that maintain the corporation's brand integrity and remove formatting and design burdens from content creators.

Content management systems can be understood as modular because they separate the content from display through the use of templates. Authoring templates allow content providers to create and edit content without concern for presentation. Conversely, presentation templates match the content with design for publication. This separation allows businesses to easily make changes to the presentation templates, changes that are then made with no effect on the content.

Such systems also allow for the content that is entered to be systematically tagged: keywords for any module of content can be assigned from a data dictionary of terms. Successful systems enforce tagging within the workflow process to provide greater and more consistent searching, personalization, and syndication. The content is sorted, indexed, and stored according to the tagging schema, allowing more consistent retrieval for end users. Synonyms are defined and stored to provide search matches based on word meaning rather than syntax.

Content management systems illustrate the shift presented by modular design. Information architects will cease creating hierarchical structures with rigid navigation and interaction paths, and will increasingly be involved in creating the rules of how content and interactions behave based on different scenarios. The role that template design plays in the operation of content management is evidence of how fundamental the concept of creating templates itself will be to this emergent direction in design.

back to top  A Closer Look at Templates

The use of templates has increasingly approached an industry standard, as more and more organizations have come to see the advantage of creating standards for presentation independent of content. Templates differ from Web pages in that they describe the structure of elements that may appear on a page rather than the actual page content. Templates consist of a combination of elements that structure the harmony of the content, design, and functionality. A description of commonly found elements follows.

  • Navigation outlines what types of navigation systems are displayed. Typical examples are primary, secondary, tertiary, global navigation, and breadcrumbs.
  • Headers are content titles provide orientation. Sometimes headers and breadcrumbs are combined.
  • Content is the actual text and images that are displayed in a template. The template does not actually contain the content; it holds the quantity, location, and formatting of the anticipated content. Content can be static, meaning the text or images remain the same from page load to page load, or it can be dynamic, meaning it is frequently or automatically updated.
  • Interactions are forms or tools to perform specific tasks. Often interactions are process-driven and may have several steps to complete, as well as have dependencies: input in each step will affect further steps and interactions.
  • Pods are areas on the page, defined by the template, that are typically contextually related information (see Figures 1 and 2). Pods provide another method of guiding users to content or interactions rather than through the hierarchical navigation scheme.
    • Link pods contain a list of links.
    • Content pods allow quick summaries of content to be highlighted, with a link to the full content area.
    • Form pods provide quick polls or forms for feedback, searching, or quick access tools.

The next section will discuss how the rules that govern these elements work.

back to top  The Rules Behind Templates: A New Focus for the Information Architect

As modular design develops, information architects will soon focus more on how the elements of a template interact and are linked, rather than on developing linear or branching interactions under a rigid hierarchy. The hierarchical conception of the Web site will be replaced by a dynamic structure┬Śmore of an umbrella under which a variety of changing interactions occur. The structure will be defined by rules that leverage the dynamic possibilities of XML-based content management, creating an environment in which context drives the affiliation of each piece of content with related links and information.

Rules are essentially logical, describing and defining dynamic relationships between various site elements. Rules may be defined textually, through visual diagrams, or, ideally, incorporated into wireframes. In a modular architecture, the rules define how modules are pulled together to form a page. Here are a few examples of how rules work with template elements:

  • Content and Link Pods rule
    A rule based on the tagging of any particular content element (such as a word, phrase, or image) may specify that the system will search for links to related content and create a contextual link pod. For example, if the content is a story about villas for rent in Italy, it could be tagged with these attributes: Italy, vacation, rental, villa, and countryside. The link pod would be dynamically created showing related links like "The magic of Orvieto," "Wine country at its best," or "Hidden castles of Italy." The rule creates a contextual relationship between the content and related information (see Figure 3), but does not define a hard-coded relationship with the content. For example, this same rule would work for a content story about a slowdown in hardware sales, with the link pod showing links such as "PCs are a commodity" and "Consumers say computers are fast enough."
  • Navigation/Breadcrumb/Header rule
    Another rule may specify that there is primary, secondary, and tertiary navigation and that the breadcrumb is dynamically built using the content titles of the navigation. The header then displays a longer version of the same title.
    Although this navigation rule is commonly applied today, it is interesting to highlight because in the future we will see movement away from rigid determination of the navigational elements.

The power of rules comes with the fact that they don't necessarily tie to the specific content of the template elements. This is illustrated by the Content and Link Pods rule. Rules support modularity because information architects are focused on defining the relationship between the elements to provide contextual experiences.

Some rules will most likely become standard combinations that information architects have in their toolkit of options. The two previously mentioned rule examples fall into that category. Information architects will need to create more specific template elements and then create more customized rules. For example, the content element is an extremely broad category. Content could be divided into several different element types such as bullet point lists and images with captions. Rules would then govern how these content types are put together in the template: their relations would not be hard coded.

An interesting challenge for information architects will be determining how a series of rules works together to provide experiences. The rules defined for an interaction could become layered and overlap. Determining how the rules work together and creating the resulting experience will be complex. In some cases, metarules may need to be created to determine how rules combine cohesively.

Rules for rules' sake will not be successful. Information architects will need to work with users, business leaders, and content owners to determine what type of experience architecture will map to the objectives of the interactive initiative.

back to top  How Rules Map to Customization and Personalization

Rules have a direct relationship to both customization and personalization and will ultimately affect how those are accomplished.

Customization has typically meant the ability of users to set the content they are interested in receiving or seeing; the user's experience is driven by his manipulation of preferences or settings. Typically, customization is handled by having users log in and go to a user profile to set up preferences.

Rules allow customization to assume a different structure. With rules, customization will become more integrated and seamless and need not take place in a separate functional area. Users will be able to set customization within the context of viewing content they are interested in. A good example of integrated customization can be seen on the International Herald Tribune Web site ( Without registering or moving to a "customization" screen, with a single click a user can quickly change the number of columns of text or the size of text in the browser. This dynamic flexibility significantly improves the experience of the reader and points the way toward more on-the-fly customization.

Whereas user specification of preferences typically drives customization, personalization occurs when the system estimates, according to the user's history of interactions, what the user wants to view or not view.

The most common personalization technique today is collaborative filtering. Collaborative filtering means that the system sees what content the user is viewing and then presents similar content based on what other users typically access. Each user's data are constantly added into the system to refine and change the content served. Amazon's Recommendations feature is a prime and early example of collaborative filtering.

With rules, personalization can be structured into experiences at the template level. The Content and Links Pod rule illustrates how personalization can happen according to what the user is viewing and subsequently pulling in discovered and related content.

One method underexplored in personalization is actually changing the navigation structure from the content and interactions accessed by the user. Typically sites are defined with rigid structures that do not dynamically change: context-based navigation would radically challenge this conception of site structure. For example, the previously mentioned Navigation/Breadcrumb/Header rule could be combined with a rule that dynamically specifies the navigational content, basing it on available contextual content.

back to top  Beyond Content, Interactions and Transactions Will Also Play in this Modular World

Custom interaction development will still exist for tools or applications that support a specific business process. Such interaction design work is moving away from a single linear transaction process and so tends to be quite complex to design.

One variation of modular transactions addresses how and when different users contribute to a shared process. For example, across a process A>B>C>D, user 1 may follow steps A and C, and user 2 may follow steps B and D. In these cases, the information architect essentially designs several views of the same content and transaction space and provides specific tools to the different users by role and responsibility in the process. Essentially, such projects address asynchronous collaboration and status tracking. Complexity arises in determining how changes in one step of the process by one user will affect the design of other processes.

Another variation addresses how a process may need to vary across different companies that approach the same business process slightly differently. For example, company 1 may follow the process A>B>C, and company 2 may follow A>D>C. In this situation, it is critical to have primary research feed the design process to help identify the similarities and differences of the processes. The modularity of such applications will be applied to the design of an administrative side of the system, which will then have interfaces that allow configuration of workflow by user access groups.

So, even though the information architect will create highly customized business applications, a level of extraction and modularity will still exist to ensure that the system is designed with enough "smarts" to be highly flexible.

back to top  What Will Control Experiences?

A recent newsgroup thread for information architects discussed whether the information architect's role was "to control the user experience." The person posting the thread didn't think that this was a valid formulation of the information architect's role, and a heated exchange ensued. The desire to control experiences conflicts with the need to provide a multitude of paths for users to accomplish their goals.

Given this, the information architect's role will need to shift toward creating extendable experience structures that allow users to find and interact with a variety of content. This means that information architects will influence rather than control experience.

As we shift toward content management systems and real-time publishing by a variety of people within organizations, we will find no single user experience. Content management systems will increasingly provide methods to implement customization and personalization. Because in this kind of system new content can be added at any time to the content hierarchy, the user experience is essentially never locked or the same twice.

This fluidity creates another challenge for designers: it will become increasingly difficult to test and ensure consistent user experiences. Because the actual content as well as the amount of it is not known in advance, what will appear at any point in time is unpredictable. Usability testing on such systems will need to occur at the goal level rather than the task level, because the steps and content displayed at a task level will continually morph.

back to top  Thoughts for Designers of Interactive Experiences

The advent of a modular approach to content and interactions ultimately means that information architects (and other team members playing the role of designing interactive experiences) must begin to rethink their role in Internet and application development efforts.

  • Information architects should play a significant role in implementing content management systems. The importance of creating an appropriate content hierarchy, data dictionary, and associated synonyms should not be underestimated. Indeed, creating a good information design will come to be seen as a critical step in the successful implementation of these systems.
  • Information architects will need to determine the number of templates, as well as the template elements, early on in design. It will be important to make sure that the structures created map to and support the objectives of the business and the user.
  • Information architects will need to adopt template rules and develop new tools and deliverables to communicate how the rules interact in different scenarios. Site maps and interactive wireframes will no longer be enough. Interactive wireframes typically show a scenario through a system. They will need to be extended to show how interaction rules affect the user experience.
  • Information architects will need to adopt a modular framework in order to create the next generation of customization and personalization. Personalization will need to be informed by several sources of information┬Śpast access as well as primary user research will be leveraged to create appropriate and relevant rules.
  • Information architects will need to design complex business processes. Such processes are typically a matrix across several users in a shared process or address variations of a process across several user groups.

back to top  Author

Julie Pokorny
User Experience Principal
Lante Corporation
600 West Fulton, Ste. 400
Chicago, IL 60661
(312) 696-5298

Design Column Editors

Kate Ehrlich
89 South St, 2nd Floor
Boston MA 02111
(617) 531-3700

Austin Henderson
Rivendel Consulting & Design, Inc.
P.O. Box 334
8115 La Honda Rd. (for courier services)
La Honda, CA 94020 USA
fax: +1-650-747-0467

back to top  Figures

F1Figure 1. A page constructed from modules.

F2Figure 2. A template view of the page showing pods.

F3Figure 3. Contextual relationships between pods.

back to top 

©2001 ACM  1072-5220/01/0900  $5.00

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

The Digital Library is published by the Association for Computing Machinery. Copyright © 2001 ACM, Inc.

Post Comment

No Comments Found