You’ve studied what XML is and how it can be applied to your workflow. You’ve made a stunning multi-color presentation proving it will save or make you money. The people who sign the checks are on board and enthusiastic about bringing this technology in. So you’re about 10% of the way there.
Publishing, as you may have noticed, is a creative business. We’re not making millions of standardized widgets on an assembly line. Content is the product. Its presentation is a major part of what makes your products sell. The people who create the content and design the presentation will have to be comfortable with the new XML lifestyle.
When we introduced the concept of XML to our editorial, design and production departments, we were given a block of time at a monthly managers’ meeting. I stood in front of a room of publishing professionals and showed them a color-coded screen of XML tags surrounding the content from a sample page. I showed them how you could take those tags and rearrange them or transform them into another set of tags to produce a new page. I showed them how you could search on all the tags to find content that would normally be buried in page comp files. I threw lots of acronyms at them. They all nodded sagely, asked no questions, and moved to the next agenda item. It was a complete waste of their time.
Based on that, I think it’s better to explain what XML does, rather than what it is, and it’s best to do that without focusing too much on, you know, the whole XML thing. I don’t recall being lectured on what PostScript is when starting to work with PageMaker. Knowing how your car’s engine works doesn’t mean you can drive.
If I had to do it again, I’d ask the content creators and designers what kinds of things they have to do that they consider repetitive or not a good use of their time. Do they have to spend a week paging through old products or archives to find that particular bit that they want to reuse? Is somebody spending all their time keeping track of art usage so you don’t get sued for using it where you don’t have permission? Are entire projects based on the concept that you’re going to take large numbers of pages and alter them ever so slightly for a customized use? At the end of a project, does someone have to gather all the files, package them up, and ship them to a vendor or another department for further processing for electronic use?
You can also look at your current workflow and determine where the silly bits are. If using XML can make them less silly, then there’s a good illustration of why you want to use it.
Once you know what all the inconveniences, inefficiencies, and idiocies are, you can determine how (or if) XML can help. That’s the presentation you want to give to content creators and designers. The big benefits. The what’s in it for them.
Once they get it, you can hit them with the catch. Did I not mention the catch? Yeah, the benefits only come if they put in some extra work up front. Tagging, file management, adhering to some pretty strict processes, maybe giving up some flexibility, especially on the design side. These are all fascinating topics for another time.