The deployment specification, which I describe in this section, you actually want to develop along with the other specifications during implementation. It details the process that you undertake to roll out your system. The deployment specification includes the following parts:

• The power-up schedule: This schedule details the plan that you devise for powering up the system. Especially during the earlier stages of development, it's critical so that each team knows your expectations for when you need its deliverables to continue building out the production system.
• The CMS system architecture: This architecture includes all the parts that I mention in the section " The production installation," earlier in this chapter The system architecture should include system diagrams as well as hardware and software requirements for the generic and production installations.
• Integration plans: These plans include schedules and techniques to use to connect the CMS to all third-party products and enterprise systems.
• Staff rollout plans: These plans detail how and when you deploy the collection system to different contribution groups (author groups and acquisition groups).
• Publication rollout plans: These plans describe the order and timing in which CMS-produced publications replace the current publications. This plan shows exactly when the old ones stop and the new ones begin. If you're planning a period during which the old and new publication productions overlap, the plan needs to show how you're handling staffing and synchronization.
• The beta plan: This plan describes the timing and participation that you expect in a beta release. If you're including certain audience groups, the plan needs to state how you plan to ask for or notify them of their participation.
• Expected and allowed volumes: The deployment plan needs to set the expected range and the maximum values for the page views and other transactions that occur in the CMS at release. It should include contingency plans for how to bring more hardware or bandwidth to bear if the actual volumes (of page requests, database queries, or other publication pages, for example) exceed the maximum.
• The distributed system plan: If the CMS system or databases is spread over various locations, the specification should provide a schedule and staffing plan for how the deployment spreads through the set of locations.
• A deployment staffing plan: This plan shows how many and what types of people you need to power up and roll out the system.
• Setup and configuration data: You need this data for all the end-user tools that you must deploy to contributors and other CMS staff.

The deployment specification dovetails with the implementation specs. Whereas each implementation specification shows how to build a particular part of the CMS, the deployment specification shows how all the parts come together as you build them to form the production system and how you intend to progressively release that production system to staff and audiences.

***

Excerpted from Chapter 18, "Rolling Out the System," in the section titled "The deployment specification."

If you own the CM Bible, click here to go to this section in the Web version of the book.

For each acquisition source, ask yourself the following questions to help you understand and design for the constraints that the source owner puts on your process:

• Owner: Who owns or is responsible for this source of content? If it has multiple owners, do they all subscribe to the same rules or procedures? If not, consider creating multiple sources. To consider sources the same, multiple owners need to behave similarly.
• Influence: What influence do you have over the timing, structure, or format of this source?
• Agreement: Can you form a binding agreement with the owner? If so, what form does it take - a formal contract, a memo, an e-mail message? In any case, seek to form the contract in writing so that you're sure that even an informally arranged agreement is specific. If forming a binding agreement isn't possible, how do you ensure that the content is delivered consistently enough to enable you to adequately plan for it?
• Source units: In what sorts of units does this source arrive (for example, individual files, database tables, or CD-ROMs full of content)? How many and what types of components are in each unit. PLAN, for example, may receive a file each week containing news stories from an international distributor. Each file may contain between 50 and 100 stories that give rise to three or four press-release components (stories that PLAN wants to modify and redistribute) and 30 to 40 news components.
• Delivery: In what format or formats does the source arrive? How does it arrive (via direct connection, FTP, and so on)?
• Escalation: Who do you contact if the content doesn't arrive in the way that you expect? To whom do you escalate the issue if it isn't quickly resolved?
• Start-up quantity: How much of this source do you need to process before the CMS launches? When does it need to arrive for you to make it ready for launch?
• Run quantity: How much of this source do you expect to receive on an ongoing basis? How far in advance of a publish date do you need it delivered?
• Changes: How can you make sure that the content that you receive is the latest or master version of the source? What provision can you make for parts that arrive late or change after they're officially passed off to you?
• Feedback: What provisions can you make for feeding back information from the CMS team to the content owners for improving the delivery process?

***

Excerpted from Chapter 25, "Accounting for Acquisition Sources," in the section titled "Source Relationship."

If you own the CM Bible, click here to go to this section in the Web version of the book.

The steering committee is the ongoing remnant of the mandate and requirements processes. They are the people in the organization that have a continuing interest in the system and enough authority, expertise, or both, to determine the direction of the CMS. The steering committee can have representatives from the CMS project sponsors, members of significant contribution and publication groups, and CMS analysts and other project team members with continuing knowledge and responsibility for the system. The steering committee can do the following:

• Set CMS standards, including content modeling trade-offs, when to make a custom collection or publishing process into a standard process, and when and how to extend current standards to include new groups.
• Work with new teams to determine whether they should become part of the CMS initiative, and, if so, when and how to integrate them into the current process.
• Resolve content-sharing conflicts between groups with competing needs.
• Serve as the ultimate supervisors of the CMS and repository teams.

***

Excerpted from Chapter 12, "Working Within the Organization," in the section titled "The CMS steering committee."

If you own the CM Bible, click here to go to this section in the Web version of the book.

The community's host is the organization that's in charge of the site's infrastructure and maintenance. This organization must implement a CMS, communication services, and member-administration services. It must also input enough content to get the site off the ground. You find the following two typical types of hosts online:

• Commercial hosts: A commercial host has the members as a target market for goods or services. This host is willing to trade the cost of maintaining the site in return for exposure to the members. In a typical scenario, the host has the original idea for the community, creates an initial implementation of the site's system, fills the system with enough content to make it viable, and then launches the site and opens it to members. The host continues to feed content in, administer user data, and create communication events. The major issue to resolve in this circumstance is what right the host has to market to the members or sell member data to outsiders. Members can leave if they feel exploited. On the other hand, the host may stop if it sees a lot of cost and little return from the community.
• Member hosts: A member host is one or more potential members who decide to create a Web presence. Typically, some existing trade or interest organization with a current membership organizes and funds the initial system. As in the case of the commercial host, the member host creates an initial implementation of the site's system, fills the system with enough content to make it viable, and then launches the site and opens it to members. The key issues here are: continued funding of the site from often cash-strapped organizations, and sufficient attention paid to the site maintenance by what is often volunteer-run organizations. Of course, selling member data is also an issue for member-hosted communities.

For both the commercial host and the member host, the primary issue is to make the site truly belong to the members. As time goes on, members should become the major contributors to the site, with the host needing to supply less and less content. In a high-affiliation community, members even plan and execute the communication events (chats, online meetings, and so on). If the community is successful, then its success comes from the host's creation of a system that promotes affiliation and targeted knowledge-gathering - among a group of people who naturally gravitate to a clearly stated and well-founded common interest.

In any case, for the community to become successful, it must have a full-featured and robust CMS behind it. Without a CMS, the site can serve neither its members nor its host. At best, it becomes an enhanced bulletin board, and at worst, it becomes an unenhanced bulletin board.

***

Excerpted from Chapter 10, "The Branches of Content Management," in the section titled "The host."

If you own the CM Bible, click here to go to this section in the Web version of the book.

Writers, public speakers, and other communication professionals, have used the concept of an audience analysis for a long time. A lot is written on this subject, appearing in textbooks and the popular press. Most of the work that I've seen boils down to the following seemingly simple points:

• Who are these people objectively? What are their ages, interests, jobs, and other relevant data?
• What does this audience already know and believe about this subject?
• What are people's needs and desires for new information in your subject area?
• What kind of presentation style are they likely to respond to favorably?
• What publications do they already trust, and to which are they likely to compare yours?
• What's the author's relationship to this audience? Is she a peer, an expert, or an outsider?
• How do you establish credibility with this audience? What do audience members consider good information sources, arguments, and examples?
• What tasks and purposes have they in mind as they approach your material?

This sort of analysis has motivated communicators from the ancient Greek rhetoricians to the modern technical writer and journalist. I believe that it's a pretty good list of the sorts of information that you need so that you can understand how to communicate with an audience. Most of the time, you conduct this analysis quite informally, and it results in an intuitive feel that the communicator gets for how to approach an audience. For a CMS audience analysis, you need to make the answers to these questions explicit and relate them to the parts of the CMS that they're going to help structure.

***

Excerpted from Chapter 21, "Cataloging Audiences," in the section titled "Audiences and communicators."

If you own the CM Bible, click here to go to this section in the Web version of the book.

In the software world, a computer-based process is known as functionality. The functionality that a computer application offers casts a human process into a series of human-computer interactions using a user interface. From the standpoint of the organization, you can say that functionality is the way that you do business by using a computer.

Simply put, functionality is the stuff that you do on the computer. Unlike text, sound, pictures, and motion, which you experience (by reading, hearing, or seeing), you do functionality (by requesting or responding to something). A user interface represents functionality as a set of buttons, menus, dialog boxes, and other controls that give you a particular capability. Microsoft Word, for example, provides table functionality. The functionality is available from the Table menu at the top of the Word window. If you choose the Table › Insert Table command, Word displays a dialog box full of buttons and other controls that enable you to specify how you want the Insert Table functionality to perform. On the Web, functionality is programming code that lives in a Web page or on a Web server. It does useful things such as performing calculations, allowing you to submit data via a form, carrying out financial transactions, verifying your credit card information, and so on.

Functionality's taken the following two major steps over the course of computing:

• It's moved away from monolithic programs, where all the functionality is built-in, toward mix-and-match programs, where the functionality exists in small chunks known as objects.
• It's moved away from applications with the single purpose of presenting functionality toward Web sites in which functionality and content intermingle and become hard to tell apart.

Taken together, these two steps enable you to treat functionality as a form of content.

***

Excerpted from Chapter 4, "Functionality Is Content, Too!," in the section titled "What Is Functionality?."

If you own the CM Bible, click here to go to this section in the Web version of the book.

Even if you will have only a couple of audiences, for starters, and a static Web site as your only publication, it is worth your while to study and document an approach to personalization. This approach can include the following deliverables:

• A messaging strategy: This document combines audiences, publications, and components together at a high level. It defines what each audience is supposed to get from each publication and which components and publication design features will be used to communicate with them. It is a high-level precursor to personalization analysis. Particularly for publications targeting external audiences, it provides a marketing context within which to do personalization. For internal publications, your messaging strategy clearly identifies which types of information are appropriate for each audience.
• A personalization strategy: This document goes into detail about exactly how you intend to do personalization in each publication. It specifies a personalization rule for each combination of publication, page, audience, and component. The core of this document is the set of personalization rules. The rules state how to fetch components from the CMS repository, based on what you know about the user, plus the values of the component's management elements. The rules also say which elements to display and how to lay out the components on the publication page.

***

Excerpted from Chapter 15, "Doing Requirements and Logical Design," in the section titled "Personalization strategy."

If you own the CM Bible, click here to go to this section in the Web version of the book.

Like the other analysts I have described, the software analyst strategizes and plans. The software analyst plans how best to accomplish all of the programming that must be accomplished to start and run the CMS.

In particular, the software analyst is responsible for the following:

• Choosing the development environment (or environments) that will be used. There are quite a few competing environments from which to choose. The right one is the one (or ones) that requires the least retraining of the programmers you intend to use, fits most cleanly into the required system architecture supplied by the deployment analyst, and, of course, provides the tools you need to create the needed functionality.
• Creating a development framework. In a CMS, there is code everywhere. From the programming macros in a Microsoft Word document template, to the stored procedures in an enterprise resource planning (ERP) database, there are more programming sites than anyone in her right mind would call a single system. It is the job of the software analyst to get all of these different parts of the system corralled into a single programming framework. The framework organizes the creation of code, its versioning and testing, its deployment, and the sharing of code modules and objects between applications. This is no small task in an enterprise CMS.
• Deciding which features of the CMS should be custom-coded and which should be done using commercially available tools. For example, should the organization use the database connectivity code supplied by the CMS manufacturer or should they extend the code they have now, which works well with their ERP system?
• Writing the specifications and development plans for the programming tasks that require them.
• Creating estimates and plans for the staffing needed to accomplish all of the programming to start and run the CMS.

As with the deployment analyst, there are people in the world who have done this sort of thing before. Still, someone who is a good general analyst but also has significant experience programming content-manipulation applications would serve you best. This is not a rare skill set, but it is not the most common. People of this ilk can be found in the back rooms of Web sites that use Perl extensively, or in the documentation groups of large companies that have had to use Structured Generalized Markup Language (SGML) to structure and manipulate massive document databases. In any case, stay away from the people who think that content can be treated just like data. They will underestimate the complexity of their task every time.

In addition, like the other analysts, this person cannot be a back-roomer. She must be able to negotiate among the competing development interests (which are no less, and often more, vehement than the business interests) and come to a workable compromise between competing platforms.

Finally, be careful not to choose someone who is more interested in writing code than getting other programmers organized. Note that the software analyst's job description does not say "writes a lot of programs." Even if you are in a position to have only one person who is both analyst and developer, because there are so many different places where code will live, it is essential that this person really be interested in staying organized, creating standards, and adhering to them, rather than simply writing code.

***

Excerpted from Chapter 11, "Staffing a CMS," in the section titled "Software analyst."

If you own the CM Bible, click here to go to this section in the Web version of the book.

Someone must set up and run the CMS. I call that person the CMS administrator.

The administrator is responsible for all of the end-user tasks required to set up and run the system. Like all administrators, the CMS administrator is neither a programmer nor a network professional (although experience in these areas helps). Rather, CMS administrators are responsible for tasks such as the following:

• Configuring the chosen CMS. The administrator enters or imports all of the component definitions, user profiles, publication definitions, and other data that the CMS needs to begin working.
• Inputting content. Where content comes into the system in bulk (for example, as the result of a conversion process), the administrator oversees the process and takes action when anything fails. Where content comes in one component at a time (for example, when authors fill in Web forms), she is responsible for ensuring that the proper methods are up and working. This may entail creating new Web input forms, distributing appropriate end-user software, or simply receiving e-mail attachments and importing them into the system.
• Fully understanding the chosen CMS software. The administrator ought to be able to make the CMS do anything it can do without additional programming. In many commercial systems, there is quite a bit that does not require programming. Much of what a CMS is capable of, however, requires you to understand content management concepts and to be able to find the right combination of options (which are often buried in text files and the system registry).
• Maintaining users and workflows. The administrator is responsible for ensuring that all staff that have access to the system are accounted for by the system. Staff may need to be profiled and added to groups in order to get access to the resources they need. In addition, the administrator needs to set up and maintain the system workflows. This may be as simple as dragging and dropping icons onto a page, or as complex as modifying a massive XML structure in a text editor.
• Triaging bugs and finding fixes. After the system is running, the administrator will be the first line of defense against problems that arise. From rebooting after a crash to spending days tracking down why one user can't seem to log in, the administrator must ensure that the train keeps running. Of course, many problems will need to be escalated past the administrator, but like the triage nurse in an emergency department, she sees them all first.
• Ensuring data hygiene. The administrator ensures that the content stored in the repository is in the best state possible. This responsibility includes making sure that required data is supplied, that content is archived or deleted on the specified schedule, and that periodic reviews and updates to content and system configurations happen as scheduled.

***

Excerpted from Chapter 11, "Staffing a CMS," in the section titled "CMS administrator."

If you own the CM Bible, click here to go to this section in the Web version of the book.

In society, communities are groups of people that share some common purpose or kinship ties. The situation is no different online. Although many people talk about creating online communities, few do so from this sort of understanding. The most popular concept of community I have heard is to become "the place" to go for some sort of information. If you add a chat room or a threaded discussion, and collect user data, it is called a community. Many community sites hope to "own" the attention of their users and sell it to advertisers or direct it toward other organizational goals.

Without real community, however, which offers a core of common purpose or kinship (in the widest sense of sharing some important aspect of life), these sites can never really be communities. To be a real community, an online community needs to fulfill its members' needs for affiliation and knowledge. Affiliation is the members' desire to belong to something. Knowledge is the members' desire to know something. More to my current interest, a Web-based community needs a system behind it to support both affiliation and knowledge.

***

Excerpted from Chapter 10, "The Branches of Content Management," in the section titled "Online Communities."

If you own the CM Bible, click here to go to this section in the Web version of the book.

I believe that you can do e-business the same way you do content management. That is, you can create a process to collect, manage, and publish information and functionality to a set of target audiences. Information and functionality are the content of e-business. To do e-business or content management, you must do the following:

• Collect content. Your organization must set up systems that efficiently capture the information and the functionality you want to deliver. To collect content, you need editorial and metatorial systems. Editorial systems ensure that the content has appropriate and consistent format and style. Metatorial systems ensure that the content is appropriately and consistently tagged to be part of the organization's content scheme.
• Manage content. Your organization must set up a system to store and organize information and functionality outside of any particular delivery channel. Management systems are usually databases of one sort or another that store and categorize content, making that content easy to find and retrieve.
• Publish content. Your organization must set up a system to design and deliver the right information and functionality in the ways that your audiences expect and respond to favorably. The publishing system undoubtedly will manage a comprehensive Web site, but could and should manage the other sorts of publications your organization needs.

If your organization is wise, it will look past the hype and vague promises of e-business and focus instead on how to use the new technologies that become available to do what it has always needed to do. This work ought to give you an approach to all of e-business, not simply to the application of content management.

***

Excerpted from Chapter IN, "Three Good Reasons to Do Content Management," in the section titled "How do you do e-business? ."

If you own the CM Bible, click here to go to this section in the Web version of the book.

Localization and content management go hand in hand. In fact I'd go so far as to say that the central issues of localization are one form of the central issues of content management, as the following list discusses:

• Collection: How do you author or acquire content in a way that frees it from its context by explicitly stating its context? For localization, you make content free from its locality by tagging the parts that are locality bound. In content management in general, you make content free from any particular audience or publication by tagging the places that are audience or publication specific. In both cases, you're not trying to remove the context of the content but rather to explicitly state it so that you can formulate and implement logical rules for the use of the content. In a collection, for example, you can tag each example with the localities that it's useful for. You can develop alternative examples for your other localities.
• Management: How do you store and administer content in such a way that people can find, access, and most easily use it? In localization, the point is to deliver content to the localization team as efficiently as possible. Doing so may mean delivering only the examples that need translating to a particular language because you're tagging them for the locality that uses that language. In the wider content-management world, of course, management is responsible for delivering content to wherever it needs to go.
• Publishing: How do you ensure that the right content gets into the right publication in the right locations? In localization, this task is a matter of selecting the localized version of the content. You may, for example, want to make your CMS select and display only examples that you tag for the locality of the current user. In content management in general, of course, this concept is the central purpose of the entire publishing system.

Localization can come into play in any or all portions of your CMS design. Thus I leave the detailed discussion of localization analysis and design to the specific applicable sections throughout this work. I leave this section with the following two general principles of content management that apply especially well to localization, and I offer them as general guides to localization:

• Conservation of work: A CMS doesn't reduce the amount of work that publishing content takes; it merely shifts the burden of that work from a human to a computer. In localization, you want to adopt the attitude that your job is to put as much of the work as possible onto the CMS. You can, however, only shift it so far. If you want content that's useful to people, you can't escape that fact that people must do a core of the work.
• Balance of generality: The more general that you make your content, the easier it is to reuse. The more general it is, however, the less it communicates. You must balance a CMS between the constraints of reusability and strong communication. Similarly, you must balance the need to communicate at all with your key localities with your need to communicate well with your primary locality. Whenever I say, "on the fly," I tip the balance a bit toward my primary locality to give them deeper and wider understanding at the expense of other localities that may get less understanding.

***

Excerpted from Chapter 21, "Cataloging Audiences," in the section titled "Localization and content management."

If you own the CM Bible, click here to go to this section in the Web version of the book.

Localization is the process of making content as understandable as possible in the variety of cultures in which people view it. I'm going to work back from this definition to one that's more useful in the context of a CMS.

The definition has the following three major concepts:

• Culture: I want to keep this very complex issue as simple as possible and define culture as a set of shared communication and behavior standards that a group of people adopts and upholds. Not all that long ago, geography was the main indicator of culture. People who lived near each other shared a culture. Today, that's too simple a way to look at it. As anyone who's walked down the street in any major city of the world can tell you, cultures aren't countries. Today, I'd define culture as a dynamic mix of language, region, ethnicity, and other affiliations. To stay within the general bounds of the accepted localization terminology, I use the word locality and not culture to capture the concept of localization.
• Understanding: What makes content as understandable as possible? Clearly the language in which you write any text is the biggest factor. But it's not just language. As I discuss in the following section, translation is only the start. You must recognize and change a world of other, more subtle local conventions.
• Process: Localization is a process. In fact, I'd say that, by and large, it's an authoring process. Content that someone authors for one locality someone else must then reauthor for another. The localization process encompasses many mechanical parts, where bits of content move from person to person for processing. But after the content arrives on the localizer's screen, the mechanics end and it becomes a human process of knowing what "works" in one locality or the other.

***

Excerpted from Chapter 21, "Cataloging Audiences," in the section titled "What is localization?."

If you own the CM Bible, click here to go to this section in the Web version of the book.

A workflow, as I present it in this work, is a sequence of tasks that a staff member performs and that some event triggers. A workflow entity is a collection of data that specifies the tasks, staff, and triggers for a particular workflow.

Workflows involve steps that form a set of sequenced operations. For each step, you must collect the following kinds of data:

• An object, which is the part of the CMS that the step affects.
• A task, which is a discrete activity that makes some change to content, publications, or the CMS structure or configuration.
• A staff member, who performs the tasks as part of her job.
• A trigger, which is an event that signals that the step is to begin.
• A duration, which says how long the step is to take.

***

Excerpted from Chapter 19, "The Wheel of Content Management," in the section titled "Workflow and staffing."

If you own the CM Bible, click here to go to this section in the Web version of the book.

Cutbacks may be natural, but they're not easy. Someone's desire is thwarted for this version, and she isn't pleased. In addition, you must go back and redo some amount of the planning process to account for the change in project scope.

You have a few tools for coping with unhappy campers. First, you have the prioritized requirements that you originally collected and had approved. Your cuts should start at the low-priority content and publications, to be fair to all and to avoid conflict. Second, you have your sponsor group, which is in place to help with just these sorts of events. Make your case for cuts to your sponsors, not to the people whose requirements you must deny. Finally, you can console hurt feelings with the assurance that a high-priority implementation in version 2 can produce a much better result in the long run than a low-priority implementation in version 1.

You also must decide how far back in your planning to make the cut, as follows:

• Do you simply need to scale back the logical design? If so, you can get by with some markup on your design documents, showing which parts must be postponed. In addition, you must make whatever changes are needed to your project plan.
• Do you need to drop requirements? If so, you need to get the requirements reworked and approved again. Then you can mark up the design documents and project plan.
• Do you need to change the goals? If so, you need to reconvene the mandate group to make the change. Then you can make the corresponding changes to the requirements and get them approved again. Finally, you can change the design documents and project plan.

Obviously, the further back you go in the process, the more work it is. On the other hand, the further back you go, the bigger the change you can make. Personally, I think you derive collateral benefits from reengaging your mandate or requirements group. Doing so gives members a chance to stay active as a part of the process and to reassert their support. You want this to remain everyone's project.

***

Excerpted from Chapter 17, "Implementing the System," in the section titled "Cutting back."

If you own the CM Bible, click here to go to this section in the Web version of the book.

All project managers attend to the scope, schedule, and budget of their projects. It is really no different in a CM project. Project managers usually appear most in the start-up phase of a CMS. After the CMS is running, the other sorts of managers tend to step in and take charge.

Project managers do the following:

• Manage project staff, apprising them of their deliverables and schedules. Perhaps the most difficult thing in managing a CMS project is the potentially long list of characters whose input is needed. Especially during the requirements-gathering phase for the CMS, there are a lot of meetings, phone calls, e-mail messages, and small documents that have to be scheduled, accomplished, and accounted for.
• Manage budgets, assuring that the money allotted for the project lasts as long as the project does. Conversely, a good project manager will see an overrun a mile away and let the world know that some sort of change is needed long before the money actually runs out.
• Create and enforce the project plan. It might well be beyond the ability of a project manger to create the plan for a large CMS, but it should be fully within her ability to make sure it is updated and adhered to.

The kind of project manager that you want is the kind that can keep a lot of balls in the air and make sure a thousand little things get accomplished and no one is left out. Project managers with strong technical skills but little ability to negotiate competing constraints need not apply.

A good CM project manager (PM) will have strong negotiation skills and a streak of insistence. The successful CM project is a careful balance of stopping the unending conversation about what content and functionality will be included, and assuring that all relevant and necessary content and features are fleshed out and used. Finally, although your PM need not be an expert in any of the CM skill areas, she should have somewhat the same ability as the Content Manager to understand the staff's subject matter enough to know a big problem from a little one.

***

Excerpted from Chapter 11, "Staffing a CMS," in the section titled "Project manager."

If you own the CM Bible, click here to go to this section in the Web version of the book.

All in all, the Content Manager is the head of the CM endeavor in the organization. Because there is no degree (that I know of) in content management, there are no recognized curricula to pass to get credentials for this position. In addition, few people can say they have much experience being in such a position. Still, there is a core set of skills that you can look for in a Content Manager. The person must be capable of understanding the multiple disciplines involved in CM. They ought to have a good head for at least the following subjects:

• Web technologies, including server and client software and the construction of Web sites and Web applications. She does not need to be a Web developer, but a good Content Manager understands the Web.
• Editorial processes, including the writing and review process. She does not need to be a writer or artist, but a good Content Manager must recognize well-constructed content when she sees it.
• Cataloging and information organization. A Content Manager does not need to be a librarian, but she does need to be good at finding structure and making sure it is enforced.
• Information technology infrastructure, including database and network administration. Because the system has to integrate with the enterprise communication infrastructure and because the collection, management, and publishing systems of a CMS are all network and database applications, some knowledge in this area is a must.
• Analysis and abstraction. This may be the most important, but least measurable, skill of a Content Manager. If you haven't noticed, content management requires you to think very abstractly about information. If you get too stuck in the concrete details of how one page or another looks, you will lose sight of the main goal of CM, which is to break information away from its presentation and instead focus on its structure and how that structure can be used to make any of a range of pages. If this lightbulb has not appeared over your Content Manager's head, you will never have a robust system.

***

Excerpted from Chapter 11, "Staffing a CMS," in the section titled "Content manager."

If you own the CM Bible, click here to go to this section in the Web version of the book.

To really study your sponsors, you can create written profiles that answer all of the learning questions I listed earlier in this chapter Now, if you are truly a consensus builder, you immediately will be questioning the wisdom of this endeavor. Taking notes on people and creating files on them is not the way to gain their confidence and trust. So, if this seems just too risky or Machiavellian, skip it and content yourself with thinking about the questions and discussing the answers you find with the sponsor and your team.

On the other hand, if you can get past the feeling that you are acting like the next J. Edgar Hoover, this approach can be of immense value. If you act covertly and sequester the information you collect, then you will indeed be doing espionage. If you are open about your motives and up-front about your techniques, however, you are just being conscientious. Moreover, if you have the sponsors participate in filling out their own profiles and openly discuss the profiles in group meetings, then the profiling process can be as innocuous as any survey.

The point of profiling is to be explicit about how you will approach each sponsor. The more open you can be with this information, the better for everyone. In fact, the degree to which you feel like you can be open with your profiles indicates the degree of general openness in the organization. If you can manage to create a climate in which it is all right to share your approach to sponsors openly, you will be creating just the right climate for honest debate and real agreement.

Still, you can only be an idealist for so long. To my mind, it is always best to lead with complete openness and retreat, as required, to retain you personal comfort and your job.

One way or another, you should have in mind a profile for each sponsor so that you can think explicitly about how to get each one to agree.

***

Excerpted from Chapter 14, "Securing a Project Mandate," in the section titled "Sponsor profiles."

If you own the CM Bible, click here to go to this section in the Web version of the book.

Someone must be responsible for the overall design and creation of the system you will use to change the raw information you acquire into finished content. I call that person the conversion analyst. Her responsibilities include the following:

• Selecting or designing the tool set that the team will need. Given the set of information inputs and content component outputs that the content analyst has specified, the conversion analyst will need to figure out what tools to buy, or create, to make the transformation as efficient as possible.
• Creating the specifications for the programs that tool developers will follow.
• Designing the methods the team will use. Given the inputs, outputs, and selected tool set, the analyst must determine the right set of methodologies to move information quickly through the system.
• Designing the facilities and needed infrastructure if the team is going to be large. For example, you might need to create a large work area where dozens of people can sit and easily interact.
• Planning and estimating the staffing levels and skills that you will need to process the expected throughput of information. It can be difficult to accomplish this task if (as often happens) there will be wide swings in the amount of information that will be received per week.

This job is the analyst companion to the production manager job I described earlier. Whereas the manager is responsible for the day-to-day operations of the processing group, the analyst is responsible for understanding the situation and getting the system set up. A good candidate for this position deeply understands text formats such as HTML, XML, PDF, and SGML. They must be very analytical and meticulous by nature. Because this person must write content processing specifications, she must be familiar with, if not well versed in, programming. Because she has to create procedures, she also must be familiar with, if not well experienced in, process management and the techniques used by data processing facilities.

Data processing facilities are one good place to look for people with this skill. Wherever teams of people have been brought together to make their way through masses of semi- structured or unstructured information, you may find people who have the analytical skills and experience to be a conversion analyst. In my experience, I have seen such people in the back rooms of CD-ROM companies that publish huge catalogs, as well as in large law firms that must process grand mounds of court documents.

***

Excerpted from Chapter 11, "Staffing a CMS," in the section titled "Conversion analyst."

If you own the CM Bible, click here to go to this section in the Web version of the book.

When I began working on content management, the terms "content management" and "e-business" did not exist. Two years ago, when my organization decided to strategically pursue content management as a focused practice, only a handful of software companies and industry analysts were using the terms "e-business" and "content management." Today, content management is a fairly well-recognized product and industry category. Dozens of products claim to do content management, and all of the major analyst groups (Gartner, Forrester, and the like) have projected major investments in this area and a growing commercial sector. 

I believe that there is nothing new in content management and at the same time it is completely new. Most of the concepts that I build upon are from other fields. On the other hand, by bringing these ideas together, a new way of thinking about content and publishing emerges. For example, you need to know your audiences to do content management. This is not a new idea. Writers, marketers, and even computer programmers have been doing audience analysis in one form or another for a long time. On the other hand, by combining the way these three groups have looked at audiences and applying it to the very particular needs of personalization in a content management system, I can create an overall concept and practice of audiences that goes beyond what any of these disciplines has done. The results are not simply conceptual, they are a practical set of questions to answer and data to collect to make your audiences an integral part of your content management system implementation.

This work is my response to the questions I have been repeatedly asked. What I hear is, "This is so different I don't even know how to approach it" and "It's at a level of complexity far beyond what we have ever done before" and "This is so new that we can't find anyone with enough experience to pull it off." What I see most often is that people try to use their old methods and understanding to tackle a new problem, and it does not work. This work attempts to propose and detail a new approach that borrows heavily form older disciplines but forms a new discipline around the new needs of large-scale information creation, management, and publishing.

***

Excerpted from Chapter 0, "," in the section titled "Introduction."

If you own the CM Bible, click here to go to this section in the Web version of the book.

If you've come from a Web testing background, the training that helps you the least is the standard click-through tests. Many Web sites are tested simply by having someone click every link to see what happens. The whole point of a CMS is to create publications that change constantly. To keep up with the productive capacity of a running CMS requires that you have an army of clickers constantly trying every new page.

You must take a much smarter approach to testing the publications that your CMS produces. You find an analogous issue in software testing. In applications that can produce an unlimited set of output screens, instead of trying to use the application's user interface to test to make sure that all screens come out all right, testers back up to the code itself. They test the screen-producing functions to make sure that, for all scenarios they can think of, the functions produce reasonable screens.

***

Excerpted from Chapter 17, "Implementing the System," in the section titled "Publication tests."

If you own the CM Bible, click here to go to this section in the Web version of the book.

With a small pool of finalists, the time is right to get down to the small details. Do a more thorough job of analyzing the RFP and follow-up questions from the finalists, and schedule one or more meetings where your technical experts and theirs gather to envision the relationship. Experts can be of a variety of stripes, as follows:

• Business experts can gather to discuss terms of the contract that you may sign.
• Editorial experts and information architects can come together to discuss the collection system and metadata modeling facilities.
• Programmers can meet to understand how the system may be developed.
• IT folks can envision the architecture and deployment of the system.
• Publications staff can deliberate on the system's capability to produce the appropriate output.

As part of this set of meetings, you may want to schedule additional demos of the product or other background sessions to get your team fully up to speed on the capabilities of the products.

These discussions should result in a clear idea in the minds of your team of how you'd complete your tasks with the different systems. At this point, you should feel comfortable sharing your full requirements and logical design with the vendors to give them as much as possible to go on and to test the strength of their understanding and desire to work with your team.

The vendors should understand that they need to move beyond the sales staff to bring in people from their development groups or from their professional services groups who can really contribute. It help to bring these people in if you're clear, during these meetings, that you're testing the relationship that you hope to have with the company that you finally choose to work with.

I favor having each meeting result in a diagram that each side believes represents what the system may look like or do, given your needs and their product. Although the content of the diagrams change based on whom you're meeting with, the concept should hold across all the meetings that you hold. If you do this, you thank yourself later. You can hang all the pictures next to each other to help you choose from among a possibly confusing array of competing approaches.

***

Excerpted from Chapter 16, "Selecting Hardware and Software," in the section titled "Technical drilldowns."

If you own the CM Bible, click here to go to this section in the Web version of the book.

After you have developed a process for bringing in Microsoft Word files, for example, you need not develop another process just because another group also has Word files. Instead, you can take the process you developed for group A and extend it so that group A and group B can both use it. In the end, your process will be general enough that group Z can train on it and adopt it without much intervention on your part at all.

Likewise, for publications, you can begin to class your publications by type and extend your publication methods so that they can be used by others with the same types of needs.

When you have reached the state where you can route most new content and publications through standard collection and publishing interfaces, you will have a CMS with a very compelling value proposition for your organization. Your proposition would run something like the following:

You can do your own thing and continue to face all of the problems that we have over the last two years, or you can sign up with us (the CMS team). With a short training session and an agreement to adhere to some standards, you can be up and running very quickly. Your contributors will have well-tested and full-featured tools for creating your content, and your publications will have all the bells and whistles of the best publications our organization now offers.

***

Excerpted from Chapter 12, "Working Within the Organization," in the section titled "Organizing collection systems and publications by type."

If you own the CM Bible, click here to go to this section in the Web version of the book.

Most of the same caveats that I gave you for writers apply equally well to editors. The problem of the editor, relative to content creators, reminds me of the following quip:

"If you think Fred Astaire was good, consider Ginger Rogers. She was doing all the same stuff backwards!"

A good editor knows how to keep in synch with the creator and gently push her in the right direction. The problem is compounded by the fact that a single editor may be responsible for many creators and many types of content (text, pictures, sound, and motion). Professional editors are no strangers to this situation and are generally able to roll with the waves. Still, in the context of a CMS - where the content in not only does not look like what comes out, but must come out in a variety of forms, juxtaposed with who knows what other content - the editor must be able to think extra-abstractly about the content she reviews.

In addition, editors who are tied to particular methods (for example, being able to make changes to the text in the final publication rather than in the copy that is stored in the repository) will have to change their ways even if the new ways are not as foolproof as the older ways. Clearly, an editor who is comfortable only with pencil marks on a piece of paper would be a poor choice for your CMS staff.

***

Excerpted from Chapter 11, "Staffing a CMS," in the section titled "Editor."

If you own the CM Bible, click here to go to this section in the Web version of the book.

There can be a dizzying number of separate pieces of content flying around when a CMS is in full swing. You may very well need a person to coordinate and keep all of this information straight. I call this person the traffic cop. Her main responsibilities are as follows:

• Overseeing the delivery of content from authors and acquisition sources.
• Keeping abreast of the CMS workflows and ensuring that everyone is on schedule.
• Resolving any bottlenecks that may be affecting the flow of information.
• Resolving any disputes about who is responsible for what.

A good cop has experience in large-scale task management. She is not afraid to pressure people to meet commitments, but knows how to do so in a way that does not alienate contributors.

***

Excerpted from Chapter 11, "Staffing a CMS," in the section titled "Traffic cop."

If you own the CM Bible, click here to go to this section in the Web version of the book.

All organizations create some sort of written communication. Organizations employ technical writers to create product documentation, marketing writers to create brochures and press releases, and subject matter experts to create white papers and other background documents. Beyond these writers (and other content producers, such as graphic artists) is a group of editors who ensure that the output of the various writers is aligned and consistent. Consistency is the currency of content management. Without a strictly consistent approach to content structuring and tagging, the CMS cannot manage or publish content effectively. If your organization has editors, then they should mediate between the business units and the central repository. Editors within the business units forge consistency within the content of the units. Editors outside any business unit forge consistency among all of the organization's content. When you implement a CMS, these two types of editors should form a common understanding, and a common set of rules, to make the editorial processes flow smoothly between the business units and the larger CMS effort.

On the other hand, editorial organizations rarely have been called upon to perform the very granular metadata tagging needed by a CMS. Thus, editorial skills in the organization must be augmented by the metatorial skills needed to develop and apply the level of metadata consistency needed by a CMS.

***

Excerpted from Chapter 12, "Working Within the Organization," in the section titled "Editorial teams unify content."

If you own the CM Bible, click here to go to this section in the Web version of the book.

By far, your best bet is to have a single central repository and management system that extends across all of your needs. That's not the case with collection and publication systems. As long as all efforts use the same small set of interfaces to the management system, you should be free to allow contributors and publishers to do their own thing - within limits.

In fact, for a system with real enterprise reach, you need to release control of specific collection and publication activities and focus instead on serving general collection and publication needs. At first, you are most likely to create the specific collection systems that gather the content you have identified. Likewise, you will create specific publications. As time goes on, however, other content and publications will come to the fore that you also need to include. Rather than continually trying to do the collection and publication for the organization, you can start providing the tools for groups to do it for themselves.

***

Excerpted from Chapter 12, "Working Within the Organization," in the section titled "Using Functional Collection and Publishing."

If you own the CM Bible, click here to go to this section in the Web version of the book.

In all of the collection and publishing variations I mentioned, the only thing that was absolutely under the control of the CMS was the central repository. Even in the case of the external collection system syndicating to the CMS, the central repository can contain the definitive content to be shared by the organization. If you back off this, and the definitive content to be shared is in two or more places, then you are biting off some problems.

It is not so much that you shouldn't have more than one database, but that you shouldn't have more than one content structure and access methodology. Regardless of how many physical databases you have, if you have a single organizational structure and unified access methods, then you have a single repository. On the other hand, if you do not have a single organizational structure and unified access, even if you have all of your content in a single database, you do not have a single repository.

That said, if you can manage to have a single database for all your content, you will spare yourself the unenviable task of distributed data management. At the very least, you must have a single place where you can tell people to go to get the blessed version of a particular kind of content.

Optimally, you want to create a central repository that really unifies your content and content access.

To function as a central repository, your system must extend the following qualities over all of your content:

• Unified content structure. The way content is chunked and tagged (your components and their elements) needs to be standardized across all data sources.
• Unified organization. The hierarchies and other organizational schemes you use to categorize and get to your content need to extend to any place where the content is stored.
• Unified access. The way you query and make use of the content you retrieve needs to be the same across all data sources.

My best advice concerning management variations is to try not to vary too much. The headaches you will have - trying to keep track of what content is in what structure, organization, and access system - will be unending. You will also inevitably find yourself in a position of not being able to get to the content you need in a publication or particular page.

***

Excerpted from Chapter 12, "Working Within the Organization," in the section titled "Management variations."

If you own the CM Bible, click here to go to this section in the Web version of the book.

You may recall (or, by now, you may be tired of me saying) that I define a CMS as a system that collects, manages, and publishes information and functionality. I want now to offer another definition - just as valid - that I believe can deepen your understanding of what really goes on in a CMS: A content management system is a balanced interaction between the forces of the significant entities that control it. Metadata maintains the balance.

If the entities are in balance, they form a stable and effective system for content creation and use. I envision that system as a wheel.

At the hub of the wheel is the set of content component classes that you create. More than any other entity, the components lie at the center of the system. They're the place where all the other entities come together. They're the result of all the knowledge you've gained about the other entities and are the resources from which you draw to provide all the system's value.

The rim of the wheel is metadata. Metadata holds the system together and gives it shape. Any decision that you make ultimately results in some change to the metadata system that you construct. Metadata and components relate closely to one another. The majority of the metadata that you define is stored in the elements of the components that you define. Components are information or functionality chunks that you wrap in metadata. So although I place components in the center of the wheel for simplicity, you can just as easily imagine them spanning out from the center to the rim of the wheel.

The spokes of the wheel are the major entities. Just as do the spokes of a wheel, these entities keep the system from collapsing and from flying apart. Each spoke puts constraints on the system that tend to make it smaller and more well defined. Each spoke also offers possibilities and additional resources to the system that tend to expand it and keep it growing. As with a wheel, if the centrifugal (outward) and centripetal (inward) forces are in balance, the system is in good shape.

From this vantage, content management is independent of the particular hardware and software from which you choose to construct the system. Instead, it's an organizational process to bring a set of competing yet collaborating forces into alignment to amass and deliver value.

Lest you think that I've gone off the philosophical deep end, I can assure you that, abstruse as it may seem, the idea of content management entities, in practice, just represents a lot of good old-fashioned hard work. They're a convenient set of categories that you can use as you collect the information that you need to understand and construct your CMS

***

Excerpted from Chapter 19, "The Wheel of Content Management," in the section titled "Introducing the CMS wheel."

If you own the CM Bible, click here to go to this section in the Web version of the book.

As part of deploying the CMS, you want to power it up slowly. You can begin powering up the CMS at the beginning of implementation. Throughout implementation, you can bring more and more of the system into operation until, during deployment, you have all the CMS systems running.

Following are the steps that you may want to follow to bring the CMS to full power:

• Get the basic CMS package running in a simple, standalone environment.
• Get the basic package running in your production environment (that is, the full environment in which the CMS eventually must operate).
• Progressively add content and publications to the standalone environment and then add them to the real environment.
• Progressively add third-party software and integrations to the production environment.
• Release a beta system that can do everything that the final system can do.
• Release a final system that you can trust.

***

Excerpted from Chapter 18, "Rolling Out the System," in the section titled "Powering up the system."

If you own the CM Bible, click here to go to this section in the Web version of the book.

A template is, generally, a text file. You can open it in any word processor and pick your way through its commands, find the static and dynamic areas, and try to decode it. The file itself isn't capable of actually building a page. Rather, it's a set of instructions on how to build a page. The thing that interprets the instructions and carries them out is known as the template processor.

In an XML system, the template processor is often the XSLT software that loads and processes XSLT templates. Other Web-based systems use a standard Web template processor, such as Active Server Pages (ASP), Java Server Pages (JSP), or ColdFusion. Other CMS products have their own processors that recognize their own template commands.

In all cases, a template processor does the following:

• Loads templates: The CMS or sometimes a Web server invokes the processor and tells it which template to process. The processor then retrieves the template file.
• Skips static text and media: The processor can detect which parts of the template don't need processing and passes them through without change.
• Processes commands: The template processor recognizes which parts of the template contain some sort of directive that it needs to carry out. The processor picks out these commands and the parameters they contain and does what they say to do. The command [Insert Title], for example, causes the processor to perform its insert function. The insert function may access the current component, find the noted element (in this case the Title element), and place the value of the element right at the command's location.
• Calls external programs: If the templating system is capable of invoking external programs, the processor is responsible for finding them, passing them any parameters, and receiving the result. The command <CustomCommand Name="SectName" File="Myfunct.dll" ID="1234"/>, for example, tells the template processor to call the SectName function in the function library in the file Myfunct.dll and pass it the parameter ID="1234". The SectName function does its work (in this case, finding the section that contains component 1234). The external program returns its result to the template processor, which can do what it wants with the result. In this example, the processor may insert the result into the page it's building.
• Returns errors: A processor must have some way of detecting and alerting the template programmer of a problem. Problems are most often commands that you type incorrectly. These sorts of problems are easy to detect, and all decent processors report them. Harder to detect are errors in the way that you use a command or the wider logic of which individual commands are a part. Only the best processors provide the sophisticated debugging tools that you need to assist you in finding these more subtle errors.
• Returns a resulting node: After the processor finishes with a template, the result is always a built publication page or section with the static areas intact and the dynamic areas appropriately filled in. The result it either saves in a file for later release or, as in the case of a dynamic Web site, pushes directly back to the person who requests the node.

***

Excerpted from Chapter 22, "Designing Publications," in the section titled "Using a template processor."

If you own the CM Bible, click here to go to this section in the Web version of the book.

Componentizing content doesn't make sense until you have enough content to warrant the trouble. If you simply want to write a short story and put it on the Web, for example, don't bother creating a bunch of components. If, on the other hand, you're creating a creative-writing site, with an expanding stable of short stories, poems, speeches, reviews, and nonfiction articles, the initial time that you take to componentize this information can go a long way toward keeping your life sane and your site sound.

You often can find a natural way to divide information into components. Look again at the example of the creative writing site. The simplest way to divide the content is to create components the size of a single contribution. You may create a single component type that you call Contribution (or Contrib, because computer types hate to type). In so doing, you're naming and thus unifying a heterogeneous set of information sources into a homogeneous set of objects. You can now talk about a Contrib. You can say what one is, what one must have, and when to use one. You may say, for example, that all Contribs must have a title, a body, an author, and a date. You may permit no more than one Contrib per page, and all the Contrib titles appear alphabetically on the home page.

By creating and naming a component type, you begin to organize. You also open the door to the further naming of elements (Title, Body, and so on.) and the capability to select and arrange components to your advantage (for example, to select Contrib titles and arrange them alphabetically on the home page).

Now suppose that you do a good job of selecting and arranging these components and also manage to choose Contribs that people want to see. Your site grows in popularity, volume, and funding. You soon find that the Contrib component type is too simple to handle the issues that you must now confront. You find that not all Contribs are created equal. Speeches, for example, have a first-delivered date, an author, and an orator. Reviews involve a thing that's reviewed, and articles often come with a picture. You can continue to widen the definition of Contrib until it loses all meaning, or you can create a finer grain of components - say, short stories, poems, speeches, reviews, and nonfiction articles. With this more-detailed approach, you become more specific about the way that you create your site. You can now say, for example, that your site includes a TOC that divides the contributions up by category; that you center the titles of poems but not of articles; that the photos that accompany articles are left-aligned; and that speeches use a serif typeface.

No absolute "right" way to divide your information into content components even exists. The right way is the way that gives you the most advantage within your current capabilities and resources. That's not to say that you can go about this process in a casual way. On the contrary. You must divide the content according to well-defined and understood rules. The rules can and do change, but at any instant, you must have one set of consistent rules so that, at all times, your content is organized. You can imagine the problems that occur (and I've seen this situation more than once) if half the staff is still creating Contribs while the other half is now creating Poems and Articles components.

Many content projects falter on division rules. The fact that you can never give a "right" answer can cause innumerable arguments. The best answer about how to divide information into content components is the one that provides a workable balance between the natural divisions in the information, the divisions that you need to make your publications, and the divisions that you can make in the time and budget that you have.

***

Excerpted from Chapter 23, "Designing Content Components," in the section titled "How do you divide content?."

If you own the CM Bible, click here to go to this section in the Web version of the book.

If you've ever been exposed to the ideas of object-oriented programming, you have a good leg up on content components.

Once upon a time, programmers wrote one long program that needed to run from start to finish without stopping. Today, programmers write objects, which are smaller programs that do a small thing and then stop. Objects are small, reusable pieces of functionality that the programmer links together to achieve a larger result.

An e-commerce Web site, for example, may use an object for processing transactions. The site's programmer links this object together with others to create the entire site mechanism. How does the programmer link objects? By wrapping the core resources of the object in a standardized container (usually known as an Application Programming Interface, or API) that programmers can use without knowing anything about the internal programming of that object. On the e-commerce site, the programmer may call the transaction object to do tasks such as total up the order, compute tax, and process credit card transactions. The programmer doesn't need to know anything about the programming code in the object that accomplishes these tasks. She needs to know only how to find the object and ask it to do its thing.

Content objects (components) rely on a very similar concept. Content components are small reusable pieces of content that you can link together to achieve larger results. On the same e-commerce site that I mention in the preceding paragraph, for example, you may make each product a component so that you can link them together into catalog pages, show a list of them on an invoice, or show the user full product detail. If you represent each product as a component, you open a lot of possibilities for mixing and matching products and customizing their appearance for a particular situation. In some circumstances, for example, you may need to show only the name and price of a product, while in another circumstance, you may need to show the full detail of the product, including a complete description, product dimensions, and a picture.

The way that you use content components is the same as the way that the programmer uses objects. You link together small pieces to make a larger whole. Additionally, content workers learn how to work with the component, not with the information within the component, to achieve the same sort of independence that the programmer gets by working with programming objects. To build a page, you needn't know what's inside the component - only how the standardized container of the component operates.

***

Excerpted from Chapter 23, "Designing Content Components," in the section titled "Components are like objects."

If you own the CM Bible, click here to go to this section in the Web version of the book.

An author is someone who creates original content. The title author was formerly a special distinction given to people who made a career out of content creation. And that's still the case today for people who define themselves as authors.

If you take this definition literally, however, which is what I intend to do, the name author applies to anyone who creates content (regardless of what such people call themselves). I know of very few organizations (professional publishing firms notwithstanding) that can afford the luxury of all their authors being professionals. Instead, authors are as often as not people with other jobs who happen to know about something and can (more or less) communicate it.

In a large CMS, this situation is especially true. You're likely to need to deal with all types of authors, from the professional writer to the engineer who failed high school composition. If you're smart, you design processes that recognize the various classes of authors that you employ and work with each on its own terms.

Authoring today doesn't even end at the organizational borders. Collecting original content from your audience is also possible and, indeed, is often a great idea. If you can turn your consumers into contributors, they become much more engaged with your organization and, of course, can supply you with content you'd have a very hard time collecting otherwise.

So I hope that I've sufficiently blurred the concept of author in this section that you're now comfortable calling people authors who'd never call themselves authors. Beyond just calling them authors, however, you need to treat them as authors, providing them with the tools and guidance that they need to successfully contribute to your CMS.

***

Excerpted from Chapter 24, "Accounting for Authors," in the section titled "Who can become an author?."

If you own the CM Bible, click here to go to this section in the Web version of the book.

Most people underestimate the amount of information you need to accumulate to fully define a large CMS. In fact, many organizations skip the stage of defining their requirements for the CMS entirely, and simply begin using whatever software they have purchased, trying to make it produce pages like the ones they have now.

Contrary to what you might expect me to say, I don't believe that this is a bad approach. Given that you have a long time to play with a system, experiment with what it can do, and determine what it requires of your organization, this method can give you a very good start. It can teach you all the basics of content management and give you practical experience with a real tool.

On the other hand, there is a big leap from a system that can produce some pages like the ones you have now, to one that can organize your entire production and distribution process. You can't expect the latter process just to happen by turning on, and using, even the best CMS.

Other organizations rush to buy a tool and then begin an analysis. Again, this can work. By immediately imposing the constraints of a particular product on the project process, you get to use a lot of the methods and tools that the CMS product company might provide. In addition, you can show immediate results and hit a big milestone quickly. On the other hand, if you buy before you study, you risk the very real possibility of having purchased a (very expensive) system, only to find after using it for a while that it was the wrong one for your needs. Finally, by choosing a tool before you really know what you want to do, you may end up not doing something that the tool does not readily do simply because it is off the tool's radar screen (regardless of how much value it can have for your organization).

If you have followed the steps I have laid out so far, you already have spent a lot of time working through the issues and should have a lot of detail about what people want and require of the system. You might think that what you collected during the readiness assessment and mandate process ought to be enough to define the system. Maybe it is, but probably it is not. What you have collected so far certainly establishes what people want, but does it define what your organization needs? At the very least, you will have to organize and augment these wants and get the organization's departments to agree that they are complete. More likely, you have a good start and a lot of general statements but nothing specific enough on which to base a system design.

***

Excerpted from Chapter 15, "Doing Requirements and Logical Design," in the section titled "Why do logical design?."

If you own the CM Bible, click here to go to this section in the Web version of the book.

If you take the trouble to do a complete logical design, it will help you significantly in the following ways:

• System selection: In logical design, you say exactly what you want your CMS to do. If you already have a CMS package in mind, then your planning team can use the design to decide the degree of fit between the selected system and the design. If you have not yet selected a system, then the design will give you a clear picture of the system you want. You can compare your picture to the one presented to you by the product companies you review. You will also be able to ask intelligent questions of the CMS product vendors and not be overly swayed by slick presentations. Finally, if you choose to develop a custom system, the logical design provides great input for your software requirements specification.
• System implementation: To implement a CMS, you create a set of specifications. The specifications combine what you want to do with how you will do it. The logical design is what you want to do. The features and functions of the CMS you will build or buy are how you will do it. If you do not get a clear idea of what you want to do, then the features and functions of the CMS you use will decide for you. A logical design puts reality into your specifications by making sure that the features and functions it defines are seen in light of the exact content and publications that you want the system to manage.
• System rollout and maintenance: The logical design should provide just the right starting point for many of your system deployment deliverables. For example, the logical design describes in detail all of the staff that will contribute to the CMS. The system must be deployed to these same people. In addition, much of the documentation you will need to train users and maintain the system can come directly from the logical design deliverables.

***

Excerpted from Chapter 15, "Doing Requirements and Logical Design," in the section titled "Why do logical design?."

If you own the CM Bible, click here to go to this section in the Web version of the book.

Your position in the requirements process is scribe and librarian. The most help you can offer is to keep the list of potential requirements from getting out of control and becoming confusing. The work you do to synthesize people's input into an easy-to-read and easy-to-understand document is crucial. When someone does not see her words in the document you produce, you should make it clear that her requirements are being superseded by larger and more central concerns, rather than ignored. There is a subtle art to combining requirements in a way that no one feels slighted, but that inferior input is weighted less than superior input.

***

Excerpted from Chapter 15, "Doing Requirements and Logical Design," in the section titled "Catalog everything."

If you own the CM Bible, click here to go to this section in the Web version of the book.

The requirements process I will lay out is quite a bit simpler than the one most software developers use. Rather than asking an exhaustive set of questions that will lead directly to a design, I recommend that you ask simple questions, which provide you with the overall direction you will need, in order to dig for the more fundamental questions and answers.

The process I present is predicated on the assumption that the people you will approach for requirements will have neither the time nor the insight to give you real answers. They do, however, have the ability and the authority to determine the broad outlines of the system.

***

Excerpted from Chapter 15, "Doing Requirements and Logical Design," in the section titled "Gathering requirements."

If you own the CM Bible, click here to go to this section in the Web version of the book.

An author entity describes one or more people who share enough in common that you can treat such people as a group. An author group can be a group by virtue of the fact that everyone in it creates the same kind of content or uses the same tools or has the same relation to the core CMS group. Your author groups may share more than one of these traits (or, at least, you hope so). The point of creating author entities is so that you can work in the same way with a group of people rather than with individuals.

The following kinds of information associate with author entities:

• Identification, including a unique ID and a name for each group.
• Content, because you need to assess which and how many content components each group can create and how frequently.
• Tools, because you need to know what sort of authoring tools you must supply and which you want this group to use.
• Relationship, because you may hire authors to create content; they may simply contribute out of kindness; or you may have any relationship in between with them. To know how to work with a group of authors, you need to understand how the group relates to your team and its goals.

Although authors relate indirectly to all the other entities, they have a major and direct relationship to audiences, components, and workflows.

***

Excerpted from Chapter 19, "The Wheel of Content Management," in the section titled "Authors."

If you own the CM Bible, click here to go to this section in the Web version of the book.

Just saying that metadata is data about data isn't much of a description. The term is in wide enough usage these days to have a lot more behind it.

You can get a fair feeling for how people use the word by looking at the following few sentences from the home page of the Metadata Coalition at www.mdcinfo.com/:

"The Coalition allies software vendors and users with a common purpose of driving forward the definition, implementation, and ongoing evolution of a metadata interchange format standard and its support mechanisms. The need for such standards arises as metadata, or the information about the enterprise data emerges as a critical element in effective data management. Different tools, including data warehousing, distributed client/server computing, databases (relational, OLAP, OLTP . . .), integrated enterprise-wide applications, etc. . . . must be able to cooperate and make use of metadata generated by each other."

This excerpt, one among many that you can find on the Web, shows the main characteristics of metadata as people most commonly use the term, and the following list describes those characteristics:

• Sharing: Metadata provides the capability to share data across applications. By employing data that describes the use and meaning of the data that it surrounds, one system can interpret and translate the data that it receives from another. In a content management context, metadata enables publications that each need a somewhat different form of the same data to draw from a common repository.
• Standards: Metadata is a set of standards that groups agree to for information definitions. Standards, which are the basis of any kind of data sharing, bring the possibility of large-scale efficiencies in information interchange among groups that don't even know one another. In the content management context, the standards may be mostly internal today, but they serve the same purpose. Standards ensure that others can automatically reuse the efforts of one person or group if they all follow the same standards.
• A focus on databases: The main reason today for an interest in metadata is the sharing and standards behind "standard" database applications. Data warehousing and interapplication data transfer are huge concerns for organizations with an enormous amount of data trapped in databases and other files that no one can interpret except by using the application that created them.
• An awareness of the wider world: Today, metadata is mostly used in data systems. A vague but growing understanding exists, however, that metadata isn't just for data. The previous quote from the Metadata Coalition mentions "integrated enterprise-wide applications." A CMS is an integrated enterprise-wide application. Metadata is critical, not only so that a CMS can integrate with other enterprise data sources, but so that the CMS itself can unify and make the best automated use of the information and functionality that it manages.

***

Excerpted from Chapter 20, "Working with Metadata," in the section titled "What does metadata mean?."

If you own the CM Bible, click here to go to this section in the Web version of the book.

The word meta itself has no meaning except (according to the Oxford English Dictionary) as a column that marks the boundary of a circus. In more general usage, meta is a prefix. It modifies the meaning of the words that it precedes.

Merriam-Webster OnLine (at www.m-w.com) states that, as a prefix, meta means the following:

• Occurring later than or in succession to.
• Situated behind or beyond.
• Change or transformation.
• Later or more highly organized or specialized form of.
• More comprehensive or transcending

All these definitions give depth to the idea of meta that I have in mind in this work. Meta-things come after the things themselves to add context and organization to them. They go beyond the things themselves to a higher level of abstraction, where you see the things in a wider and different light.

***

Excerpted from Chapter 20, "Working with Metadata," in the section titled "What does meta mean?."

If you own the CM Bible, click here to go to this section in the Web version of the book.

In addition to being the way that you encode a file, format is more commonly known as the qualities that you use to visually render content. If I use the word format without qualifiers in this work, I mean this sort of format. Typographic qualities such as bold, italic, and underline, as well as layout qualities such as tables, right alignment, and margins, are all part of this definition of format. Although I dwell most on text formats in this work, the other media types (images, sound, and motion formats) all have unwritten equivalents of the notion of format.

Rendering format is important because you must manage it across all of the content that you intend to handle. The following list describes two ways in which you must manage your format:

• You must make format consistent across content categories, as well as across all content, in a single publication. To ensure readability, for example, you want to make certain that all of your news releases feature the title centered and boldfaced at the top of the page. You can also format a cross-reference link the same way, across all of the content in your publications, to ensure that the user recognizes it as a link.
• You must separate format from content so that you can reuse the content in a variety of outputs. Although making your titles centered and boldfaced may be appropriate in your Web design, for example, you may prefer to make them left-justified and italicized in print. In this case, the title itself doesn't have any set format associated with it; rather the publishing system enables the title to adopt the title format that the specific publication uses.

For the content manager, rendering format is best thought of as separate from content. For the consumer of content, the two are inseparable. The typography and layout of the page tell you much of what you need to know about the page. Format is a kind of metadata. It's information above and around the language on the page that tells your brain what to do with the language on the page. It tells the reader things such as "This part is important," "Read this section first," or "This text is a link." It guides your eye and your emotions around the language, leading you, if done well, to a much faster and fuller understanding of the information on that page.

***

Excerpted from Chapter 2, "Content Has Format," in the section titled "Rendering Format: Presenting Information ."

If you own the CM Bible, click here to go to this section in the Web version of the book.

Nothing causes an organization to get efficient about its processes quite like a deadline. Moreover, nothing else equals a continuing string of deadlines to really hone an organization's processes. The periodicals publishing industry has just such deadlines. Consider a newspaper organization that produces a large book's worth of content each day. Streamlining every part of its process, from content creation through final publication, is more than essential for a newspaper. I was involved in the launching of one of the first online news organizations - MSNBC. I was quite impressed to see how it (and we) got better and better over time at putting out the day's news on time. In the end, we developed a hybrid between standard news processes and new electronic processes that enabled us to move a piece of content through a sophisticated series of tasks quickly and reliably.

Out of this environment of continual deadlines and large team efforts comes much of what I describe as part of the collection process, including the concepts of workflow, aggregation, and acquisition. I'm lifting my entire concept of syndication intact from the publishing world.

***

Excerpted from Chapter 9, "The Roots of Content Management," in the section titled "Content collection."

If you own the CM Bible, click here to go to this section in the Web version of the book.

In the spirit of casting a broad metadata net, I offer the following list of the types of metadata you're likely to encounter in your travels through the domain of content management:

• Structure metadata: The ruling monarch of metadata. It precedes most other kinds of metadata by creating structural divisions in your content.
• Format metadata: Applies to any level of structure that you define and marks how you intend to render that structure.
• Access metadata: Organizes the structures that you create into hierarchies and other access structures.
• Management metadata: The data that you attach to structures to administer and track it.
• Inclusion metadata: Stands in for external content. It marks the place where the external content is to go.

One of the best ways that I can think of to get quickly immersed in the wide view of metadata is to look at some good markup. Markup languages (such as XML) are the major way that you apply metadata to content. The other major way that you apply metadata is in database rows and columns.

***

Excerpted from Chapter 20, "Working with Metadata," in the section titled "Understanding the Types of Metadata."

If you own the CM Bible, click here to go to this section in the Web version of the book.

People will not naturally seek out the CMS and contribute to it. Rather, the CMS team must seek out contributors and go to them. To begin, you must define what makes information valuable to your organization. Some of this valuable information comes from outside the organization (industry news, for example) and some comes from within the organization (case studies, for example). For the information originating inside the organization, you must discover the following:

• Where in the organization is it created?
• What particular people or job descriptions create the information?
• What is its initial purpose?
• To whom is it distributed?
• Are there places (directory locations or file cabinets, for example) where the information naturally collects?
• Are there particular people or job descriptions that collect and save this information out of interest or job function?
• In what formats is it produced?

The main obstacles to harvesting information from the organization are finding it, understanding how to remove it from its original context, and any adverse attitudes in the content creators.

***

Excerpted from Chapter 12, "Working Within the Organization," in the section titled "Understanding your information."

If you own the CM Bible, click here to go to this section in the Web version of the book.

For a computer to use information, it must convert it to binary code. If you digitize a printed picture, for example, then the scanner must convert the picture from tiny blobs of color on paper to a structured set of ones (1) and zeros (0). Over time, the various kinds of structures that programmers have devised have become generally accepted. In images, formats such as JPEG and GIF are now the standards for Web publication, and formats such as EPS and TIFF are the standards in print publication.

Computer files are the traditional way to store binary information, so binary format is also known as file format. Each binary format has its own way of representing the information that it encodes. Most image files, for example, feature code at the top of the file that tells what kind of file it is, and how big it is, and gives a wealth of other format-specific data. Vector graphics are encoded as a set of equation values that, after calculated, create the shapes that you see in the image.

In text, the characters you type are generally encoded using American Standard Code for Information Interchange (ASCII) or its more modern equivalent - Unicode. This definition is the most fundamental one of format - the way information is encoded so that computer applications can use it.

Binary format is important because you often must move between one binary format and another. You may receive images in EPS format, for example, and must convert them to JPEG format for a Web publication. Or, you may need to keep both versions because you need to use the same images in print and on the Web. Although the various formats all represent the same sort of information, moving from one to the other isn't always easy.

Microsoft Word (DOC format) files, for example, are notoriously hard to convert to Web files (HTML format). Although they're both text formats, any number of conventions that exist in a DOC file don't exist in an HTML file. Thus, you get inconsistent, poor results if you try to convert between one and the other without a lot of intelligent human oversight.

***

Excerpted from Chapter 2, "Content Has Format," in the section titled "Binary Format: Storing Information."

If you own the CM Bible, click here to go to this section in the Web version of the book.

E-business is the process of electronically delivering the right parts of your business at the right time. Generally, you deliver your business through computer networks and onto someone's computer screen. The essence of e-business, however, is not in the particular way in which you deliver your business, but in the fact that the essential parts of your business are stored and managed digitally and can be delivered in whatever medium you desire. By digitizing the information and services your organization provides, you make it available for delivery over digital or nondigital channels. Your own Internet site is only one of these channels. Others include the following:

• Your intranet site and any extranet sites you host to communicate with partners
• The Web sites of other partner and promoter organizations
• Kiosks and other offline digital publications
• Print publications that include shared information and "paper functionality"
• Screens for devices such as Web-enabled phones and personal digital assistants (PDAs)
• Personalized broadcast e-mail messages

What are the parts of your business? Loosely, you can break these parts into information and interactions, as follows:

• Information is the text, sound, image, and motion that communicate what you would like to convey to your constituents.
• Interactions are the capabilities you would like to project, such as buying product, asking for help, contacting an individual in the organization, or participating in an organization-sponsored discussion. Interactions are pieces of functionality that your organization can digitize and treat just the same as information.

To do e-business, the wide and possibly unorganized information and interactions that are key to your organization must be identified, digitized, and segmented into useful chunks so that they can be delivered individually to those who need them — customers, members, staff, partners, or constituents.

***

Excerpted from Chapter IN, "Three Good Reasons to Do Content Management," in the section titled "Delivering any part of your business ."

If you own the CM Bible, click here to go to this section in the Web version of the book.

Without some notion of who a person is, personalizing for that person isn't possible. Who the people are that use your publications is the subject of your audience analysis Some organizations personalize on an individual basis, bypassing audience segments all together. I believe that this approach doesn't deliver nearly the value to the organization as personalizing by audience segments.

By using your audience analysis, you can come up with the set of traits and trait values that each audience type may exhibit. Each cluster of these traits is a user profile that you can collect, store, and access to decide what kind of person you're dealing with.

Determining a user profile is one thing. Collecting trait values for each person who uses your publications is quite another. In pursuit of an audience trait, you really have only the following choices:

• You can ask: The most reliable and straightforward way to find out about someone is to ask the person. Of course, this approach is also the most time-consuming and intrusive way to find out.
• You can infer: Based on the actions that a person takes in your publication or based on other traits that you know the person has, you can make an educated guess on the value of related traits. Getting it wrong, however, is all too easy if you guess. Is the person who consistently goes to the children's section of your site, for example, necessarily a child?
• You can buy: Given a name and address, you can sometimes buy the trait values that you need for a person. Any number of sources of information about people are for sale. Moral issues (and you face many) aside, this method may or may not give you the specific traits that you need and may not prove very accurate on the traits that it does provide.

All in all, asking is still the best way to get good information. If you do decide to ask for information from your audience members, keep the following points in mind:

• Trust: I wouldn't give my name to someone I don't trust. On the other hand, I'd tell just about anything to someone I do trust. Before you ask a question of a user, ask this question of your organization: "How does she know that she can trust us and what can we do to communicate that trust?"
• Value: Users understand quite well that their information is of value to you. What do you give them in return? The value that you return doesn't need to be monetary. In fact, if you work through your audience analysis in the way that I present it, you already know what value you can provide to each audience and are already thinking about how to communicate it to them.
• Time and effort: Even if trust and value aren't an issue for people, time and energy probably are. You can think of each question that a person must answer as a small barrier. If she perceives the barriers as small enough, the user hops over them and sees them as not much of an obstacle to progress. As soon as the barriers get too high to easily cross, however, they stop the user and frustrate her until she stops providing any information at all. Asking 10 questions on one page of a Web site that a user must answer before she can continue, for example, is more of a barrier than many people are willing to cross (unless the information on the other side is very valuable to them). One question on 10 pages that you disperse throughout the site makes up a smaller set of barriers that the user can "take in stride" as she moves through the site.
• Context: If the user ever stops and asks, "Why are they asking me that?," you haven't done a good job of presenting the question. The user is at best confused and, at worst, is put off and refuses to answer. Make sure that you explain why you need the answer to the questions you ask or, better yet, position the questions in a context where an explanation isn't necessary. If you ask for the user's age on the home page of your site, for example, the question may seem out of context. But if you ask the user's age on the page where you then select a set of songs for her, she understands why you want the data and is likely to report it more honestly.

***

Excerpted from Chapter 22, "Designing Publications," in the section titled "Personalization and the audience."

If you own the CM Bible, click here to go to this section in the Web version of the book.

I assume that you're likely to be familiar with Web-site testing, software-application testing, or, perhaps, no testing at all. If you have no familiarity with computer testing at all, your effort to read up on it or take a short course is definitely repaid. I don't spend any time at all going through standard testing methods.

If you come from a software testing perspective, your best information is found under the heading of enterprise integration. Assuming that you do all the standard testing on the CMS's custom applications and template code, your main concern is the innumerable dependencies between the CMS and other systems. The most critical of these are on the Web server. Web servers aren't the most robust systems to begin with, and if you add the complexity of dynamic, high-volume sites to them, they can and do fail frequently. Stress tests on the server are thus critical to your peace of mind and future ability to sleep. You should consider testing for at least these following sorts of loads:

• High browser transaction volumes on your most dynamic pages. In logical design, you've estimated transaction volumes. I suggest doubling these values in testing. Or, better yet, increase the volume of page requests until the system fails.
• The effect of live publishing. Try pushing a lot of new pages and database records to your site while it has an average to high transaction load on it. This simulates a publishing cycle. You want to make sure that no bad things happen if you do large updates later.
• Simultaneous authoring. If your live databases have data added to them at the same time they're accessed by end users, make sure that the process doesn't destabilize your system. If you collect and publish news stories on your live site, for example, ensure that the news-story page continues to publish correctly even as you plow in as many news stories as your staff can add simultaneously. Of course, it's rare that you wouldn't impose a workflow step or two between the news-story creation and its publication, but still, make sure that nothing strange happens.

In planning for system tests, the best approach that I've seen is to create a large dependency spreadsheet that lists all the parts of the CMS and supporting systems (Web servers, enterprise data systems, and so on) on both the row and column headers. In the cells of the spreadsheet, type what can go wrong for the row and column that intersect there. Then use this as your first test plan. As you (or your test crew) test each intersection, don't forget to enter the new scenarios that come up.

In addition to being a great way to test the system, this is a great way to learn the system and how all its parts interact. Make sure that you pass this spreadsheet on to the people who must document the system and do training.

***

Excerpted from Chapter 17, "Implementing the System," in the section titled "Testing the system."

If you own the CM Bible, click here to go to this section in the Web version of the book.

The time between now and the heart of the Information Age is a period of transition. We will continue to move in fits and starts toward a world where information is more and more freed from the context of its creation but more and more constrained to fit within a known system of categories and relationships. This transition is spurred by the technologies we newly have at our disposal to create, organize, and easily distribute information. It should be guided by the needs of the organizations that are using these technologies to interact more and more efficiently and intimately with their constituencies.

This work can help ease your transition from the information overload period we are now in to the information economy toward which we are headed. It tries to answer the following key questions:

• What does a system that handles massive amounts of information look like?
• How can a system be created that recognizes the value of each piece of information and guides contributors to most easily contribute to a growing knowledge scheme?
• How can a single system produce a very wide range of well-targeted custom publications from the same information base?
• How can all of this automation and systematization of information happen without endangering the very important relationship between the author and her readers, listeners, or viewers?
• What are the steps and processes you need to create such a system?
• How can this sort of system fit into and serve an organization's overall goals and initiatives?

So, I am promising you a lot in return for your commitment to content management. I am promising you that you will have a way to conceive of e-business and begin on your organization's journey into e-business. I am promising that you will have the tools you need to combat the onslaught of information that your organization is facing. Finally, I am promising that you will be closer than you were before to becoming part of the coming information economy.

***

Excerpted from Chapter IN, "Three Good Reasons to Do Content Management," in the section titled "Content Management in the Information Age ."

If you own the CM Bible, click here to go to this section in the Web version of the book.

The CMS administrator and her assignees need comprehensive documentation on how you put together and configure the system. In a way, an administrator's guide is the sum total of all the system configuration and setup that you do. Thus, even if you do no more than gather this information from the specs and other sources that you may have and then put it all in one place for the administrator to access, you're doing enough. Don't expect authors and processing teams to plow through raw information to learn what they need. You can, on the other hand, expect that a CMS administrator's familiar enough with the source documents and the system itself to find the needle that she needs in the haystack of files. As you gather the administrator's stack, don't forget to include the following:

• Any system diagrams that you may create that show the relation of parts of the CMS.
• The documentation from all third-party software that you include.
• All support agreements that you sign.
• The full documentation set that you prepare for other staff. (The administrator, by the way, is a good point of distribution for this stuff.)

The one thing that you may need to create for an administrator's guide is the list of responsibilities, the reporting procedure, and the escalation path for the administrator to follow. This material should be mostly present in the staffing plan that you create.

***

Excerpted from Chapter 18, "Rolling Out the System," in the section titled "The administrator guide."

If you own the CM Bible, click here to go to this section in the Web version of the book.

Talking of templates building pages is common practice. Most experienced CMS staff take page templates for granted. Less common but still acceptable is to talk of templates building print sections. Most people simply accept section templates. I'm going to take this tendency one step farther (into an area that I don't hear widely discussed): to talk of templates within templates building parts of pages. Content and navigation templates are a concept that I use to extend templating to the parts of a page.

You have the following two main reasons for using page templates:

• To modularize the production of a publication node: You can always build a Web page of a certain type, for example, from the same combination of static and dynamic areas, and so you package the process in a template and apply it to a set of pages.
• To standardize the presentation of a particular type of node: By using a template, you're sure that nodes of a certain type always look a certain way. Moreover, to change the presentation of a certain type of node requires only a change to the template and not to each node.

You have no compelling reason, however, to stop at the level of the page. Within a Web page are dynamic areas. Each of those areas may also consist of static areas and dynamic areas. You can pack these area into a template as well and reuse them as necessary whenever you need to produce that particular dynamic area. The benefits of templates apply just as well to parts of a page as they do to whole pages.

A dynamic navigation area, for example, may prove useful to create. It may create an expanding and collapsing TOC that lists all sections down to a specified level of the site's TOC. The area may contain the words Table of Contents and a set of static links to an index and full-text search facility above it and the expandable outline below it. As you're designing your site templates, instead of repeating the definition of this area over and over, you can call it the TOC Navigation template, define it once, and reference it wherever you need it in other templates.

In using the TOC Navigation template, you modularize your approach to the site TOC; you standardize its presentation; and you make it easy to globally update.

***

Excerpted from Chapter 22, "Designing Publications," in the section titled "Using templates within templates."

If you own the CM Bible, click here to go to this section in the Web version of the book.

Templates use logic to specify the operations that they need to perform to build a page or section. In any particular templating system, logic is a programming language that you use to specify commands and processes. To illuminate how templates work, however, you don't need to learn programming language but only a few simple programming concepts.

In my discussions of template logic, I boil the world of programming down to the following few constructs:

• [Insert ____] means insert the thing that you name at the location of the command. No matter that the command doesn't say how to find the thing or whether it's a component, an element of a component, or some other thing. For the purposes of understanding template logic, these fine points are unnecessary. The command [Insert Title], for example, means, "Insert the Title element of the current component here."
• [For Each _____ ][Next _____] means do the operations that these two tags bracket multiple times. Never mind how the processor knows how many to do or what exactly is the thing they refer to. That's all for the programmers who create programs to figure out. Knowing that the same operations need to work over a range of content is enough. The command [For Each Article] <H1>[Insert Title]</H1>[Next Article], for example, means, "Insert the title of each article component, surrounding it by first-level heading tags."
• [If ____ ] [End If] means do the operations that these two tags bracket only if the specified condition is true. Never mind how the processor can determine true from false. Knowing that certain actions are conditional and depend on others is enough for now. The command [If you have OtherNews components] <H2>Other News</H2>[End If], for example, means, "Put in the other news headings if you have any OtherNews components."
• [Run ____ ] means run the program that you mention. Others decide how to make this "real" programming. For now, specifying that you need to write and run some program at a certain point in a template is enough. The command [Run Credit Card Transaction], for example, means, "Run the credit card transaction program here."

This very small set of pseudo-programming logic statements is all that I need to illustrate the template logic that I describe. If you need others to describe your templates, make some up. Nothing's in any way special about the way that I create these examples. They're simply a way to give you enough language to state what you want to happen in a way that's easy to read and that you can later make into programming code.

***

Excerpted from Chapter 22, "Designing Publications," in the section titled "Understanding template logic."

If you own the CM Bible, click here to go to this section in the Web version of the book.

A cross-reference directly relates one chunk of content to another. I use the word cross-reference to encompass the more widely used term hyperlink. A hyperlink (or just link) is a way to jump from one Web page (or other electronic publication node) to another, irrespective of where on the site it is. I like the term cross-reference better because it's more descriptive and applies across all publication types.

Cross-references have moved from the sidelines in traditional publications to center stage in electronic publications. In fact, the World Wide Web was named for the web of interconnections that are possible through the use of cross-references that can cross not only two pieces of content in the same content domain, but also two pieces of content in any domain that's on an accessible Web site.

The connotation of the term cross-reference is a bit lackluster for the meaning that I intend for the concept. A much more evocative word is association. Behind each cross-reference is an association between the content chunks you're linking. The association answers the question, "If I'm here, where else may I want to be?" The usual answer of "For more information, see . . ." is the very tip of the enormous iceberg. With what other content, for example, do you associate a content chunk about cows? Surely much more than simply more information about cows! What about farms, animals, spots, religion, milk, songs, meadows, laziness, and a million other places that someone may want to go next? Imagine the possibilities of a system that can detect where you may want to go next and jump you directly there.

***

Excerpted from Chapter 26, "Designing Content Access Structures," in the section titled "Cross-references."

If you own the CM Bible, click here to go to this section in the Web version of the book.

An index is an ordered list of words or phrases that categorize content. I use the word index to capture and encompass the following terms:

• Keywords: People often use this term in the computer world and, especially, in the Web world to mean a list of terms or phrases that you can choose from to jump to the content that they describe. This operation is often known as a keyword search, but in fact, you can more aptly describe it as a keyword index.
• Thesaurus: This term refers to a guide to synonyms or alternative words to use instead of the one that you know. It's now making its way into the computer vernacular to mean a set of alternative words under which you can try to find the same content. If you search for the word shoe, for example, the computer may use a thesaurus to extend the search to the phrase footwear or even to every kind of shoe (sandal, sneaker, high heel, and so on). I see a thesaurus as simply another kind of index. It maps between one set of words and another.

To me, the central meaning of the word index, and the theme that runs through keywords and thesauruses, is map. An index provides a map between the words and concepts of the seeker and those of the system. The keyword index, for example, is a map between the word that you choose in the list of choices and the Web page that corresponds to it. The thesaurus is a map between the word that you choose and all the other words that you may have chosen if you knew how the system described content.

***

Excerpted from Chapter 26, "Designing Content Access Structures," in the section titled "Indexes."

If you own the CM Bible, click here to go to this section in the Web version of the book.

An audience is a group of people who share common traits and to whom you can communicate in the same way. To become part of an audience (for example, women in their childbearing years), individuals needn't know about each other or care to communicate with other members. An audience is like a neighborhood where each family keeps to itself. Each family is likely to display similar traits (income level, interests, hometown, and so on), but they don't consider themselves really part of the group of people who live near them.

In contrast, communities are like neighborhoods where everyone knows each other. These neighbors share experiences and knowledge, have a lot of cross-communication, and most important, a feel that they're part of the neighborhood. The neighborhood undoubtedly contains meeting places (schools, parks, the grocery store, and so on) where members congregate and share information and advice and feel a part of a larger group.

Online, the same analysis holds. A community site provides a meeting place where members can congregate and share information and advice and feel a part of a larger group. While all sites should communicate to one or more audiences, community sites go further by fostering communication among audience members.

***

Excerpted from Chapter 10, "The Branches of Content Management," in the section titled "What is a community?."

If you own the CM Bible, click here to go to this section in the Web version of the book.

If you prepare a little, your foray into the organization to collect requirements will be much easier. In addition, in the heat of collection, you will be able to refer back to your plan and not have to remember what to do next.

One way to approach this plan is to focus not on the requirements but on the people in the organization from whom you will collect them. My assumption here is that, given the questions I have laid out, you already know enough about the requirements you need to capture. On the other hand, I assume that you need to know more about how to collect them from your colleagues. To work this through, you can create a spreadsheet that lists your requirements contacts. Before you send out any questions, get together with each contact and define the following:

• Which questions will you ask? You might want to number your questions to make it easy to refer to them.
• What kind of turnaround time will you expect on answers?
• What kind of review of your synthesis will she require?
• Who would be the right person to contact to escalate any responses to questions that she is not comfortable answering to someone of more authority?
• Who are the other people who should answer the same questions? You can compare her answers to this question to the people you have targeted to be sure that you have not missed anyone, and that she is aware of the other people you have chosen for each question. It is better not to surprise her later.

With this task complete, you can create a second spreadsheet that focuses on requirements. For each requirement, you can enter the following information:

• The names of the respondents
• The overall turnaround times for responses
• The review process you will use for the requirement
• The arbitration process for conflicts in answers

The second spreadsheet is a plan of attack for gathering requirements.

***

Excerpted from Chapter 15, "Doing Requirements and Logical Design," in the section titled "The requirements plan of attack."

If you own the CM Bible, click here to go to this section in the Web version of the book.

You need an official result of the requirements process to hang next to your project mandate. When the arbitration is finished on the last question, I suggest that you gather the final results into a document and get specific sign-offs from the following people:

• The respondents to the requirements questions
• Your sponsors or their assigned point persons
• Your project team

I believe that it is worth making this much fuss over the requirements document because it is the last of what you will expect the organization to provide to you for a while. As such, you want to make sure it gets full closure and that the signatories know that their chance for major input is now done. In addition, these requirements are your true marching orders. If the mandate is the goal of the war, the requirements are your orders. What is left, of course, is a battle plan.

Be sure to include in your requirements document clear references to the mandate. You want to be sure yourself first, and then communicate to others, that the requirements derive clearly from the mandate. For your own sake, as well as the effect it will have on others, be sure that this is actually true. Later, it may be too late to reconcile those nagging little inconsistencies between the overall goals and means you have chosen to achieve them.

As you might have guessed, my major organizing principle for all content management materials is collect, manage, and publish. To the extent that you can organize your requirements document with these three categories, it will clearly tie into the later deliverables as I describe them. However, you needn't go too far with this. The requirements document is the pivot point between the world of the organization and that of the CMS. The categories content, system, and publications that I presented earlier map very loosely to collect, manage, and publish, but are about half-way between the language of the organization and that of the CMS. They may be a bit clearer to the audience of the requirements document than collect, manage, and publish are.

***

Excerpted from Chapter 15, "Doing Requirements and Logical Design," in the section titled "The requirements document."

If you own the CM Bible, click here to go to this section in the Web version of the book.

Data and content are different, certainly, but that difference doesn't mean that they don't interact. In fact, innumerable transitions from one to the other occur every day. Moreover, from the standpoint of the computer system, content doesn't exist — only data exists. Today, users have few tools for dealing with content as content. Instead, you must treat it as data so that the computer can store, retrieve, and display it.

Consider, for example, a typical Web interaction where you may go to a music site. You browse a page that features a music CD that you like; you add it to your shopping cart and then pay for it. What you experience is a series of composed Web pages with information about music as well as some buttons and other controls that you use to buy it. All in all, the experience feels like a content-rich interaction. What happens behind the scenes, however, is a set of data-oriented computer programs exchanging data with a database.

Some of the data behind the scenes is very content-like. A database stores, for example, the feature article with the artist's picture. The artist's name is in one field, and the text of the article is in another. A third field contains the picture of the artist. Some of the data is very data- like. It consists of numbers and other snippets that create an economic transaction between you and the record company. A database stores your credit card number, your order number, the quantity that you order, and the order price, for example, and uses them in calculations and other algorithms. Some of the data is in-between data and content. The song catalog contains song names, running time, price, and availability, which are all snippets of information that can look a whole lot like data as the site's database stores them, but they appear more like content as the site displays them.

In the database, it's all just data. On the page, the transaction data still looks a little like data; while the feature-article data looks nothing like data, and the catalog data can retain or lose as much of its data appearance as you want. On a well-designed page, however, visitors perceive it all as content.

So, from the user's perspective, information is all content, while from the computer programmer's perspective, it's all data. The trick to content management, in an age when the technology is still data-driven, is to use the data technologies to store and display content.

***

Excerpted from Chapter 1, "Defining Data, Information, and Content," in the section titled "Content Is Not Data."

If you own the CM Bible, click here to go to this section in the Web version of the book.

Content management is important. It can underlie today's most significant digital technologies (including, among others, eCommerce, customer relationship management, personalization, advanced Web sites, and electronic communities). By understanding and properly implementing a CMS, organizations will have laid the groundwork on which the rest of these systems can stand. In so doing, they can save a tremendous amount of time and money and can unite these disparate systems with a single, enduring infrastructure.

This work matters for two additional reasons.

• The field of content management is in its infancy. I believe that this work helps define it. In my work I daily experience the confusion and frustration of people who need to define or implement a content management system for their organization and do not know how to approach it. These people are being bombarded by product-centered white papers and superficial ad-speak that present an all-too-simple picture. In contrast, this work provides a thoroughgoing and impartial framework upon which to base an understanding of the problems and the solutions of content management.
• There is a definite need for the kind of practical knowledge this work provides. The processes and practices that I, along with my colleagues, have developed can be of great use to people who need to implement and staff a content management system. From job descriptions to conversion code samples, you will find a good supply of methodologies, pointers, and insights. This practical knowledge, woven into an overall framework for implementing a content management system, should provide a powerful resource to anyone needing to understand or do content management.

When I began speaking on the subject of content management, my audiences consisted mostly of writers, marketing people, managers, editors, and librarians who were tasked with putting together a large Web site. Most had in-depth knowledge in their respective disciplines and some experience creating Web sites, but little resource for tackling the job they had taken on.

Today, my audiences consist of much the same people, but now they have job titles like Content Manager, Director of e-Business Strategy, and Chief Information Officer. In addition to creating an Internet presence, many are being tasked with developing an entire enterprise system for controlling the creation and dissemination of information. They have bigger titles and greater responsibility but few extra tools to help them meet these new responsibilities.

***

Excerpted from Chapter 0, "Front Matter," in the section titled "Why this Work Matters."

If you own the CM Bible, click here to go to this section in the Web version of the book.

An access structure relates components or publication pages to each other or to an external set of concepts that someone may use to get to a particular component.

The types of access structures are as follows:

• Hierarchies (outlines)
• Indexes (keywords)
• Cross-references (links)
• Sequences (next and previous)

An access structure entity is a set of data about the structure and how you intend to create it. The entity includes the following sorts of data:

• Identification, which is the name, type, and a unique ID for the structure.
• Storage, which describes how and where the structure is contained (in a database table, as a component element, in a text file, and so on).
• Creation and maintenance, which specifies who creates and updates the structure.

***

Excerpted from Chapter 19, "The Wheel of Content Management," in the section titled "Access structures."

If you own the CM Bible, click here to go to this section in the Web version of the book.

Acquisition source entities describe a single kind of preexisting content that feeds into the system. You may tap the source once at startup or consistently over time as the CMS runs. You need to collect the following kinds of information about your acquisition source entities:

• Identification, including a unique ID and name for each source.
• Content, including the number and types of components that the source yields.
• Relationship to the CMS, including the person in charge of the acquisition source, the agreement you reach with her, and the way that you get information from her.
• Conversion, including an analysis of how to distinguish each component within the source and how to locate and tag component elements in the source information.

***

Excerpted from Chapter 19, "The Wheel of Content Management," in the section titled "Acquisition sources."

If you own the CM Bible, click here to go to this section in the Web version of the book.

It's never a good idea to force a CMS on the organization. You are too much in need of the organization's active and creative participation ever to risk that sort of alienation. Rather, you need to figure out how the CMS can bring value to the groups it will encompass. You need to be clearly convinced that the CMS brings value to a group greater than the cost they will bear. Then, you can present your case to the group and hope for the best. Be prepared for groups not to be convinced immediately. They may have a lot of personal and financial investment in the way they do things now. Think as objectively as possible. Is the problem that they just don't want to change? Is it that you have not presented your case well? Or do you just not have a compelling case?

For any of these reasons, you may need to fall back to a looser connection between the CMS and a particular group. There are a number of ways to loosen the connection.

***

Excerpted from Chapter 12, "Working Within the Organization," in the section titled "Exploring Organizational Models."

If you own the CM Bible, click here to go to this section in the Web version of the book.

A CMS becomes integrated into the organization in the following ways:

• It organizes many departments and job types into an overall system.
• It harvests information from throughout the organization.
• It unifies the organization's communications to itself (an intranet site, for example) and the outside world (an Internet site, for example).
• It ties into the organization's existing information management infrastructure.

Quite often, the need for a CMS is felt most acutely by one part of the organization. The group that feels the pain organizes a team to confront the problem. In my travels, I have seen these originating groups:

• A business unit (or department) that needs a much fuller Web site than it now has. The business unit has diverse content and core functionality that it needs to bring to its audiences.
• The organization's corporate communications or editorial, group that finds it cannot keep up with the explosive growth of content that must be created and delivered.
• The organization's IT group that needs to unify all of the divergent requests it receives for Web pages into a single, manageable system.
• The organization's marketing department that wants to both unify the organization's appearance to the world and better target market segments.

If all goes well, the originating group brings in all other groups and they coalesce into a tight team that serves all the groups' needs. More often than not, however, this does not happen. Rather, the originating group avoids the hassle of dealing with other groups' budgets and politics and decides to go it alone. The result is, at best, inefficiency and redundant efforts. At worst, the result is massive infighting and paralysis while the organization decides who owns the effort.

***

Excerpted from Chapter 12, "Working Within the Organization," in the section titled "Content Management and the Organization."

If you own the CM Bible, click here to go to this section in the Web version of the book.

Make sure that you build robust link checking into your system if it's not part of a system that you buy. A robust linking system has the following sorts of functions:

• Authoring: The system should have the capability to author links at the component, element, or text level (as I describe in the section "Cross-References in Relational Databases," earlier in this chapter.
• Structure: The system ought to enable you to pack additional information into a link. In addition to the reference and referent ID, the system ought to enable you to specify link IDs, link types, and any other parameters that you may want to manage and render the link to your specifications.
• Management: The system ought to enable you to find and repair broken links automatically. A broken link can have an internal or external referent. For internal referents, the system ought to alert you if you delete a component that's used as a referent somewhere else. The ideal user interface for this would be some kind of dialog box that lists the titles and IDs of the components that link to the one that you're trying to delete. From this dialog box, you ought to be able to globally change the referent to be a different component or open referring components individually to decide what to do with each link. A much more subtle piece of functionality would be to have your system detect if you change the title (or other significant elements) of a component and ask you whether you want to review links. Often significant content changes to a component invalidate some of the links you've forged to it. For external links, the system must check the link periodically. For links to Web URLs, the system can try to access the URL and see whether it still exists. Of course, this doesn't tell you whether the URL is still appropriate. As an enhancement, the system can try to determine whether the target page has changed since the last access by storing an image of the page linked to and comparing it with the current one. If the current page is different from the last one, the system can trigger a workflow to have someone verify that the page is still valid. If this process can't be automated, the system should be capable of compiling lists periodically and initiating workflow to tell someone that it's time to check the validity of the links manually.
• Rendering: If the system has only one way of rendering links (as HTML <A> tags, for example), you may need to augment it so that it can produce the other sorts of links that you may need. You may, for example, need to write your own extension to create print-format links ("for more information, see . . ." and so on).

***

Excerpted from Chapter 32, "Building Management Systems," in the section titled "Link checking."

If you own the CM Bible, click here to go to this section in the Web version of the book.

Content is information and functionality. And just as an information content component has a class, an instance, and body and management elements, so does a functionality content component.

The kind of functionality that I discuss here is the kind that you want to distribute to your audiences and not the kind that makes up the CMS itself. This published functionality happens mostly, but not entirely, in electronic publications.

You use some of the more common forms of published functionality for the following purposes:

• Connection to other systems: In your Web publications, you may need to connect to a catalog, a transaction, or other non-CMS systems. To do so, you program and package functionality that connects to and exchanges data with the other system.
• Advanced navigation: If simple lists and outlines aren't sufficient to produce the navigation that you need in an electronic publication, you can program and package functionality to present more elaborate navigation areas. You create the popular "fly-out" menus on many Web sites, for example, by using JavaScript functionality that must find its way onto each page that it's a part of.
• Communication: Perhaps the most useful kind of functionality is simply to facilitate communication between the audience and the publisher. Many publications (print and electronic), for example, include a form that you can fill out to subscribe to or order something from inside the publication.

To make your creation, administration, and use of published functionality more efficient and effective, you can treat it as you do other content and pack it inside content components.

***

Excerpted from Chapter 23, "Designing Content Components," in the section titled "The Relationship between Functionality and Components."

If you own the CM Bible, click here to go to this section in the Web version of the book.

The key to finding the right set of audiences is to look within your organization to see how it divides constituents now so that you're sure that you're making the most of what your organization already knows. Find out how your organization communicates with each audience now and what feedback it receives from those audiences.

For each audience, you need to construct the set of personal traits (for example, age, interests, and so on.) that select a person into the audience. These traits later serve as the user profiles on which you can build your personalization module. To most effectively speak to each audience, you must create a set of assumptions about what members like and dislike (for example, what motivates, impresses, and offends them). You should find publications that they know and trust now and make sure that you're providing content that's consistent with their aims. These assumptions give rise to the metadata that you add to your content so that the people who want that content the most can find it and get it delivered to them.

After defining all your audiences, you need to decide how they relate to each other to decide whether simultaneously serving the variety of audiences that you want is possible and to determine the kinds of metadata that most effectively capture the essential needs of each audience.

***

Excerpted from Chapter 21, "Cataloging Audiences," in the section titled "Analyzing Audiences."

If you own the CM Bible, click here to go to this section in the Web version of the book.

Each markup language has a range of the formatting and structural elements that it can represent.

HTML has a particularly low range of coverage. That is, of the world of tags that you may like to have, the HTML language offers relatively few. This makes HTML easy to learn but also easy to grow out of. I remember how gratifying it was to learn the first versions of the HTML tag set in one sitting. I remember, too, how quickly I stopped finding tags that I needed to make my pages work.

Word processors (and desktop publishing programs as well) have substantially more tags than HTML. They need a lot tags to cover the range of needs of professional publishers who may use them. As HTML's continued to develop, it's come ever closer to covering the same mid-range selection of tags that most word processors support. With the extensions offered by Cascading Style Sheets (CSS), HTML can today support a large fraction of the formatting and structure of word processor markup.

The range of coverage of XML, of course, is infinite. It can have any tag that you can dream of - and lots of them. Given that you have the wherewithal to support the tags that you create, you can represent any formatting or structure that you can imagine.

***

Excerpted from Chapter 28, "What Are Content Markup Languages?," in the section titled "Range of coverage."

If you own the CM Bible, click here to go to this section in the Web version of the book.

People talk about the Information Age as a fait accompli. They suppose that because there is a worldwide communication network, we are fully connected. They assume that computer technologies already have turned the world into a constant digital information stream. The coup-de-grace, many contend, is the World Wide Web, which has combined the global network with the latest computer technology to create the first tangible information economy, complete with transactions and stock market value for information assets.

In fact, we are at only the very beginning of the Information Age. The global network connects only a small minority of the world's population at very low speed. Computer-based information is viable only as long as you reduce the enormous complexity of information to the absurd simplicity of data. The World Wide Web proves only that information can be valuable. It has helped frame the issues of an information economy, but it has not begun to really address them. The tentative steps we have made so far prove that there will be an Information Age, not that it is really here. We are no further into our new age than the first cave dweller was in hers when she felled her first wild boar with a stone-tipped spear.

Still, the signs are all around us that the Information Age is coming, and coming quickly. The volume of information that needs to be produced and somehow managed has grown to the level that, without serious planning and organization, the cycle of information creation and use bogs down or simply crashes. For many organizations, this is the key dilemma that drives them toward more sophisticated systems for information management.

***

Excerpted from Chapter IN, "Three Good Reasons to Do Content Management," in the section titled "Content Management in the Information Age ."

If you own the CM Bible, click here to go to this section in the Web version of the book.

For whatever reason, system selection can be a real hassle if you don't put serious effort into reining in all the people who want to decide, as follows:

• Depend on the consensus that you built during the mandate process. If the process didn't yield a list of who gets to decide, you at least should have gotten a group of people with enough authority to help you choose a small but evenly distributed group with no members who've decided before the process starts.
• Ratify a group process before you begin. Make sure that everyone agrees to it and agrees that the winner wins. Too often, I've seen a clear winner emerge in this process, only to be shot down by people who don't like it "for some reason." If they can articulate a reason, it can be added to the list and scored with the rest of the criteria that you use. If they can't articulate why they like or don't like a product, their opinion shouldn't count for much. Don't create process on the spot as you need it. This leads to a lack of respect for the process and rigging by people who can figure out how to manipulate the criteria and scoring.
• Decide on a fair and impartial scoring mechanism for each scoring step that you include in your process. Agree to the range for each scale and agree to what constitutes each value in the range. Then each person can make a judgment in the strict context of the scale and scoring criteria that you established.

• Agree to stick to what your process decides. It helps no one to add up all the scores and then ignore them because they don't come out right.

As far as who should be in the reviewers group is concerned, I can think of two types of people: those who represent a significant organizational interest and those who have the expertise or perspective to judge vendors. Obviously, you should shoot for people who have both qualities. I'd resist people who represent a constituency but have no basis to judge between vendors. As much as someone may want them to serve as a reviewer, they can slow down the process and cause a general lack of respect for the rest of the reviewers from the vendor and the organization.

***

Excerpted from Chapter 16, "Selecting Hardware and Software," in the section titled "How to select decision makers."

If you own the CM Bible, click here to go to this section in the Web version of the book.

I've seen more politics wrapped around the product decision than in any other part of a CMS project. More than once, I've seen a CMS project stall and die because of the following:

• The lack of consensus that you previously could choose to ignore comes out and fouls up the entire process.
• Some groups have their favorites and inside players, others have the tools that they're already using, and yet others have one tool that they've heard of and just want.
• Some people see this as the most significant decision of the project and one where they can have a say.
• Some people see this as a way to influence how large budgets are spent.
• Some people think that, if you make a bad call on the product, the project's doomed, so they put too much emphasis on the process and drag it down.
• Some people just think that they're good at system selection and plug in because they have experience.

All these reasons have some validity and some invalidity. My overall feeling is that selection gets all the attention because it's so tangible and easy to understand. Money is spent and a product is chosen. The other parts of the project are more difficult to get your hands around and not so straightforward.

***

Excerpted from Chapter 16, "Selecting Hardware and Software," in the section titled "How to select decision makers."

If you own the CM Bible, click here to go to this section in the Web version of the book.

To work in the world of the publication, the template must do the following:

• Create the context of the publication: The look and feel of a publication is entirely in the template that creates it. This look and feel includes the colors and overall layout of the publication, the imagery that goes behind and around the content, the branding and titles within the publication, the fonts and other text styles that it uses, and a host of other qualities that, together, give the content of a publication a very particular and meaningful context. In a CMS, this stuff is stored separately from the content of the publication. Most of it you design it into the template. Some of it you can store as separate components in the CMS repository. It's still separate from the content of the publication; you simply use the management functions of the CMS to keep track of it.
• Produce the formatting of the publication: On the Web, this requirement means producing HTML. In print, it may mean any of a number of proprietary markup languages. The template must translate the format-neutral content of the repository to format-rich content in the publication. A simple Sidebar element (which you represent as <SIDEBAR></SIDEBAR> in an XML repository), for example, may give rise to a lengthy and complex set of formatting codes that position the text between the tags in the publication margin and surround it by a box with a drop shadow.
• Produce the structures of the publication: The template must exactly reproduce the structure conventions of the publication. The repository may store a cross-reference structure, for example, simply as an ID that you embed at some point in the text of an element. (In XML, it may look like <XREF ID="1234">.) A print publication template must turn that ID into a recognizable print cross-reference (such as "For more information, see the section 'Some Section,' in Chapter 3").
• Target the audiences of the publication: In the case of personalization, the template must detect audiences and produce publication pages and sections for them. A Web page template for example, may contain code that detects whether a child is accessing pages. The template may then use code that changes the look and feel of the site accordingly and displays only content that you tag as appropriate for children.

Finally, to tie the publication into the worlds of any external systems, templates must do the following:

• Connect: They must have the appropriate programming code for accessing the external system. A credit card transaction system, for example, may require a complex and highly secure logon routine for the template to connect to it at all.
• Query: The template must "know" how to get data out of the external system. The credit card system that I mention in the preceding paragraph, for example, may use the common Structured Query Language (SQL) for data access after the template connects to it.
• Send data back: The template must follow whatever conventions the external system requires for receiving data from the publication. The credit card system, for example, may require that the template send it a transaction data set (product number, amount, company name, and so on) in a text string delimited by commas.

***

Excerpted from Chapter 22, "Designing Publications," in the section titled "Bridging worlds."

If you own the CM Bible, click here to go to this section in the Web version of the book.

To work in the world of the repository, the template must do the following:

• Query the CMS repository: The most fundamental thing that a template does is to draw content out of the CMS repository. To get at content, the template must make a query against the repository and receive the results. The query that you type in a template may or may not look like a database query (because sometimes the query is implicit in another command you type), but the result is the same. You make a query against the repository and the components or other data that match the query pass to the template for further processing.
• Use the content schema: In some way, the template must be aware of the kinds of content components that the repository contains and what their elements are. Suppose, for example, that a publication page calls for creating a table where each row is a competitor (a kind of component) and each column contains information about the competitor (component elements such as name, address, product focus, and so on). To accomplish this table, the template that builds it must know the names of both the component and of all the elements that it needs to list.
• Use the access structures: To build the navigation of a publication, a template must get to and work with the access structures that the CMS repository stores. Suppose, for example, that a TOC table in the CMS repository database has ID, Title, Level, and Order as its columns. To use this table to create a table of contents for a publication, the template must access and query this table, but it must also know how to turn the data ID, Title, Level, and Order into the visual representation of the table of contents outline. On a Web site, the template may need to create an expanding and collapsing outline where the Level and the Order data control the indentation and order and the Title and ID turn into a link (<A href="ID">Title</a>). In print, the Level data may turn into a paragraph style, and the template may use the ID to somehow calculate a page number to insert (not an easy task). In all cases, the template must be aware of how access structures are stored and what meaning to attach to each element of the access structure.
• Store data: The template must send back user requests and data in a format that the CMS can understand. A template may, for example, have the responsibility of gathering up the responses that a user makes to a series of questions and storing them in the CMS user profile table. To do so, the template must know how to access the user profile table in the CMS and store data there in the appropriate way.
• Call the CMS services: In addition to working with the data that the CMS stores, a template may need to use any of a range of functions and commands that a CMS provides. The CMS may, for example, include a personalization engine that runs on a Web site and has special commands for use in a template. The template must be capable of using these commands and also of using whatever data or content the personalization system passes back in response to the command.

***

Excerpted from Chapter 22, "Designing Publications," in the section titled "Bridging worlds."

If you own the CM Bible, click here to go to this section in the Web version of the book.

What will finally push us into the heart of the Information Age, I believe, is the information itself. When it is as easy to put a value on a small chunk of information as it is to put a price on a manufactured good, the Information Age will really be here.

The quantity of information to be handled drives us forward, but what really heralds the new Information Age is qualitative, not quantitative. The most important signs are the more subtle, qualitative ways in which our notions of information are changing, as follows:

• Information is gaining value. Traditionally considered to be a necessary evil on the way to their true goals, organizations are slowly bestowing upon information the status of an asset, not a burden.
• Individual works are being subsumed by wider information webs. Information is beginning to coalesce across creators, organizations, disciplines, and industries. We are beginning to ask authors not to create a stand-alone work but rather to contribute to an existing content domain. Creators are beginning to contribute to overall repositories of reusable information, where their work is related to and cross-referenced with other contributions to produce a growing web of content.
• Information publication is disengaging from creation. The way information is consumed is beginning to be unlinked from the way it is created. How a particular piece of information is formatted, delivered, and connected to other pieces of information can now effectively be varied and changed, based on the needs of the consumers. Thus, an author may not know how or when her work will be delivered.

In the heart of the Information Age, the exact value of the information you create will be known. In addition, each piece of information will contribute specifically to some very large and very rapidly expanding schema of content. Finally, consumers will simply expect that the information they receive is delivered in the way that is most convenient and useful to them — and they will gladly pay for it.

***

Excerpted from Chapter IN, "Three Good Reasons to Do Content Management," in the section titled "Content Management in the Information Age ."

If you own the CM Bible, click here to go to this section in the Web version of the book.

From manufacturing and finance, computers moved to the business desktop as the replacement for the typewriter and the paper-based spreadsheet. Then, three related developments occurred in the personal-computer industry. Together, the following breakthroughs set the stage for a major change in our expectations of what computers can, and are, to do:

• Digital media creation (images, sounds and video) became possible.
• Digital media output (color displays, sound cards, and video accelerators) became available.
• Consumer-oriented mass removable storage (CD-ROMs, in other words) became available and cheap.

These developments led to the meteoric rise of the multimedia industry. For the first time, you could create and cheaply deliver actual information and not just data. Soon, multimedia CD-ROMs proliferated, with everything from encyclopedias to full-motion games. You can now consider your computer an actual replacement for familiar information channels such as books, TV, and radio. What these traditional channels deliver is content and not data.

What the multimedia industry began, the Web is in the process of completing. Today, getting your content online isn't only possible, but it's often preferable to obtaining it in any other way. I now listen to more music and talk on my laptop computer and Personal Digital Assistant (PDA) than I do on my radio or stereo. Still, I'm usually frustrated whenever I go to the Web because I expect to quickly locate the content that I want and see it presented at least as well as in the traditional channels. Unfortunately, that's not always what happens.

Although users' needs and expectations changed, the guts of the computer didn't. Ten years ago, people came to computers to input, process, and output data. Today, most people come to find and consume content. At the base of all computer technology, however, is still the idea that you can reduce any problem to a set of simple instructions working on discrete and structured snippets.

***

Excerpted from Chapter 1, "Defining Data, Information, and Content," in the section titled "Content Is Not Data."

If you own the CM Bible, click here to go to this section in the Web version of the book.

E-business is not a set of static outputs but rather a dynamic "best fit" of your practices to the environment inside and outside your organization. Because the technology is continually shifting, it is not possible to stand still. Because your organization, its audiences, information, and business practice are constantly shifting, you had better not stand still.

The technologies behind e-business are new and will change. Applications for customer relationship management, campaign management, self-service procurement, vendor relations, automated fulfillment, and a host of others are barely out of their first versions. In addition, the underlying infrastructure on Web servers is also in flux. Finally, new delivery platforms (such as Web-enabled phones) are appearing all the time. What you can do is changing so rapidly that you have no choice but to consider e-business a process that is never complete.

To do e-business, you create a system for production, not a particular product. You focus more on how you will constantly readjust to the changing landscape of technology, your audiences, information, practices, and publications than on any particular configuration that you might happen to be in right now.

***

Excerpted from Chapter IN, "Three Good Reasons to Do Content Management," in the section titled "The process of doing business ."

If you own the CM Bible, click here to go to this section in the Web version of the book.

To start the selection process, it's useful to create a short project overview that you can include in early correspondence with the vendors. The overview also should orient your selection committee to the major points toward which you're aiming.

To create the overview, take the high points from your project mandate, requirements, and logical analysis. Here's a sample overview:

Our company is seeking to implement an enterprise-level content management system that aids in the creation, management, and publishing of personalized content to the Web and beyond. At the highest level, the system is successful if it does the following:

• Provides a solid framework behind the staff and processes involved in creating and tagging content.
• Supports a wide and diverse contributor base with tools and processes appropriate to skill level and commitment.
• Provides a full-featured repository where content components and file-based resources can be stored, tracked, updated, targeted, combined, and archived.
• Provides a flexible, template-driven publishing capability that can format and output any combination of content and file resources to standard databases and file formats (including XML, HTML, flat text for e-mail messages, and QuarkXPress for print output).
• Provides strong, easy-to-use workflow tools that can guide the entire creation, storage, and publishing process.
• Supports a robust publishing, testing, and deployment environment.
• Provides a full-featured but extendable personalization capability for targeting and custom publishing of content.
• Integrates with our existing internal systems and current Web infrastructure.

The product or products selected are successful if they do the following:

• Have "out-of-the-box" functionality capable of covering a wide range of the preceding requirements with minimal customization.
• Have standards-based customization and extension capabilities that enable full integration with existing systems and rapid development of additional functionality."

***

Excerpted from Chapter 16, "Selecting Hardware and Software," in the section titled "A high-level overview."

If you own the CM Bible, click here to go to this section in the Web version of the book.

In publication design, you define and prototype the pages of the publications the CMS will be called upon to produce. The goal of publication design is to create the most compelling publications possible that can still be efficiently produced from the CMS. Ideally, publication design should begin at the same time, or even before, you begin collection and management design. Collection and management design ensure that a viable system can be created behind the publications, and publication design ensures that the system produces compelling output.

The deliverables from the publication design process can be a large number of files rather than the few files that result from a collection or management design process. These deliverables include the following:

• A publication strategy document, which specifies how you will deal with your publications in general
• Page design files, which define, at increasing levels of detail, how the pages will look and be built
• Personalization strategy documents that show how you intend to target and deliver personalized content
• A publication administration document that details who will be needed to create publication on a start-up and run basis, what tasks they will have to accomplish, and how frequently they will have to accomplish them

***

Excerpted from Chapter 15, "Doing Requirements and Logical Design," in the section titled "The publication design documents."

If you own the CM Bible, click here to go to this section in the Web version of the book.

To give you a feeling for who in your organization should be most focused on XML, here are the kinds of tasks that an XML system requires and some comments on the best sorts of people to do them. I've arranged the tasks from least to most technical, as follows:

• Authoring: You can take two approaches to authoring XML. You can convert the author's output to XML, or you can try to get your authors to create content inside an XML authoring environment. The first option is what's usually taken today. To do so, you try to get as much of the DTD structure as you can into the author's native environment. You may use style sheets, templates, and macros in Microsoft Word, for example, to try to get authors to create Word files with as much of the rigor of XML as you can manage to simulate in that unstructured environment. The second option, using an XML authoring tool, isn't as far out as you may think. Having created this work entirely in one such environment, I can say that, although it's not nearly as friendly as Word, it's getting there. With enough effort, I could make this tool (XMetaL by SoftQuad, at www.softquad.com) workable for nontechnical end users. In the future, I'm sure that this tool and others will advance to the point at which it's not so much effort on your part to bring XML authoring to nontechnical contributors.
• Rule creation: Someone must create the logic and structure that your XML files implement. This structure is what I've called the content model. It includes all the component classes, their elements, and the access structures that they participate in. In my scheme of CMS jobs, the Content Analyst is clearly the person to do this work.
• DTD creation: Someone must design and code the DTDs or schemas that you use. Although this task often falls to programmers, I believe that it's better left to the Content Analyst. If this person isn't up to the challenge of mastering the tools and syntax of DTDs and schemas, you have the wrong person in the position or your analyst hasn't yet realized that these technologies are simply a very formal way of writing down the sort of rules that she's been defining all along.
• XSLT: XSLT files are programs. Contrary to some of the claims that I've heard made about XSLT, it's hard for me to imagine anyone but a trained programmer (or someone who wants to become the equivalent of one) able to create more than simple XSLT templates. In my job scheme, it's the template programmer who's best targeted to XSLT. XSLT is a bit behind many of the more graphical and ease-oriented languages in use today; if you can't find someone with experience in XSLT, look for someone who has a lot of patience and doesn't mind the lack of an integrated development environment. Also, as with all template programmers, an XSLT programmer needs to be conscious of and interact well with the needs of the designers with whom she shares her template files.
• Tool automation: If you release an XML authoring environment to your nontechnical contributors, you need someone to program it so that it implements your DTDs and has the kind of user interface that the contributors expect and understand. This programming likely includes CSS, XSLT, some sort of scripting, DOM programming, and distribution programs (setup programs and the like). It may also include integration programming with the author's other tools. The custom application developer in my framework ought to do well in this position as long as she's comfortable with the XML programming tasks.
• Conversion programming: If you intend to convert the output of authoring tools to XML or convert acquired content to XML, you need conversion programming done. In my scheme, it's the conversion analysis and the tool creator who'd most qualify for this sort of task.
• Custom template programming: If XSLT isn't suited to the needs of your CMS, you need to develop other programs to produce your publications. XSLT, for example, may not help you much on any non-HTML publications. In addition, if your template programmers revolt against XSLT, you may need to forgo it for more standard techniques. By using the XML DOM, programmers can do most of or all the operations of XSLT in any standard programming environment. In any case, you want to use the equivalent of an advanced template programmer or custom application developer for the task of going beyond XSLT.
• Management programming: If you store your content in an XML repository, you need programming to ensure that the content there can be managed correctly. You may need a program written that goes through the repository periodically, for example, and archives any components whose expiration date has been reached. In addition, you may need any number of programs written that connect to the repository, convert data to XML, and import the data per the DTD into your repository. These activities may require your most advanced programmers, who not only have a mastery of external systems, but also of XML programming using the DOM .

If your CMS uses XML extensively, XML skills may be distributed throughout your staff. Even staff who aren't called on directly to create XML can benefit from learning its major concepts. A metator, for example, may never directly create XML but could still really benefit from the ability to read and understand an XML file where the metadata that she creates in Web forms is stored.

***

Excerpted from Chapter 29, "XML and Content Management," in the section titled "Who needs to know XML?."

If you own the CM Bible, click here to go to this section in the Web version of the book.

Computers were first conceived as a way to perform computations that were too time-consuming or complex for humans. The model was (and to a large extent still is) as follows: If you can reduce a problem to a series of simple mechanical operations on numbers and logical entities (entities that are either true or false), it is amenable to solution by a computer

Computer professionals were either programmers or data input clerks. Programmers reduced problems to a series of mechanical operations according to the following simple maxim:

You input data; the computer processes it and then outputs it in a more useful form.

Clerks took care of inputting the data. They sat in long rows and columns, typing long rows and columns of numbers as well as small phrases, such as first name/last name and street address. As time moved on, computer scientists invented databases (bases of data) to organize and hold vast quantities of these snippets.

As you may expect, some problems were better solved this way than others were. Thus, as computer technology developed, the use of computers moved naturally from science to manufacturing and finance, where numbers were still the main event. Today, of course, computers are in everything. But the part of everything that computers are in is the reducible part. The reducible part is the part where a finite set of very specific rules operating on numbers and logical entities can yield a useful result.

The idea of computers as data-processing machines runs deep and continues to this day as the main thing that computers do. On the other hand, everyone knows that most users want computers to do more than grind finely through mountains of snippets. Today, people want computers to sift through mountains of large, complete chunks (not snippets) of information and deliver the ones that they want most at that moment. In addition, people want computers to deliver information of the quality that they expect from more familiar sources of information, such as books, radio, TV, and film.

***

Excerpted from Chapter 1, "Defining Data, Information, and Content," in the section titled "Content Is Not Data."

If you own the CM Bible, click here to go to this section in the Web version of the book.

In a nutshell, e-business is the process of delivering any part of your business to any audience wherever it is. E-business does not change the basis of business, but it does change the practice of doing business. In particular, e-business brings a quantitative change in the following aspects of business:

• Ubiquity: Parts of your business can appear on any computer screen anywhere there is connectivity. Time and space are no longer barriers to conducting business.
• Depth: You can deliver as much detail and background as you can manage to create in a convenient and easy-to-consume fashion. Rather than racks full of catalogs and technical documentation, a simple URL is all that is needed to fully detail your organization's offerings.
• Speed: The slowness of your human processes is the only necessary delay between the creation of information and its general availability. Second-by-second changes to information are now possible and entirely practical.
• Personalization: Your ability to understand and serve your audiences is the only impediment to tailoring messages and offerings that are as individualized as you want them to be.

***

Excerpted from Chapter IN, "Three Good Reasons to Do Content Management," in the section titled "What is e-business?."

If you own the CM Bible, click here to go to this section in the Web version of the book.

In the end, you will have to be very specific about the information you include in your CMS. To start, however, you can cast a much wider net and find out what kinds of information are out there in the organization and what sorts of information people are assuming will be included. As with audience information, it is unlikely that anyone has created the definitive guide (eventually, you will), but there should be an enormous amount of raw material in the organization. Rather than trying to amass the whole bulk of information that might be included, focus on collecting representative samples and any catalogs that might exist. Catalogs can be anything from official content inventories to the TOCs and indexes of existing publications to a listing of the files in a directory.

Without a CMS, content and publications are pretty much the same thing. That is, the publications contain the content that you will collect and manage. A group creating industry analyses now, for example, will be creating the content and simultaneously publishing it (as, say, printed white papers).

Just as important as creating a general content inventory is discovering the structure and attitudes of the content groups. What staff and workflow do they use now? Do they use any automation systems, templates, or style sheets? What kind of standards do they adhere to? Is there an editorial guide? What are their assumptions about their audiences? How do these groups feel about the idea of a CMS? Do they understand it? Do they support it? How do they think it will affect their jobs? This sort of information will be crucial to you later as you develop an approach to implementing the system.

***

Excerpted from Chapter 13, "Getting Ready for a CMS," in the section titled "Content assumptions."

If you own the CM Bible, click here to go to this section in the Web version of the book.

The core tasks of the project team show directly the skills the team needs to have in order to succeed. The following list overviews these skills which you will need to have in at least one member of your team:

• Analyze and assess your organization. For this task, you need a business analyst. This person is responsible for answering questions like, What groups need to be involved? Whom do I contact to get permission to...? Who are the key supporters we need to have on our side? Who needs what education? How do we maneuver through the organization's bureaucracy? How will we build consensus around a mandate? How do we align and extend organizational goals? How do we measure success? Someone from management is a logical choice for this job, but it must be someone who can manage "up" and not down. It must also be someone who is quite analytic and strategic in her approach.
• Understand your audiences. You need an audience analyst. This person is responsible for figuring out who the appropriate audiences are, what they want, what you want from them, how finely to divide them, what good analyses exist in the organization, how to align your system to current marketing approaches, what data you need to collect on audience members, and how to collect it. Someone from marketing or public relations is a logical choice for this job, but it must be someone who is less focused on campaigns and more focused on analysis. Someone from an editorial background is also a possibility, but in this case, you need to be sure the person is comfortable being quite quantitative in her approach to audience analysis.
• Understand the publications that your organization will be creating from the system. Thus, you need a publication analyst. Even if your first plan is only to create a Web site, you should still have your eyes open for the ways in which the Web site needs to share with other publication efforts. This person is responsible for finding out what publications exist now, how they share information, how they are produced, how often they are produced, what their audiences are, how they are distributed, and how they can be deconstructed into pieces that a CMS can produce and coalesce. Someone from the current Web effort, or another major publication group, is a logical choice for this job, but that person must be able to climb out of the publication she has been creating and look beyond the particulars of a publication, to how publications in general can be created.
• Understand the content that the system will manage. This task requires a content analyst. This person is responsible for finding out what kinds of content you have, what you need, how it serves audiences and publications, how it can be divided into content classes, how each class can be reduced to a set of content elements, and how those elements can be fashioned into a metadata framework for tagging content. She is responsible for understanding how information is produced in the organization and where it can be found. She will assess the amount of work it will take to write or acquire content and how much will be needed to start and run the system. Someone from an editorial background is a logical choice for this job, but it must be someone who is less focused on creative writing and more on mechanics. Someone with a library background is another good choice, but the librarian must be able to understand the creation process as well as the cataloging process.
• Understand the computer infrastructure upon which the system will run. You therefore need a technology analyst. This person is responsible for understanding all of the systems in the organization that will interact with the CMS. She is also responsible for understanding any constraints or technical requirements the organization might have. Later, she will be central in the selection of any new hardware or software you will need to build the system. She must be able to understand and piece together every piece of technology used, from the first authoring application to the final piece of JavaScript in an end user's browser. Someone from a development or IT systems background is a logical choice for this job, but she must have a head for content as well as data. A technologist who is comfortable ignoring the human parts of the system will not do.

***

Excerpted from Chapter 13, "Getting Ready for a CMS," in the section titled "Start with the project team."

If you own the CM Bible, click here to go to this section in the Web version of the book.

A good way to begin any conversations when examining your organization's CMS needs is to ask what information problems the person is facing. If you ask (and even if you don't), you probably will hear a plethora of issues, dilemmas, worries, and horror stories that surround the core issues of content management. Certainly, if you do not hear a lot of woe, you should question the need for a CMS! Be sensitive not only to the types of problems, but also to the actual stories that people tell. These stories will come in very handy when educating the organization, bring a measure of "ground truth" to the abstract discussions you will find yourself in, and keep your team on track toward solving the problems that are most pressing. As you hear these stories, do the following:

• Record and categorize them. Distribute them freely to let everyone know where the problems are.
• Try to find the common themes. These are the major issues for your organization to resolve.

Try to rate the severity of the problems. See if you can put some numbers around the comments you hear, especially concerning the problems of a lot of information, slowness of the system, people complaining, and unsatisfied customers.

***

Excerpted from Chapter 13, "Getting Ready for a CMS," in the section titled "Look for pain in the organization."

If you own the CM Bible, click here to go to this section in the Web version of the book.

Your content domain is the scope or range of content that you care to collect, manage, and publish. In short, it's the type of content that you need to manage. I use the concept of the content domain to capture the idea of bringing together disparate content chunks into a unified system.

The content domain is a good one if it does the following:

• Differentiates: The content domain should enable you to make crisp decisions about any piece of content that you're presented with. Does it belong or not?
• Clarifies: Knowing your domain, your range of content should be immediately understandable to potential content contributors and anyone else associated with the project.
• Confines: Your domain shouldn't be too wide for you to adequately cover nor too narrow to adequately drive the publications that you need to create.

A content domain is a statement that sums up the domain that you choose. The right domain statement is no more than a few sentences. If someone hears it, that person can immediately imagine what's part of the content and what's not. If you recite it, you know immediately whether a piece of content is of interest to you.

***

Excerpted from Chapter 26, "Designing Content Access Structures," in the section titled "The content domain."

If you own the CM Bible, click here to go to this section in the Web version of the book.

At the point that you begin implementation, reality sets in. You become all too aware of the magnitude of the collection effort, the system setup, and system integration, plus the complexity of the publications that you want to produce. As this happens, be prepared.

You inevitably plan a bigger project than you can really do. If you know that this stage is coming, you needn't panic and run from the entire endeavor, and you needn't stiffen your upper lip and agree to do it all.

The attitude that I believe serves you best is that the requirements and design stages defined the foreseeable goals for the organization and that the implementation and roll-out stages define what's immediately doable for the organization. Interestingly, this attitude both closes down and opens up the project, as follows:

• Just because something isn't immediately doable doesn't mean that it can't be done. The only question is when. The parts of the design that can't be done in the first version of your CMS are the starting points for the second version.
• Just because something wasn't foreseen in the design doesn't mean that the organization doesn't want to do it. The design process itself needs to continue. As you move into implementation, and especially as you begin to use the system, new content, system features, and publications become apparent.

Cutting back, then, is not only necessary at implementation time, but it's also just a part of the ongoing design process.

***

Excerpted from Chapter 17, "Implementing the System," in the section titled "Cutting back."

If you own the CM Bible, click here to go to this section in the Web version of the book.

Over the years during which I've been building electronic publication systems, I've hit again and again on the problem of metadata. At first, I didn't think of metadata as a problem unto itself. Rather, I confronted related issues such as, "How do I know what content is ready for an audience to see?" or, more widely, "How do I pack a bunch of data in with the content, knowing that this data isn't going to appear but that I need it to manage the production and display of the content?" Over time, I began to standardize the ways that I dealt with this "bunch of data" so that it became easier and easier to find, parse, and manipulate. For some time, I used a "dot" system, where each line of the file that I needed to process began with a period and the name of the data field. The systems of standardized tagging that I was working with made isolating metadata from the information it surrounded and doing what I needed to do with it (usually find it and load it into database fields) easy. At about the same time (I would guess about 1996), the term metadata became fashionable in the electronic publications arena as a way to describe "data about data."

As is apt to happen, over time I began to notice some patterns, as the following list describes:

• Metadata consistently fell into a few distinct categories. These categories include navigational (TOC, index, cross reference, and browse), management (author, create date, last edit, and so on.), content type (what I now call components), internal structure (title, abstract, body, and so on), and inclusion (add media here, add a banner here, add standard text here, and so on.).
• Without a rigorous consistency and careful attention, metadata becomes useless. What good is sometimes including a chunk of standard text and sometimes typing it in from scratch? How useful is a TOC if every submitter has a different notion of how organize content and where it belongs? (You can guarantee that every submitter's own content always comes out on top!) Someone or, better, some system is necessary to ensure that people handle metadata thoroughly and consistently.
• A different set of skills is necessary to deal with this metadata. Authors, who are, generally, subject-matter experts and not experts at the system for managing their expertise, are often unable to add this extra data. One very fundamental piece of metadata, for example, concerns where, in the overall outline of content, a particular piece of information belongs? In larger systems, authors who have no problem creating content often don't know enough to decide where to put it. The problem is worse for cross-references. Authors rarely have the wherewithal to discover what else others are submitting and exactly how to relate it to what they submit. Overall, you need a type of person who's a cross between an editor, a librarian, and a database administrator to do a good job creating and maintaining metadata.
• To do metadata well requires a lot of human energy. Simply writing some scripts and pulling out what's easy to find isn't sufficient. A perfect example of this idea is keywording. I've seen many systems fail miserably at indexing because people thought that all they needed to do was create a program to find and mark every example of a small set of words and phrases.

With all these patterns in my head and with clients becoming ever larger and more demanding about the quality of their publications, I became creative. What's needed, I reasoned, is something like an editorial framework for metadata. It needed the right kind of leader (such as an editor), an overall metadata framework that everyone can buy into and apply, and a set of rigorous metadata guidelines (such as an editorial guide) and a metadata process that everyone must follow (such as an editorial process). Thus the metator, the metatorial guide, and metatorial processing were born.

As much as I like coining words, I recognize that it isn't the particular names that you choose that matter. Rather, it's the fact that you name a thing at all that's important. The most important thing for me in coming to these names was that doing so gave me a reason and a way to begin thinking about metadata systems as separate entities. Metadata became, for me, not just a part of gathering and tagging content but a subject of concern and importance on its own and apart from any particular content management process. For me, this turn represented a critical change from doing content management systems to understanding them.

***

Excerpted from Chapter 20, "Working with Metadata," in the section titled "What does metatorial mean?."

If you own the CM Bible, click here to go to this section in the Web version of the book.

Before jumping into the aspects of XML that are pivotal to content management, let me spend a moment on a very important aspect of XML that's not pivotal to content management (at least not directly). XML is often discussed as the coming data interchange format for data transfer between computer applications.

There's a vast tower of Babel in the computer systems world. Each applications speaks its own data representation and transfer languages that other applications may or may not understand. XML has begun to provide a lingua franca for all applications. In the past, every company that created a product also created its own scheme for storing and transferring data. (In lieu of any global standard, what else could they do?) XML is, or at least is becoming, that global standard. Now companies can give their products the capability to send and receive data in XML with the knowledge that other applications are doing the same. In the past, it's taken tremendous repeated effort to make various enterprise applications (financial, ERP, operational applications, and the like) talk to each other. And although XML doesn't help you decide what two applications need to say to each other, it does give you the tools to make the conversation that you want to happen possible.

If the Internet's proved one thing, it's that every computer that can be connected to all others will be. After two applications become connected these days, it's likely that XML has some part in how they communicate. I focus very little on the data interchange uses of XML because it plays a far less critical role in content management than does the role XML plays in representing and storing content and metadata.

***

Excerpted from Chapter 29, "XML and Content Management," in the section titled "XML and data interchange."

If you own the CM Bible, click here to go to this section in the Web version of the book.

As a content manager, XML should be very important to you. Within the world of markup languages, XML is a good one. It has the advantage of being open and easily read. It's taken some strong lessons from its "also ran" parent SGML and its superficial cousin HTML. It represents structure, which endures long after format has faded, and naturally encodes the hierarchical relationships that often categorize content.

Best of all, XML is accepted by the Web community as the markup language of choice. Company after company has dropped the pretense that their language is "the one" and have instead rallied around XML. Today's poor XML tools are already being eclipsed by coming killer applications. XML may be one of the first standard markup languages that actually gets accepted as a standard. XML may be most important not for its superior functionality or for its style and sizzle but for the fact that it's a content standard that may stick.

***

Excerpted from Chapter 29, "XML and Content Management," in the section titled "What Is XML?."

If you own the CM Bible, click here to go to this section in the Web version of the book.

You need a CMS if you have too much content to process by hand. Although the concepts of content management can help you with even small projects, until you have a big system, you can't realize enough cost savings to justify the effort that constructing a solid CMS involves.

What is a "big" system? A big system is one that's too big to fit in one person's head. Say, for example, that, in the past, you counted on your Webmaster to simply know what content's on your site and where it all goes. Maybe you recently started to notice that she can no longer keep up with the influx of information and can no longer quickly assess and place new information on your site. You may now need a system to help the Webmaster (or, at least, some other people to help). In particular, a big system has the following characteristics:

• A lot of content: Based on my experience, by the time that a Web site reaches 1,000 pages, it's clearly too big for anyone to manage informally. This number, however, is far from standard. You must view the sheer size of the content base in the context of all the other factors that I list here to finally decide whether your situation warrants a CMS. And, although pages make up the usual unit of site size, the number of content components on your site is a better measure of the size of the content base than is the number of pages.
• A lot of content types: A content base of 1,000 components, all of the same type, is obviously easier to manage than a base of 1,000 components of five different types. For each component type, you must invent, implement, and oversee a corresponding collection, management, and publishing process. The more types that you have, the harder this task becomes to accomplish without help.

***

Excerpted from Chapter 8, "Knowing When You Need a CMS," in the section titled "Gauging the Amount of Content."

If you own the CM Bible, click here to go to this section in the Web version of the book.

The best way to capture the mechanics of content is to go right to the core conversion issue. How do you find information of interest in source content and map it to components and elements in the target CMS? Your ability to map hinges on the amount of correspondence that you can find between the format and structure of the source and that of the target. There are only a few ways that the source and target can correspond.

Both source and target can correspond as follows:

• Directly: There's exactly the same format or structural element in both.
• Indirectly: There's some way to infer the target format or structural element from clues in the source automatically.
• Ambiguously: There's more than one target element that the source element may give rise to.

If the source and target correspond poorly or not at all, the reason may be as follows:

• No format or structure: There's no format or structural element in the target components that corresponds to a source element. A person must add the additional elements to the target.
• No markup: Certain target elements exist in the source but are unmarked or inconsistently marked. Mapping depends on the judgment of a person.

***

Excerpted from Chapter 30, "Processing Content," in the section titled "Understanding the principles of mapping content."

If you own the CM Bible, click here to go to this section in the Web version of the book.

Components divide your information into convenient and manageable chunks. You create content components to establish a set of content objects that you can create, maintain, and distribute. Each component travels through your CMS as a unit, as the following list describes:

• Whenever you create new content, you do so one whole component at a time. Authors, for example, don't just free-associate and type whatever they please. Rather, they create a particular usable chunk (a backgrounder, a news article, an employee profile, and so on.)
• Whenever you move existing content into your system, you do so by dividing it into components. If you find a hard drive full of useful information, for example, you start by categorizing it into types. You then ensure that each piece of content of a certain type has the same format and structure. In other words, you establish a set of component types and use them to create a set of components.
• Whenever you store content, you do so by component.
• Whenever you archive or delete content, you do so by components. After an event passes, for example, you may delete the Event component from your system.
• Whenever you create a publication page, you do so by pulling components together into a page template. You may construct an Event page on your Web site, for example, by pulling an Event component into a page template that formats the event information and surrounds it with banners, navigation and site buttons, and images.
• Whenever you gather statistics, you gather them by component. You may want to know what the most visited component is, for example, how many of a particular type you created in the last month, or how many are stuck in legal review.

Most Webmasters count Web pages. Most authors count pages of text or number of images. Administrators count database records. None of these measures has any universal meaning. On the other hand, a component has meaning regardless of the stage of the system you're working in or what your job is. Regardless of stage or job, you're always trying to move the right set of content components from creation to distribution to eventual retirement.

***

Excerpted from Chapter 23, "Designing Content Components," in the section titled "The basic unit of content management."

If you own the CM Bible, click here to go to this section in the Web version of the book.

As much as possible, your collection ought to reach into the contributors' authoring tools to make it as easy as possible to submit content. Reaching into someone's authoring tool means having the CMS appear to be part of the tool. Here are some of the ways that you may reach into an authoring tool:

• Spawning applications: As I mention in the earlier discussion on Web-based forms, some systems launch (or spawn, as it's called) authoring tools that enable you to create and edit component elements outside the CMS. In the simplest form of spawning, the CMS starts the authoring tool, and it's up to you to copy text into the application and then back into the CMS form. In better implementations, the CMS opens the authoring tool and copies in the text to be edited. After you close the application, the CMS copies the edited text back into the form that you started from automatically. This is more a process of linking to the author's chosen tool than really integrating into it.
• Integrated open and save: For the CMS to spawn an authoring application, the user must start from a CMS form or some other part of the CMS. From the author's standpoint, it's usually better to start from the chosen authoring tool and then call the CMS instead. This effectively turns the tables on the CMS. The author does her work from her chosen tool and accesses the CMS instead of working from the CMS and accessing her tool. The simplest way to achieve this sort of integration is to have the CMS control the Open and Save command of the application. The CMS may, for example, add two extra commands to the File menu (present in the typical Microsoft Windows authoring tool): Open From Repository and Save To Repository. The new Open command displays a dialog box that you (or your CMS) created. In fact, this dialog box may be little different from the component selector that I describe earlier. It contains an interface to all the access structures in the CMS repository. The user can navigate to the component that she wants to work on. The CMS can then take care of loading the component into the tool for editing. Similarly, the new Save command can enable the user to return a component to the repository directly from her chosen application.
• Integrated-input templating: Adding an Open and Save command as I outline here effectively changes an authoring tool into an extension of the CMS. The two features, as I describe them, however, aren't sufficient to tie the two applications together. To complete the link, the CMS must have some way to project the rules of each component class into the authoring tool. I term the capability of a CMS to project rules in this way integrated-inputtemplating. In some way, the CMS must create an input template in the authoring tool. An input template is usually associated with a Web-based form. There, it lays out the component elements that must be entered as a set of HTML form fields. It formats the fields (filling list fields with allowed values, pattern fields with the allowed patterns, and so on) and arranges all the fields on a form that's understandable and usable by the author. To integrate into an authoring tool, the CMS needs to do the same work in the context of the authoring tool. This can be a difficult but possible task. Essentially, the integration that you create must use whatever templating capabilities that the chosen tool supports to represent the various kinds of element fields and validate the results. In Microsoft Word, for example, there's a templating system that you access through document templates (Word's DOT files). The templating system consists of styles, standard text, Word's own input field system (with buttons, text boxes, and the like), and any amount of programming code that you care to write to augment the built-in features. There are ample capabilities in the Word templating system to enable you to create a structured input system for most component classes that you may want to create. It may require a fair amount of programming code, but it can usually be done. So, in addition to the Open and Save commands that a CMS may add to an authoring tool, it should also add a New Component command that enables the author to choose a component class and then be guided in her entry of the elements of that class.
• Integrated check in and check out: To increase the usefulness of the Open and Save commands that you may add to the authoring tool, these two commands ought to be connected to the CMS's access and versioning system. In other words, a user with no access right