Cutting through the purple prose of my prior posts, we have:
1. Why do you want to use XML?
2. Will using XML actually save or make you money?
3. Do the people who are going to pay for it believe you?
4. Do these people back the project 100%?
5. Is everybody who’s going to be affected at least aware of what you’re up to?
If the answer to all these questions is “yes”, go back and re-read #1. If the answers to all but 1 are “yes” and the answer to 1 is a list of compelling things, then you’re all set to actually start an XML workflow project.
As we’ve established, XML is not magic, or even useful in its raw form, just sitting there, quivering with potential (or botulism). You need to be able to make it, store it, and do stuff with it. (I suppose that applies to lots of things, but here we’re just talking about XML.)
To make XML, you could go a number of ways. You could have content written in a word processor, then use a vendor to turn it into XML. You could also buy something that turns word processor files into XML via stylesheets. I think that’s lame, but sometimes the only way to get content is from an author who uses a word processor and there’s nothing you can do about it.
Why do I think it’s lame? Because word processors are format-centric platforms. There. I said it. You can make stylesheets that describe content, but you’re asking a lot to get people to use them. It’s so much easier to click the Bold button at 3am than to search through 1200 character styles to find the “scientifictermusedinchapteropener” style. And if you fail to capture the content information from the author, there’s no way your vendor or magical stylesheet-to-XML automator is going to be able to do it.
XML authoring tools are equally lame. They’re either so XML-geeky that an author is going to get lost amidst the flashing lights and smoke machines, or so “Friendly” that the authoring experience is reduced to filling out forms, which can be insulting to Someone Who’s Been Doing This For 25 Years (I’ve only Been Doing This For 14 Years and I’m outraged).
Nothing that I’ve seen has been able to find a middle ground. Maybe I’m not as good at googling as I think I am, and there IS something out there that mixes the familiarity of a word processor with the rigor of an XML markup tool (though I found this, this, and this in under 15 seconds, so I’m clearly pretty good at googling).
Until somebody makes the “just-right” authoring tool, we’ll all have to deal with the “existing” ones. I’d think about who your authors are, and how comfortable they are with technology. If your company is like my company, the answer is “they are all different with different comfort levels technology-wise”. If that’s the case then you might need more than one pathway to XML-land.
A handy thing to do is make a list of criteria for choosing an authoring tool. And by that I mean have your authors make a list of criteria for choosing an authoring tool. They’re the ones who are going to be using it all day. They might ask for crazy things like “ease of use” and “intuitive interface” but that’s what you’re going to have to look for.
Find a bunch of authoring tools, download the demos, and . . . what. Start writing in XML? Have your authors try them out? Really? Writing WHAT in XML? I wasn’t kidding about the whole “work up-front” thing. You can’t just buy an authoring tool and start writing. There’s a bit missing. What KIND of XML are you making? Whether you can see them onscreen or not, there are tags in there. What are they?
You, my friend, need a content model.
Filed under: XML |