DOCUMENT Magazine - Winter 2012 - (Page 14)

COlUMN IN MuLtI-ChANNeL DeLIvery, ALL Is Not CreAteD equAL by William McCalpin he paradigm of multi-channel delivery has been with us for a number of years now. Most of these new channels have focused primarily on the delivery of data or content. Yet, an area that has been left out of the discussion is the difference between “content” and a “document” and how this difference affects the ability (or even the desirability) of multi-channel delivery. In the world of transaction documents, “content” is frequently seen as a listing of transactions. For example, on a credit card account, on any given day, a consumer may use a mobile device to view the transactions posted up to that point. There is no legal consequence as to the accuracy of this lis—if a transaction is posted tomorrow rather than today, that’s just a matter of inconvenience, not error. On the other hand, a “transaction document” is the unique fusion of fixed and variable data at some point in time that has been brought together to create an entity that has financial and, often, legal significance. Think of that credit card account. The credit card statement at the end of the month is a legal agreement between you and the company; therefore, this credit card statement has to be correct because “there is money riding on it,” if nothing else. The result of this understanding is that the transaction document should be treated as “persistent,” that is, once the transaction document is created, it should never be “recreated.” Whereas content is, by design, usually served up dynamically in order to reflect the most current data, a transaction document is, by design, not served up dynamically but is always the same original copy re-presented. This is true in order to prevent errors creeping into the dynamic re-presentation of the information in a transaction document, if that document is also recreated. Of course, in some industries, the layout or “look and feel” of the transaction document may be regulated, such as for certain parts of insurance policies in the United States. Thus, the company may be liable not only for errors in the data within a transaction document but also for changes in the very layout of the document itself. HTML and XML languages are normally used in the dynamic electronic presentation of content on web browsers and mobile devices. These are lightweight languages that permit the quick presentation of content on a variety of devices with quite different attributes. The downside of using these languages, however, is that it’s difficult, if not impossible, to guarantee what the customer will see on the device. The very flexibility that these languages offer on very diverse platforms assures that the presentation will invariably change. It is for this reason that transaction document producers normally use PDF as the presentation format. PDF, being at its heart a print stream, like PostScript or AFP, assures that the customer sees a transaction document with the same “look and feel” on any platform, even if the customer prints the transaction document locally. Indeed, it is for good reason that PDF means portable document format. However, the ability to easily view PDF on some mobile devices may be practically impossible, given that the transaction document in PDF is usually based on a US Letter or A4 medium—specifications that are far larger than some mobile devices. Thus, in the near future, it seems virtually required for most transaction document companies to communicate with customers not only through multiple channels but with presentation formats geared to the requirements of those channels. This may limit the ability of a company to provide all content and all transaction documents via all channels. In these cases, the company must clearly communicate which content is dynamically generated and which content is document-based. O WILLIAM MCCALPIN is registrar and co-founder of acadami, the transaction document educators. He is also principal and cofounder of MHE and has more than 30 years experience in software development and consulting. For more, email registrar@acadami.org. 14 winter.2012 DOCUMENTmedia.com Full column: www.documentmedia.com/WilliamMcCalpin_Winter2012 http://www.DOCUMENTmedia.com http://www.documentmedia.com/WilliamMcCalpin_Winter2012

Table of Contents for the Digital Edition of DOCUMENT Magazine - Winter 2012

DOCUMENT Magazine - Winter 2012
Contents
What's New
Masthead
Most Social
Editor's View
Contributors
Look After Your Own: Information Security Is Your Job Too
In Multi-Channel Delivery, All Is Not Created Equal
Strike a Balance between Technical and Business Needs
Building Intelligence
Plug into the New World of Work
Chasing the Storm
Get in the Game
I’ve Got the Remedy
Lost in Space

DOCUMENT Magazine - Winter 2012

http://www.nxtbook.com/nxtbooks/rbpublishing/document_2013summer
http://www.nxtbook.com/nxtbooks/rbpublishing/document_2013spring
http://www.nxtbook.com/nxtbooks/rbpublishing/document_2012winter
http://www.nxtbook.com/nxtbooks/rbpublishing/document_2012fall
http://www.nxtbook.com/nxtbooks/rbpublishing/document_2012summer
http://www.nxtbook.com/nxtbooks/rbpublishing/document_2012spring
http://www.nxtbook.com/nxtbooks/rbpublishing/document_2011fall
http://www.nxtbook.com/nxtbooks/rbpublishing/document_2009winter
http://www.nxtbook.com/nxtbooks/rbpublishing/document_2009summer
http://www.nxtbook.com/nxtbooks/rbpublishing/document_20090506
http://www.nxtbook.com/nxtbooks/rbpublishing/document_20090203
http://www.nxtbook.com/nxtbooks/rbpublishing/document_200812
http://www.nxtbook.com/nxtbooks/rbpublishing/document_200810
http://www.nxtbook.com/nxtbooks/rbpublishing/document_strategyforum
http://www.nxtbook.com/nxtbooks/rbpublishing/document_200808
http://www.nxtbook.com/nxtbooks/rbpublishing/document_200806
http://www.nxtbook.com/nxtbooks/rbpublishing/document_200804
http://www.nxtbook.com/nxtbooks/rbpublishing/document_200803
http://www.nxtbook.com/nxtbooks/rbpublishing/document_200802
http://www.nxtbookMEDIA.com