The design and organization of information is a key factor in creating a unified content strategy. But without a capable delivery engine, a unified content strategy is just an exercise in data collection. To turn your data into usable content, you must assemble it, format it, and deliver it to your user community, whenever and however they need it.
Delivery systems have many different capabilities. The content management system may have built-in facilities for delivering content, or you may have to integrate a delivery system with your content management system. Some delivery systems will enable you to deliver to a variety of outputs (such as web, HTML, or PDF), whereas others may be restricted to a single output.
Some delivery mechanisms reside on users’ desktops; others are server-based and are available to everyone. Some delivery systems can interface with content management systems, web servers, portal servers, and other systems. This chapter describes the range in capabilities of delivery systems, including considerations to guide you in figuring out what you need your delivery system to do.
To determine the type of delivery system you need, you must first understand the range of capabilities available in current products. Products may have all or some of the following capabilities:
Aggregation
Transformation
Conversion
Distribution and output management
Assembly
Automation
You need to ask the correct questions when you are selecting a delivery system that will meet the needs of your authors and the requirements of your unified content strategy. This section describes some of the considerations for selecting a tool that best suits your needs. However, each organization’s requirements are different, so you will need to identify criteria to meet your specific needs.
For more information on determining your needs and the criteria to meet them, see Chapter 13, “Evaluating tools.”
One of the goals of a unified content strategy is to eliminate multiple occurrences of the same data. But in today’s enterprises, where the information that comprises content typically exists in multiple, frequently incompatible systems, that raises complications. Often, data must be maintained in legacy systems for access by specialized applications. Data may also be required in outputs (such as catalogs and specifications) and must therefore be collected from either a single system or multiple systems for delivery. In other circumstances, multiple content management systems may be used as information repositories. Again, information can then be collected from the multiple systems for publication.
Consider the following:
In the past, information was typically delivered in a single format. It was designed for that format and republished each time the information changed. That is no longer the case. With the popularity of web-based publishing, information is typically output to multiple formats, including HTML, paper, and sometimes wireless. The content may be identical, with format optimized for the output. Or, the content may be tailored for use in the output format. Whatever the output, a key function of any delivery system is the transformation of information from its stored format to the required output. Delivering unified content requires the ability to publish not only to traditional outputs (such as paper and web), but also to XML, PDF, and WAP devices (such as PDAs and cell phones).
An obvious first question is to ask what output formats are supported by the delivery system. Some possible formats include the following:
PostScript
PDF
HTML
XML
Microsoft Word
Wireless
The next question to ask is whether the tool supports output to multiple formats for a single publishing request. For example, can you create a PDF version of a product specification sheet and an HTML version with a single request?
Most—if not all—of the big delivery systems support some form of XSL, the XML formatting and transformation language (See Chapter 14, “The role of XML”). It is actually their support of XSL that gives many engines their apparent power. There are two questions to be asked of a delivery engine. First, how much of the XSL standard does the tool support?
XSLT?
XSL Formatting Objects?
XPath?
Second, how compliant to the XSL standard is the engine? In the rush to get market share, companies frequently develop their products in advance of the standard: They develop a product based on what they think the standard will be. Sometimes their interpretation is not correct. Or, vendors support part of the standard—the part that’s easiest to implement—and save the complicated stuff (frequently the most valuable functionality) for later versions.
You should think carefully about any delivery engine that supports just a part of the XSL standard or that supports the product developer’s own version of the standard. XSL is growing in popularity by leaps and bounds. Systems that do not fully support XSL now will be forced to play catch-up with functionality, assuming that XML and XSL maintain their current growth in popularity.
You should also think twice about a delivery engine that does not support XSL. There are processing engines that support other style languages, but they are usually limited in flexibility.
In publishing models of the past, authors created the “navigation structures” that are part of a book or web site. The structures include Tables of Contents (TOCs), indexes, lists of figures, lists of tables. For example, the author would embed index entries in a file. They would then need to generate the index and insert it in their document. In today’s models, systems can be designed to assemble and locate these structures as part of the automated publishing functions. Therefore, can the tool automatically create TOCs, indexes, and linked lists (for example, of figures) from the content without any intervention from the author?
On other occasions, you might need to publish just parts of a document, such as updated procedures in an intranet-based policies and procedures guide. Does the tool include support for publishing pieces of a document or just full documents?
In the case of large volumes of information, it may be necessary to process or publish a collection of discrete information products, such as a series of departmental policy guides to a corporate intranet.
Does the tool include support for publishing collections (groups of documents)? For example, can the tool take a series of input files and build a complete web site, with full hypertext linking? Can the tool compile the TOCs and indexes for these collections?
Graphics designed for one media (such as paper) do not display well on another (such as the Web), or may not even be in a compatible format. Graphics must be transformed to match the requirements of each output.
Will the tool perform automatic conversion based on targeted output? Can selected content be flagged to preserve maximum fidelity of graphics?
Conversion is similar to transformation, except that conversion is usually on the input side. The engine takes content in a specific format and converts it to the neutral format required for publishing. For example, it might take a Word document and convert it to XML. After the document is in XML, the delivery engine might transform it into HTML and PDF.
Does the tool support conversion of content? What formats does it support? How clean (that is, problem-free) is the conversion?
There are many potential output formats for information, including PDF for paper and HTML for pure web access.
Enterprise information must be managed throughout its full life cycle. That includes the actual physical outputs from the delivery system. That is, if you create PDF files as your output, they must be fully managed to ensure that the complete, up-to-date versions are available, and that you don’t have old versions being distributed. Or, if your output is an HTML file or series of files, they must be managed. Ideally, the publication engine should help to automate this management. Generated files should be copied to web servers, copied to output directories, or checked into content management systems automatically. For the delivery engine:
Are published documents (outputs) automatically checked into the repository for tracking?
Can outputs be automatically associated with source documents (through metadata)?
Are metadata from contributing documents (files) automatically assigned to published output for check-in?
Are publication directories automatically populated (both internal and external to the repository)?
Any publishing actions that cannot be accomplished automatically must be addressed manually in your processes. In situations where the actions are complicated or involve large numbers of files, human error becomes a risk.
With the increasing capabilities of content management systems has come a building-block approach to output creation. The information exists in the content database as discrete chunks that an assembly engine assembles into complete output entities. Content that is assembled in chunks is often referred to as a virtual document or compound document.
Does the tool include support for virtual or compound documents (assembled in response to a publishing event or request)?
Dynamic content is content that is assembled only when it is requested. It does not exist as a document; rather, it exists as a series of content objects that are assembled on demand. Dynamic content can be delivered to both users and authors (systematic reuse). For more information about dynamic content see Chapter 10, “Designing dynamic content.”
Dynamic content can be delivered to the users in multiple ways:
Multi-channel format
With an assembly engine, appropriate content can be extracted and assembled in the requested format (for example, web page, wireless, or PDF) and delivered to users.
ASP (Active Server Page)
An ASP is a web page that is created by using Microsoft products. These pages are identified by an .asp extension (file ending). When a browser requests content, the web server for the page dynamically generates an ASP page with HTML code and sends it back to the browser. As far as users are concerned, they are looking at a standard web page.
An ASP is typically set up as a framework (sometimes called a wire frame) that has physical regions on the page for the dynamic content to fill. The ASP can draw the content to fill the page from a database or a content management system.
Portal
A portal is a web site that is commonly used as a gateway to specific web content or other web sites. Personalization techniques make it possible to dynamically configure a portal to show users only the content that is relevant to them. Users can then navigate from the portal page to the desired content.
The content shown to users is based on metadata, which are derived from:
User profiles
A user profile consists of explicit information about users. The information is contained in metadata.
User selection
Users can specifically identify the type of information they want to view. They usually do this by selecting options on a form or selections from a web page. The options are then used as explicit metadata and added to the user profile.
Behavior
Behavioral information is implicit information gathered about how users navigate the web site, the information they view, and the product or service they buy. This implicit information is then interpreted and the results added to the user profile.
The user content metadata are then interpreted by the business rules that control what content is appropriate at what time, for which user or author, and in what location in the document. The business rules then match and extract content from the content management system. Finally, the assembly engine assembles the content appropriately and delivers it to the user interface. Figure 18.1 illustrates how the metadata from the user profile, user selection, and behavior are matched with the business rules to identify the appropriate content, assemble the content, and deliver it to the user interface.
Can the delivery tool support dynamic content? How is dynamic content delivered (multi-channel, ASP, portal)? How is it supported? How do you enter user profiles? Can the delivery tool update the user profile based on user selection? How are business rules entered (code or user scenarios or plain language interface)?
Personalization is an extension of dynamic content. Personalization engines provide dynamic content to users, but they also recommend related content (for example, products and services). Many web content management systems provide personalization engines. Personalization engines have typically been provided to improve the user experience and to support sales and marketing campaigns. Personalization engines also collect information about the user for the system to use (such as usage reports, login/logout data, navigation reports, history, customized newsletters, and so on.) In addition to the components for dynamic delivery of content, personalization engines typically provide a recommendation engine. A recommendation engine uses the user profile, user selection, behavior, and business rules to identify what content (usually a product or service) to display to users. In addition, it can use collaborative filtering (looking at what other users have selected) to provide recommendations.
What functionality does the personalization engine provide? How do you enter user profiles? How are they saved? Can the delivery tool update the user profile based on user selection? How are business rules entered (code or user scenarios or plain language interface)? How does the recommendation engine work (analytics, algorithms, collaborative filtering)?
Gone are the days of big publishing departments, which took files from authors, cleaned them up, and published them to the required output. Today’s enterprise model features centralized automated publishing. Authors submit a file directly or by setting a workflow flag, and the required output is generated automatically. Therefore, the question that you need to ask is whether the publishing system supports automated publishing (batch mode, without operator support), triggered by author request, workflow event (check-in, status changes), or end-user request.
The delivery engine is an integral component of a successful unified content strategy. You need to understand the basic capabilities of the systems that exist.
Basic capabilities include:
Aggregation
Conversion
Distribution and output management
Assembly
Transformation
Automation
Key questions to ask of potential delivery engine vendors include:
What output formats are supported? Can you publish to multiple formats with a single request?
Does the tool support conversion of content? What formats will it support? How clean (that is, without problems) is the conversion?
Is delivery automated? Can it be triggered by workflow?
Does the system support XSL? How complete is that support?
Can the delivery system help to automate the management of the output? Can it automatically check output into content management and apply metadata?
Can the system build TOCs, indexes, and other navigation structures automatically?
Can the system build navigation structures for collections of information?
Does the system support partial publishing, to deliver only changed information, or must you republish everything?
Can the system assemble chunks of information into virtual documents?
Can the system convert graphics from one format into another format more appropriate for the output?
Can the delivery tool support dynamic content?
How is dynamic content delivered (multi-channel, ASP, portal)?
How do you enter user profiles? Can the delivery tool update the user profile based on user selection?
How are business rules entered (code or user scenarios or plain language interface)?
Does the CMS or delivery tool support personalization? How does the recommendation engine work (analytics [a method for analyzing information], algorithms, collaborative filtering)?