Content Management: When do we need it?

We all use content management to some degree. When we start out our companies we use what I like to call the "unknown folder system". This folder hierarchical system is set up by one person and as the company grows the location of content within the folders is passed on via written procedures or more likely through word-of-mouth.

It is cheap and easy to use when the amount of content is small. As the company starts taking on more projects, developing more products, and hiring more employees the amount of content increases and so does the amount of people needing access to that information.

Posted to an RFP by the District of Saanich, BC Canada (which closes March 18 if you are interested in tendering a bid District of Saanich: Bid Opportunity)

"Information is an important strategic asset for the Municipality of Saanich and like other corporate assets it must be managed in order to meet strategic goals and to deliver programs and services. Increasingly, local governments are fully recognizing the value of their information assets and looking at how standards and procedures can be developed to support decision-making, minimize costs, and maximize the value of information."

Here is a municipality that understands the value of the information they have and the costs involved in writing and maintaining it. But unlike most of us they have 100's of thousands if not millions of tax dollars to take on a large project like this.

So the real question is at what point does implementing a content management system become viable. Well, like I said, you probably already have one. What needs to be implemented is a document system that can be used throughout the evolution of the change in your information as the organization grows. Yes good practices and a core understanding of the purpose of your company and its direction will make that leap easier and cheaper when the time comes.

Questions like "how can we justify the costs of implementing a CMS application", will transform to "how can we not justify the cost of implementing a CMS", which will make the time to act more clear.

In an upcoming webinar hosted by Just Systems called "Transforming Manufacturing Processes through Dynamic Documents" the speakers will be describing how "The static nature [of documents] can result in design, development and maintenance delays, mistakes, rework costs and compliance issues that can rapidly erode profit margins, customer loyalty and time-to-market advantages."

I think this goes to the thought that your documents are not static pieces of paper but living, growing, and changing pieces of information that get used and reused whether or not a process to take care of your documents has been defined. By ensuring a document process is put in place and all people in your company know where to find information, how to request changes, update, and distribute new content, and who has the permission to manage the content you will be well on your way to having a viable content management system. Adding the software to automatically manage the content will only come when core principles of the organization require it.

CMS or Version Control - which one for documentation?

Version control has been and is being used by 1000's of companies to manage their software design. Software programmers check out files from a server to their local client. They can then, make changes and update or check the files back into the server at any time, as long as the connection between the client and the server is available. The version control software keeps the change history. Version control is often used by the documentation department of small companies to track the changes in documents. So why would anyone need a Content Management System (CMS) to look after their documentation? I believe now that CMS tools are becoming more available and cost effective this questions is being seriously asked but the habits of the past are making it hard for us to justify the cost of the change.

In the 60's and earlier technical writing was a very narrow field, comprised mostly of defense and aerospace documentation content writers. It wasn't until the age of the personal digital computer and the explosion of software applications that the technical writer became an invaluable person in the design, distribution, and marketing of these new products. Before this age documents were paper based, stored in boxes. Design history was a function of process and procedure, tracked by a paper-driven system. Even as late as eleven years ago I can remember clearly the physical effort involved in updating a procedure or manual. It required:

• many trips to the active and archived document filing system
• the walking around of drafts for sign-off
• walking around beta for testing
• filing drafts
• archiving current documents to a physically different filing cabinet located in a different room
• holding a release meeting to have the traveler signed off by all officials
• filling the final released document to the active document location.

The process itself is not unlike what is used today, but we did not even have internal email so every question, response, check, and issue had to be physically walked from person to person.

As computer memory increased and word processing applications became more accessible the ability to store documents electronically became more feasible, but the systems that were available to the average company where for tracking the history of code changes. Using version control to track document changes was really a stop-gap solution with no alternative.

I don't know the exact history of CMS applications but I do remember witnessing the increase in hype amongst the technical writing community with respect to XML and CMS about 9 years ago. With the responsibility of a technical writer changing quickly, the hype was more of a plea for a solution to be able to organize, share, and search the increasingly growing size of paperless content. Content writers where now often responsible for coding (HTML, XHTML, XML, JavaScript, CSS, XSL), designing (print, web, help, training, blogs, FAQ's, knowledge base), doc management, graphics, web marketing, regulatory, usability, user validation, applications expertise and evaluation (Word, FrameMaker, WebWorks, RoboHelp, Flare, CMS software, bug reporting, version, screen capture, publishing, e-mail) and finally publishing.

And again I ask, "what is the value of a CMS to a company?"

Content is not code. Software code is written for a specific function, used in a specific location, in response to a specific action or inaction of the hardware, user interface, or the software itself. Content is the description of a concept or procedure that can be used in multiple ways to define a product or company. The design of software code cannot be changed without a consequence to the quality of the product. The content can be written in multiple ways to mean the same thing or sometimes written exactly the same to mean something completely different. The consequence of changing content may or may not affect the quality of a product. At best it is merely inconsistent.

Kevin Ballard of L-3 Communications says, "CMS allows authors to maintain unique names" as well as "maintain the [relationship of] links" between document files. I believe he is right and here is why. As the volume of the content increases, the location of specific wording becomes impossible to track and remember. Content reuse is only possible if the relationship between the new document and the current content is known.

File Relationships
In a version control system files are checked in to a files system designed to store code. The file is checked out to any location on a clients computer. In a CMS system the relationship of file system is maintained when files are checked out. This means that when ditamaps are created for XML files or images used in marketing are imported into a user manual, the relationship is the same on the authors computer as it is when it is checked in. The knowledge of where a file is stored is related to the file it is linked to, not the absolute file location.

Unique Names
Files saved to a version control system use specialized naming structures to meet coding standards. This nomenclature often makes it difficult to determine the actual content or purpose of the document.

Metadata
Another very important functions of a CMS is the ability to search for and find information using metadate. The term "information mining" is become very prevalent in this age of information. The more products and models, the more content that is created and the harder it becomes to find pertinent information. Text files and some word processing files can be easily searched but binary files like jpg, cdr, and quark files cannot.

In a CMS environment files can be categorized using metadate so that the information can be quickly grouped and located. For example, lets say we are a moderate sized medical device company that has 80 products on the market. Within those 80 products there are three target markets (hospitals, government, and personal use). How would you search for all products that can be sold to both the hospital and government market? Well if it was a Word document and you happen to put the target market in the document content then you will find those with a simple search using Windows Explorer, but what about marketing documents designed in Quark or Indesign, or jpg images, FAQ responses in XML, and HTML help topics?

Result
As the amount of content in a company grows over the years, the ability to find specific information becomes more difficult. Without a way to search content across an enterprise, information is lost and then re-written causing similar products in current release to have different wording. If technical documentation is explained differently in different documents there is a potential for misinterpretation, incorrect product use, product failure, product damage or worse, injury. If updated in one document but not in all locations this content resides the problem can continue to haunt the company. The location of all content must be known to ensure consistent, reliable documentation and guaranty the reliability and trustworthiness of a company. Companies are built on brand, brand is built on trust and trust is not implied or expected, it is earned.

The CMS system is a tool required for this information age. Without this type of tool there is little hope of finding our way through the mountains of information we create every day.

Converting to XML - Some Point-form Pros and Cons

I have recently converted some user documents from MS Word to XML for a medical device company with the intent that they would be looking at authoring their future end-user documentation (printed, embedded, and online) in XML. I want to share with you some of the triumphs and challenges we had met along the way.

Pros

• Reuse becomes so much easier - The same 15 steps to 'prep' a patient were used in four different manuals and all we had to do was point to the content. When a change got made in the one manual, it was automatically updated in the other three.

• Editing process is shorter - Chapters or pieces of chapters that are shared between the different models are only edited once reducing the cost for editing.

• Updating for global changes are a snap - when content like product name, revisions, corporate names, logos, styles, etc. are saved as separate XML files that are referenced instead of embedded they can be updated in one place and changed in all documents that point to it.

  Imagine how valuable your company becomes as a salable entity when the purchasing company can re-brand all documentation in less than a few minutes and then republish everything with the new corporate image.
  

• Consistency is easier to enforce - If you are using an editor that validates DITA it becomes easier to uphold standard in authoring. Authors that must validate their content are more likely to follow the standards set by DITA and validated by the software. Note - Most authors know there are ways to work around validation error that do not fit a standard, but it is usually more difficult then following the standard in the first place.

• OASIS and DITA bring down the costs of using XML - A few years ago I wouldn't even consider suggesting to my clients to tackle XML unless they just happen to have an expert on staff with nothing better to do then write XSL and play with the DITA Open Toolkit or invest upwards of $100k for a great publisher and editor.

  With the advances in DITA, the general acceptance of the standard, the specializations that are constantly being improved on, and the new tools hitting the market that are priced for the SMEs the benefits of implementing XML can often outweigh the costs and time it takes to embrace the technology.

• Future cost saving - Once you have your XLST developed, your authoring standards in place, the process for authoring and editing understood, etc. there are so many cost savings that can be realized over MS Word authoring that it makes all the Cons worth the effort.

  When the client said they wanted one manual that had only common content in it, created from the four vertical market manuals, we returned to our publisher, set the conditions to remove all product specific conditions, added a short description to the introduction to describe the manual and then published. This took a total of 11 minutes and we had a reasonable manual. Try to do that with four 170 page manuals in MS Word.
  

Cons

• Painful - No matter how prepared you are there is going to be some pain. There are new processes, now tools, and new ways of thinking that must be embraced not only by the person looking after or authoring the documentation but also by all the people in the company that will touch the content as it moves to publication.

  Half way through the project the DITA standard for chapter books was released with DITA 1.1 and we had to go through a software upgrade for our editor and publisher as well as a second review of the manual styles, a second quote for style customization, and issues that were associated with any release of new software.
  

  DITA is by no means a mature standard and there will be many interations that will cause pain.

• Editing in PDF format was slower - If the content is published to PDF then edited it is very similar to editing each manual separately. There is benefit to having the content edited directly at the XML level in a content management system so that changes can be tracked and accepted or rejected. The problem with this is the person editing must have the ability to edit XML code or have the tools to view XML in a WYSIWYG environment.

• Tools add to costs - Yes there are loads of free products out there and many are feature rich and easy to use but if you were thinking you would publish using DITA open source easily you might be in for a programing ride. I had a software engineer look at the implementation for DITA Open Toolkit and claim he had "flashbacks to his Unix coding days", where only the people closest to the program could use the application.

• XSLT coding required - The XML authoring is the easy part and if you have determined how you will publish your content, the publishing is quite painless as well, but the styling can be very complex and somewhat expensive if you decide that the DITA standard for style does not suit your branded corporate image.

• DITA standards don't apply to all - If you are like most good companies you have a brand and image to uphold. Until just recently (August 2007) DITA did not provide chapter numbering as a standard in book publications. There are other features that your company may require for publishing a book or help file that are not part of the DITA standards.

What they're saying about CMS and XML

The geeks saw it coming years ago. XML is the next wave in documentation yet we have been waiting for ten years for the tools to catch up. What is the Content Management System (CMS) our corporate leaders want and does it come with easy to use structured authoring tools. After
attending the DocTrain UX conference I may have some answers.

I am a technical communicator that has moved to the corporate side of business. I am not a CM or XML expert so this perspective is from the point of view of a technically intelligent person with a business vision that includes CMS and XML. Ever since I took up HTML, XHTML coding 7 years ago for help design and accessibility for web functionality I have been interested in single sourcing. I've heard Anne Rockley speak numerous times on live webinars, and each time after hearing her and others speak I would return to my desk to attempt to write a proposal that would win the support of the lords that ruled over the purses. Content management and XML made so much sense but I never worked for a company that could justify owning the tools to implement it.

In the past XML tools have been hard to use and required coding knowledge. The cost for the tools to do XML is much less that the CMS and range from free, in the form of open source or Notepad, up to the price of good publishing software. The CM systems had a price point that only appealed to larger enterprise companies. The price for the software or system is just the tip of the iceberg there where all kinds of additional costs like training, implementation, legacy documentation transition, as well as the costs involved in implementing a corporate shift to structured authoring. Although the price point to enter the CMS world has changed the cost of the additional processes still exists today.

What Tools are Now Available?
Well obviously I have not seen or worked with many of the tools that are available, and there are plenty. I am going to talk about a select few that I have either worked with or have interest in working with.

XML Authoring Tools
Sometimes the path to complete enlightenment (or structured authoring) must be taken in small steps and sometimes its "all in" or nothing. I am organizing these authoring tools from least to most functional in the sense of true structured authoring. This way you will be able to see where you are on the path and how far you need to go, because not all of us need to go the whole way. (How to determine where you need to be is another article).

Microsoft Word
Word can produce XML files but the problem with the code it creates is that the formatting elements are all embedded in the XML making the final product not truly structured (and huge). Remember, structured authoring separates the content from the format. This provides little if any savings when it comes to reuse and translation.

Adobe FrameMaker (unstructured)
"Ok, this is not structured writing, where am I going with this?" you might ask. FrameMaker has always been much better than Word at keeping the formatting elements separate from the content. Although the elements are embedded, they are not visible to the translators, ensuring that they do not change the way a document looks just by changing the content in the document. Imagine the time you would save if you didn't have to fix section breaks, footers, pagination, and reference links because they are broken when someone added content to the wrong place. FrameMaker is just a better product for producing larger technical documents.

Adobe FrameMaker (structured authoring)
Although Adobe uses their own DTD-type file called an EDD, you are not tied to it. Your content embedded tags for the EDD rules but can be saved as pure XML. You can even convert the EDD to a DTD. This means that you can have the best of both worlds, structured XML authoring and FrameMaker's powerful formatting abilities. This product is an addon to FrameMaker, but is included in the price. Their next version 8.0 promises to have a lot more features.

JustSystems XMetal (XML authoring tool)
This is a great front end for a solid CMS. It follows the DITA structure which ensures that your content is going to be valid (assuming you follow the DITA rules when authoring).

As an extra note, for all you Word folks (which includes me, although reluctantly) there is a plug-in from In.Vision called Xpress Author for Microsoft Word. This intrigued me when I was at the DocTrain UX conference last week but unfortunately they had two computers 'keg' on them leaving us without a presentation and them without a demo.

CMS Tools
Again there are a lot of tools to look at. Two companies that I found interesting both host the CMS system so the business does not have to implement the network architecture to do this.

Inmedius has a whole suite of product for different industries.
Bluestream XDoc is a smaller very function CMS at a price point most small and medium sized business (SMB) could afford.

Anne Rockley the premier expert on content management and president 2005 of the international content management community of practice is the person you want to learn from. She has some wise advice about moving to structured authoring and content management. One article she wrote gives some prudent advice to not start with the tools (Don't start with the technology).

So where is the value?
Assuming the tools are now within the range of an average SMB and all the other costs associated with implementation are still there, what incentive is there for a business to want to change?

My clients are medical device manufacturers. They are required by law in almost every country they distribute in to conform to some type of regulation. In Canada it is ISO 13485 and Health Canada, in the USA it is the FDA, in Japan it is PAL, and so on. If you have ever written for any ISO standard for any industry you are familiar with the intricacies of the required documentation process. Every work procedure in every department, from admin to shipping, must be documented. The spin off is that the procedure defines weather or not there are other documents required to ensure the quality of the product: For example, the ISO regulation does not state they have to have a specification, but when my clients write their design and development procedures they state they will design and build based on the specifications they have defined for the product, which requires a specification document. They may also need marketing requirements, service requirements, validation procedures, etc.

All this information is a gold mine when it comes to preparing the end user material. With my current client I have received 15 of these types of documents of which I have used pieces of each to write the operator's guide. Can you imagine the time that would have been saved if I could just reuse the chucks of information I needed?

Next, they will have to send the manual for translation. Max Hoffman of Enlaso (www.translate.com) has a presentation that talks about the ROI of using structured authoring and estimates that making a small change like using FrameMaker (unstructured) over MS Word alone can save about $1000 per language to translate a 350 page manual. If you implement structured XML the savings go way up.

After that they want to use some of the information as part of the GUI, displaying relevant tips depending where you are in the interface. Then they want a service manual, installation instructions, help files, etc. Each time this gets rewritten from scratch in MS Word is a loss of profit for them. Although I do make more money this way, I am not doing my clients any justice by providing them with a system that costs them more than they need to spend.

As a bonus (insert sarcasm here) there is a decrease in consistency and accuracy when not using structured authoring. When the auditor comes and reviews their systems and finds inconsistencies, they can be flagged or written up with a non-compliance. When they are in the middle of a project and they have limited time to get their product to market, the last thing they want to be doing is checking all the documentation they have already signed off. Worst case scenario is that they lose their license to sell their product in a particular country. If ISO registration is lost the opportunity to sell in many countries is also lost. It is definitely more costly not to use structured authoring than to purchase some software, set up a structure authoring environment, and do it right from the beginning.

Another potential bonus is your company becomes more appealing to venture capitalists. With content that can be ported into any other company, the value of your documentation system goes up.

Conclusion
Start by implementing the structured authoring attitude. Ann Rockley's advises companies to "understand their business needs, information life cycle and content" before investing in technology. Then add pieces as you need them or can afford them and you will always be more efficient and more effective than just writing and saving.

DocTrain UX Conference Review (April 18-21, 2007 in Vancouver BC)

I was just in lovely Vancouver BC for five days to attend the annual DocTrain UX (user's experience) conference. My experience was very positive and for my business very valuable. Let me tell you why.
First, my company provides information management and content creation primarily for the medical device manufacturing industry. Our secondary industry is documenting software applications. Currently we enter our client's work cycle just before they are ready to release and ship their product. Since they have had no support when first setting up their documentation system they are almost always writing their content in MS Word using few if any styles. ClearComm is often involved as early as their pre-beta development stage, to help with validation documents and build procedures. Many times they have not thought about their information until they need user documents. At this stage all we can do is offer to create their content or design their manual layout. After this is complete they will want the information ported to other documents for distribution like help systems, installation guides, FAQ's, training, or service manuals.
My poor editor feels like she is editing the same content over and over. Consistency is lost, cost for writing and editing is higher and the potential for error goes up. It is frustrating.
I went to this conference looking for some answers. I want to give my client's more than a simple fix to complete their project.

What did it look like?
The conference was very well organized by Eileen Savary and Scott Abel. The location was beautiful. The Marriott Pinnacle was a very hospitable hotel with excellent staff. There was continental breakfast, a wonderful lunch and coffee, lots and lots of coffee each day. There was also tea and water.
Every workshop or seminar started and ended on time, which I always appreciate. The presenters where interesting and the vendors where friendly and helpful. There was lots of opportunity to network and get to know others within our own community and there was quite a diverse community represented at this conference. There was even a cocktail reception on Wednesday evening to encourage networking and get people meeting each other. The whole event was very well thought out and orchestrated.

Who did I meet?
Day 1
I went to Alan Houser's workshop on "Task analysis and information modeling for DITA". I've had the pleasure of hearing Alan speak at our STC chapter before and I knew I was going to leave with something worth while. This was a beginner's look at the structure of DITA. Because the audience was not all beginners the questions where compelling and thought provoking. It was an excellent introduction to the conference, starting me on the path to thinking not just how content gets used but why it gets reused and the value of both.

Day2
The keynote speaker was Salim Ismail and I really enjoyed his look at "The Future of XML Publishing: Understanding Web 2.0 | Internet 3.0". Salim is a great presenter. He got me thinking about documentation in a whole new way. Content is moving towards open, available usage. He says, "ownership of data is not the key" and I believe he is right. The more we open up our content to other authors the more valuable it becomes. If the resolution of issues for our FAQ's are being written by the customers then we give back real-life solutions to our audience. His tie in with XML and its realtime searchability made these solutions seem very powerful.

The first morning session was in a question and answer format. Kit Brown, Brenda Huettner and Char James-Tanny spoke about "Keeping your Sanity While Managing Virtual Teams". There was no shortage of questions for them and their insight into working with people all over the country was valuable.

The second morning session I went to see the tool snapshots. This presentation followed a very strict timeline, each vendor got 25 minutes to demonstrate the value of their application. What an opportunity to see different companies' products side-by-side.

Robert Rose was the first presenter I saw in the afternoon of Day 2. He was probably the best presenter of the conference, and that is saying a lot since there were some very good speakers. Robert has a great sense of humour that he is able to work smoothly into his topics. His presentation, "From Chaos to Clarity: How Web 2.0 Delivers on the Promise of Content Control" was just as it promised. It helped add one more layer of clarity to the puzzle I was trying to put together. Every presentation got me closer to a solution for my clients.

I decided I wanted to hear Salim Ismail speak again. In the second afternoon presentation Salim presented "Creating Structured Content With Blogs: How to Leverage Syndication on the Web.... - He was well worth listening to a gain and I am taking his advice to heart. There is so much more I can do, but one step at a time.

The Cocktail Reception and Technology Showcase ran from 5pm - 7pm. Most people attended. It was a great networking event. After the reception one of the venders had a special dinner for their clients and those that had attended their session in the morning. It was another fabulous opportunity to get to speak to so many people working in the industry, both as software vendors and as technical writers. Although it was only 11pm when I got to bed, it felt more like 2pm Toronto time, which was the time my internal clock was still set to. It was a late night. But I was still up at 4am the next morning.

Day 3
I started the day with "Metadata, Taxonomies, and Information Architecture: Putting the Pieces Together to Create an Effective User Experience", being presented by Seth Earley. This was one of those seminars that you really need to be awake for. I was running on 3 nights of 6 hours or less and I found it very hard to concentrate on the technical nature of this topic.

Before lunch I sat in on "The XML Word Processor: Moving the Masses to Structured XML Authoring", presented by Michael Boses. Unfortunately his presentation and backup presentation where riddled with technical difficulties. It was hard to listen to and follow his distracted fumblings so I cut out on that presentation. I was interested in seeing how clean the XML was when created in Word, if it was at all... maybe next time.

At lunch I watched a presentation by FrameMaker Evangelist RJ Jacquez. RJ promised to do a short introduction to the power of FrameMaker before allowing his colleague (sorry I did not get his card) to spend most of the time discussing how to create structured and XML documents as well as DTD's. RJ got a little carried away and spent most of their allotted time discussing important but elementary FrameMaker functions which left his colleague with little more than enough time to rush through the most interesting part of the presentation. Luckily he was very quick and thorough. I got a lot out of this demonstration.

I think this is the key to how I can help my clients. They are too small to be able to afford a complete CMS / single sourcing system, but they need to begin by creating structured documents. By starting them with FrameMaker I can get them headed down the path of structured authoring, while saving them money immediately on translation costs. As they grow, the transformation of legacy documents to a fully structured XML system will be less painful than it would coming from a Word environment. Brilliant!

I had met some very wonderful people at this meeting. We had a second opportunity to spend some time together at the art gallery and get to know each other better, which was a fabulous bonus of the conference.

Day 4
Today was a half day workshop. I chose to listen to Bernard Aschwanden speak on "Demystifying DITA: An Introduction to the Darwin Information Typing Architecture". Bernard has an interesting perspective on the industry. He has a lot of experience with many of the vendors and applications. He spoke about structured writing with reference to all the applications he has used.

Bernard is very intense, filling every possible moment from 8:00am to 12:00pm with information, allowing only two very short regimented breaks. Overall an interesting perspective on applications and lots of solid information on DITA, well worth the time.


What did I take away?
I want to increase the value of my clients' companies by providing them with a system that will give them more control of the information they are sharing internally and externally, provide more accountability for their regulatory audits and save them time and money in product development and translation.

Remember I only had the opportunity of seeing 1/3 of the presenters at this meeting. There was so much to choose from it was sometimes disappointing to know you had missed something that also had value.

I give this conference a 5 out of 5.

XML Tools - less expensive, more abundant and easier to use, I hope

You know, eleven years ago I didn't even know a person could be a technical writer. I had no idea the possibility of performing the best part of every job I had ever had was rolled up in a single career. Since then I have had the opportunity to design, code, create or write many of the types of document known to technical writers. What a blast.

Now, for me, the tides are turning. Single-sourcing is looking like the best fit available for many of my clients. At first I looked at my newest client's documentation with the eyes of an MS purest, how can I write all these manuals and still keep the costs down. They have a 400 page user manual and 5 vertical market manuals that need to be created. The software required help files specific to the market, a training video, and web-based FAQs. I couldn't justify the cost involved in writing all this information in a linear fashion. The only way I could see to produce all these documents, keep the costs down and keep the quality was to reduce the amount of information that had to be written. XML and single-sourcing is where I'm looking to handle the load.

XML (extensible markup language) started as subset to SGML. HTML another very small subset of SGML was not meant to handle formatting and SGML is just too large and complicated for the average non-programming writer. When the buzz about XML started showing up on technical writing listserves and in an STC publication I started to get excited about working with it. I could immediately see the usefulness of single-sourcing, and since I was already maintaining a help system written in SGML the code seemed so elegant to me. Many people praised the ease of use when maintaining a documentation system that had been designed in XML, but as Jim Shaeffer posted to the TechWR-L list, Wednesday March 14, 11:17am, "[Early evangelists] skipped [telling us] all the messy part about writing our own programs or researching esoteric tool chains to get what we wanted."

The tools available to small companies 7 years ago where either too expensive, too complicated, or non-existent. One open-source tool, DocBook, provides DTD and Schema's for XML reducing the amount of coding required to build a system, but small companies where not willing to put out the money to implement a system from the ground up.

So I have tried to use as many of the principles of single sourcing and content managment that a company using only MS Word, without version control, could tolerate. This was a difficult effort.

Now, options seem to be opening up all over the place. Tools are not only becoming less expensive, they are also becoming more functional, with interfaces that are intuitive enough to jump right in. There is also an abundance of applications to choose from. What I need to know more about is where does the Content Management System (CMS) system come in and the XML authoring begin, do you need both and which types go together. In an article "Selecting a Content Management System" [Bob Doyle - Intercom, March 2007, p.9], Mr. Doyle estimates the number of "unique CMSs is now somewhere over 2,000 worldwide". With that kind of variety there is bound to be competition and competition begets choice.

Recently I had the opportunity to participate in two product demonstrations and I liked them both. The first was an XML content management system (CMS) XDoc™ from Bluestream Corp running with XMetal as its editor and the second was a help authoring tool called Flare™ from Madcap Software. The GUIs for both these products were so familiar I could have probably faked my way through a project and ended up with something of value.

They both allow for various publications formats (doc, PDF, HTML, help) and they both allow for security and document ownership. XDoc is better used for entire documentation systems, including marketing documents, internal specifications and procedures as well as end-user documents. XDoc is not an authoring tool but it does integrate easily with many of the most common tools. XDoc provide solutions in technical publications, content management, web content management and E-Learning.

Flare on the other hand is a help authoring tool that can generate help files, printed documents, or a PDF via MS word or FrameMaker.

I am still evaluating the costs and benefits for my clients as well as potential alternatives. All I am sure of at this point is that every new client is a new learning experience. What a great job I have!