So you have a content model, and an authoring tool, and a good support system for your users, and everybody is happy and excited and all your XML dreams are coming true. And the writers start writing, and they’re just bursting with creativity and having flashes of brilliance as they tag the content in the user-friendly authoring tool, and they get done and go to File/Save As and are asked where to put the file. And then your dream comes crashing down.
Where DO you put the files?
As always, it depends on what you’re going to do with them. In the, let’s call it, least automagic workflow, you can treat the XML files just like you’d treat any text files that will eventually be put into a page layout application. You’ll divide them up however your page layout templates demand. They’ll be named according to your naming convention. You’ll save them onto a server, or a firewire drive, or a 5.25″ floppy, or whatever you do. It doesn’t much matter because the files will be manipulated by people. Possibly by manipulative people, but that’s an issue for HR.
In a somewhat more automagic workflow (semi-automagic?), the files will be manipulated in a quasi-automated (hemi-manual?) fashion, maybe through watched folders and scripts. A person puts a file in a folder, and an automation does something with it. Somebody else retrieves the altered file and does something else with it. It’s like a manual/automatic partnership. Humans and machines working together for the betterment of all (though mostly the Humans). The XML files in this one would be just like the XML files in the previous example. They’ll contain whatever content chunk the workflow requires, and can be stored wherever digital files are stored. Some upfront work is needed to set up the scripts and whatnot, but eliminating those repetitive/dull tasks is more than worth the effort.
We, naturally, went for the full-on, completely automagic solution. The idea is solid: users interact with the content in whatever capacity they’d normally iteract with it. Writers write, editors edit, artists art, and we all go home at the end of the day satisfied with our contributions. The content management system meanwhile takes all those contributions and cuisinarts them into something we can sell. There are literally menu items like File/New/Print Publication and Tools/Create Online Version.
In order for this to work, all the business requirements, the technical requirements, the design requirements, the editorial guidelines, the workflow constraints, the very living soul of the organization has to be collected and distilled down to whatever format the content management system can deal with. And that, as you might imagine, is hard. It requires heartrending introspection. What do we do? How do we do it? Why do we do it that way?
The content management system will house everything that goes into the products you make. All the raw materials like text content and illustrations and video clips and those audio files of native German speakers asking quiz questions. You’ll need to be able to put new ones in and find the old ones.
The content management system will also be programmed to manipulate those raw materials. So it’ll have to be set up so that it knows what raw materials to pull and what to do with them.
Since all your stuff is in there, you’ll probably want to control who has access to it, so there will be some administrative stuff that will have to be dealt with on an ongoing basis.
This thing will be the users’ main interface with your XML workflow system. They’ll probably come to think of it as the XML workflow application–what they log onto in the morning and swear at as the day goes on. Ease of use is critical here. If it takes 12 steps to get at the XML content, the user is going to be in a very bad mood before they even get to the XML stuff.
Next time I’ll detail some of the practical considerations in setting up a content management system. And by that I mean I’ll share all the stupid things we did and should never, ever, do again.