documentation toolkit
Jul. 7th, 2003 07:20 pmOur company makes an SDK (software development kit). That means that we sell our product to people who then use it to make their own products. We provide documentation for those programmers. We also provide the building blocks of a user interface, which they can use or not.
It was only a matter of time before we had to start worrying about user documentation for that interface. Now, we can't just do up a user guide for the interface, because our customers can modify it and need to be able to produce their own customized user guides to go with. And we can't, it turns out, just make them do all their own user documentation. (We currently provide a quick-start guide, a UI cheat sheet of sorts.)
So I'm now thinking in terms of a "UDK", a "user doc kit". Like the SDK, we would supply building blocks and they would put them together as best suits their needs. As with the SDK, we would provide a basic implementation that makes sense and that they can use if they like.
I know I'm not breaking new ground here, but I'm enjoying thinking about the parameters of the problem so I can structure it appropriately. (It even makes up for the prospect of having to write some of that user doc...) We need to support people using everything from HTML to Word to Frame to some Mac-specific PageMaker-like tool (I don't know its name), so it looks like I'm going to settle on unformatted text files and standard graphics formats (JPG, PNG, etc) as the portable common format. I'd like to do something a little richer than that; we'll see. (I proposed XML or HTML but they didn't like that.)
We have a project in-house that needs user documentation, so I'll have a handy guinea pig. They asked me for help with user docs; I sold them this approach instead, which is generalizable. It would be stupid to just do a project-specific user guide and later raid it, cut-and-paste style, for the next project that needs this. Besides, this way we can package the bits for customers, too.