Writers, XML, and CMS
Structured Content: What's in it for Writers?
by Mark Baker
17-Nov-2002 --
Two of the longest running issues in the content management community are,
- what tools writers will or will not use, and
- whether writers will or will not employ markup or other forms of structured writing.
Everyone has heard (or experienced) stories of CMS or knowledge management initiatives that did not work because content contributors refused to use the tools deployed or were unwilling or unable to supply content in the format required. The conclusion often reached is that writers cannot give up their WYSIWYG tools and that any attempt to make them do so is doomed to failure.
On the other hand there are always those who will reply with stories of systems where writers have successfully adapted to the use of XML or SGML, and the CMS is working well. All that is required to duplicate this success, they maintain, is that writers must be forced and/or trained to use the new tools.
I’m a writer. I’ve written for newspapers and magazines. I’ve written brochures, white papers, and technical manuals. I’ve written a book on programming in OmniMark and contributed a section on XML to a book on HTML. I have also managed teams of technical writers working on a number of different projects. I got interested in SGML/XML and CMS not because they promised solutions in the web site management or corporate knowledge management fields, but because they promised solutions to some important productivity problems for writers. I have used every kind of authoring and publishing tool from Page Maker to Frame and from Word to TextPad, and a variety of custom forms-based interfaces. I have designed a custom CMS for single sourcing of technical documentation and managed the people using it.
So I’m in a position to say that both sides in the “what will writers do” debate have got it wrong.
The Writers’ Side
The truth is, writers will use any tool that makes their task easier. If the task is to create a formatted document for print, then a WYSIWYG word processor is a task-appropriate tool. But if you are contributing a structured information object to a single-sourcing system, a forms-based interface combined with the use of XML or SGML markup certainly becomes the right tool. I have hired writers with a really strong prejudice in favor of Frame Maker. However, when they used our custom in-house single sourcing system they were converted very quickly -- not because our system was inherently superior to Frame in any general sense -- but because it was highly specific to the task they had to perform and thus it made their lives easier.
Interestingly, those writers became so devoted to our in-house system that when our company rolled out a new product, they insisted on using the custom system for documenting that product as well. However, the system was designed for documenting our main product, and it soon became clear that its structures did not work for the new product. Eventually we had to abandon the use of the custom system for the new product and turn to conventional tools.
The key, then, to successful tool selection is not WYSIWYG facilities, and it’s not standards or markup, it’s not even ease of use in any general sense – the key is really task appropriateness.
However, we have to understand task appropriateness in context. It is not enough to say that the CMS department wants XML-based documents so a desktop XML editor is therefore a task appropriate tool for content contributors to use. Very few people are willing to change the way they work in order to make somebody else's life easier. Webmasters hoping that everyone in their company is going to start writing well-structured XML documents because it makes life easier for the webmaster are doomed to disappointment.
The same thing goes for knowledge management architects trying to capture all corporate information in an easily searchable form. Getting all their content in well-formed XML may make these folks’ tasks easier, but they aren’t going to receive what they want unless it makes the writers task easier as well.
All Pain, No Gain
There is a fundamental imbalance here between cost and reward: most content providers get no benefit converting to structured authoring; however, it does costs them both time and effort to switch. It is not just being deprived of a WYSIWYG view of your work. There is a lot more you have to know and monitor carefully in order to produce a structured XML document, whether or not your authoring tool actually makes you type angle brackets.
Nor are most content providers given any incentive to produce content in this form. Promotions and raises are typically not tied to it. However, general incentives probably won’t be enough to get authors to produce structured content. People need direct feedback. They need to see how providing structure actually makes a difference in their lives. Without this you the best you can get is dumb conformance – a mechanistic adherence to the visible constraints rather than an intelligent contribution to the success of the enterprise.
But even if we supposed a widespread benevolent impulse on the part of content contributors to supply structured content despite the fact that it cost them additional time and effort and produced no immediate benefit for them, you would still not get well structured data, because the writers usually lack the context to understand the structures they are asked to produce.
Complaints about authors cheating the markup rules to achieve particular layout effects are as old as SGML, but I suspect that in most cases achieving the anticipated visual presentation effect is the only comprehensible context the author has ever been provided. If you don’t understand what it all means and what beneficial effects structured information produces, how do you know when you’re doing it right? And if you don’t know when you are doing it right and when you are doing it wrong, how do you correct your mistakes or improve your technique? The only tangible result most writers ever see is formatted output. No wonder they will do whatever is easiest to achieve the output effect they are looking for.
What Makes Writers Switch
On the other hand, there are situations in which moving to structured writing benefits the writer. Single sourcing in the technical documentation community is of benefit principally to the writers themselves. Writers in technical documentation are facing a productivity crisis because of shortened product cycles, increasing customization of both products and content, and, of course, ubiquitous headcount reductions. The ability to create each piece of information once and to maintain it in one place -- then create many different information products for different products, markets, users, and media from that single source -- can provide a huge productivity boost to writers.
If a writer sees that by providing a piece of information in a highly structured and controlled format they can avoid having to search for that information across a whole set of documents whenever the information changes, then they have the motivation, feedback, and context to produce accurate highly structured information. Writers who discover this do not mind using forms-based interfaces or even typing SGML or XML tags into a text box, if that’s what it takes. (After all, typing tags isn’t hard. We all picked up HTML quickly enough, before the WYSIWYG HTML editors came out.)
What makes the task palatable is seeing the benefit to themselves, getting the feedback on success or failure, and understanding the context of the work.
Not for Everyone
This certainly means that some content contributors will be willing to create structured information and other will not.
Technical documentation is prime territory for structured authoring because it provides substantial benefits to the writers themselves. Also, writers in this field tend to have a good understanding of the structure of their information, and a natural ability to adapt to new technologies. (You can't be a tech writer if you don’t adapt quickly to new technology.)
On the other hand expecting content contributors in HR, Marketing, and other departments to create structured content is probably not realistic. These people are not writers by profession, contributing content is a minor part of their jobs, and they will seldom see any benefit to themselves from creating structured content.
People working at the enterprise content management level (web site creation or corporate knowledge management) must face the fact that they will always need to transform and sanitize the material they receive, because it will never be in the interest of the vast majority of their contributors to provide pre-structured information to them.
But in the world of full time professional content creation (technical documentation groups being the prime example) a move to structured authoring, if done properly, can be of direct benefit to the authors and therefore has a good chance of success.