Impact of Technology on Information Architecture
The Rockley Group
This article points out the key areas where technology impacts information architecture for content management and provides guidelines to help you understand how your information architecture requirements should guide you in your technology decision.
Information architecture (IA) defines how your content management strategy will function from authoring through to content management and delivery. A content management strategy is typically supported by technology, such as authoring tools as well as a content management system. Yet, different tools have different capabilities, which will impact your information architecture. While your information architecture should form the basis for your tools selection, you also need to keep the tools' capabilities in mind when you develop your information architecture. Wherever possible you should partially complete your information architecture prior to selecting technology, using the development of the preliminary IA to answer the following questions:
- How semantic should your content models be
- What is your level of granularity
- What types of linking requirements do you have
- How do you plan to control reuse
- At what level should security permissions apply
Content modeling is a key component of information architecture. Content models indicate the structure of your information products (defined semantically), their granularity, and their reuse strategy. Content models are supported in authoring tools; authors are guided through creating content by authoring templates or forms that reflect the content models. The more semantic your content models are, and hence your authoring templates (refer to "Semantic vs Generic Elements" in The Rockley Report, Volume 1, Issue 2), the more effective the authoring templates will be. However, more semantic structures require more work to implement. If you are using an XML-based authoring tool, the technology does not provide any restrictions on how semantic the template can be, but because individual tags must be created for each uniquely named element, the person responsible for implementation may prefer a more generic authoring template. Likewise, if you are using a non-XML-based authoring tool, numerous semantic tags can be problematic.
Traditional authoring tools support semantic structure by listing all the semantic tags in a single drop-down list, which can quickly become unusable when there are too many tags to choose from. In both cases, you may have to compromise, deciding to identify only the larger elements semantically. Supporting semantic models is even more problematic if you are using authoring forms. Authoring forms are supported by XML or HTML and typically provide a field-based interface where authors "fill in the blanks" with content. Forms can be very useful if you don't want to provide a fully-functional editing tool to authors or if you have occasional authors creating content. However, supporting semantic structures can be very challenging for the following reasons:
- Control over optional vs mandatory fields
You often don't have any control over the display of optional vs mandatory elements; essentially all elements are displayed. You will need to provide an interface that clearly identifies required content.
- Repeatable elements
There is usually no facility that allows authors to select repeatable elements. For example, steps may be defined semantically by the name "Step". Some steps may apply to all products/processes, but others may be unique to a certain product/process, so you want be able to add metadata to identify where each step should be used. However, when authors enter a number of steps into one field, there is no way to add metadata to an individual step. Further complicating the matter is that authors typically don't know how many steps there will be before they start writing. Because authors don't know how many step fields they will need, it's impossible to provide the right number of step fields in the authoring form. In this case, you want authors to be able to add step fields as required. Some-although very few-tools for creating forms allow authors to request another field.
Granularity identifies the smallest piece of information that is reusable. For a further discussion of issues with granularity associated with implementation, refer to "Implementation: Issues with Granularity" in The Rockley Report, Volume 1, Issue 2. Granularity is a key component of your information architecture because it enables you to identify how small your elements should be to optimize reuse; however, different content management systems handle granularity differently. Only with a thorough knowledge of your granularity requirements and how you plan to implement reuse can you select an appropriate content management system or customize it to meet your requirements.
Another aspect of granularity is "bursting". Bursting is the process of breaking content into element parts so they can be stored individually in the content management system. When determining your level of granularity, you also determine which elements are stored individually, but not all tools have a built-in bursting mechanism. This forces authors to create the individual reusable elements first (e.g., individual steps) then assemble the individual elements into the complete piece of information (e.g., procedure). This is a counter-intuitive process and very frustrating for authors, who prefer to create content in context (e.g., an entire procedure rather than an individual step). To avoid this, make sure your content management system can support bursting.
Content frequently includes links such as hypertext links between sections of content in online materials or cross-references to content in paper. When content is reused, the destination for the link may no longer exist in the information set, or the location of the destination may change depending upon where the content is reused. Your system should:
- determine if a link exists and if it does not, then it should hide the link
- link content so location does not matter (e.g., link using element IDs)
You can control reuse in multiple ways:
- Opportunistic reuse
- Systematic reuse
- Nested reuse
Opportunistic reuse occurs when authors make a conscious decision to find an element, retrieve the element, and reuse it. Opportunistic reuse is the easiest reuse because it is not supported by technology; rather it is supported by author education and an effective searching mechanism that provides for full-text search as well as search based on metadata. In fact, opportunistic reuse relies very much on the metadata you define as part of your IA. If you are employing opportunistic reuse, it is important to know that the system will support both types of searches (full-text and metadata).
Systematic reuse is automatic reuse. This means that the content management system automatically populates authoring templates with reusable content. Systematic reuse relies heavily on your information architecture to define where content is reused (e.g., which element takes reusable content) and on metadata to correctly identify which content to reuse. Systematic reuse essentially personalizes content for authors instead of users and employs the same technology. If systematic reuse is part of your IA, then you must select tools that support that technology.
Nested reuse is content that has a number of reusable elements contained within a single element. The individual elements can be filtered out depending upon requirements. Nested reuse is a useful way to handle very granular content. If nested reuse is defined in your IA, your technology must support semantic models and metadata on granular elements (see the previous discussion of Semantic models in this article).
People don't tend to think about workflow when they think about controlling reuse. However, workflow can play a valuable role in controlling reuse. For example, Author1 creates an element which goes through the review and approval cycle (workflow). This element now becomes approved source. Now what happens when Author2 reuses the element, modifies it and has it reviewed and approved. Does the revised element become source? You decide based on your business rules. Your workflow helps you to control when an element is considered source based on your corporate processes. Make sure your technology can use workflow to control content at the element level, not just the information product level.
Security is applied to content to ensure only the appropriate people can view, edit, delete, or reuse content. You define security as part of your information architecture, determining if an element carries its own security or if it is derived from the information product where it resides/is reused. Security at multiple levels is ideal and you should have business rules that determine how security is applied, depending upon how and where an element of content is used. Ensure your content management system supports security at both the element level and the information product level.
Technology impacts your information architecture and information architecture impacts your technology selection. Create a preliminary version of your information architecture to guide you in your tool selection, but don't finish the information architecture until you have selected your tools and can fine tune your architectural decisions. If the tools are selected first (I highly recommend that you don't do this) make sure you know the functionality of the system as you begin your information architecture and customize the technology if necessary.