At my previous company, I championed the principles of minimalism in documentation. While minimalism is not specifically DITA-related, content development in DITA benefits from applying the principles, and DITA certainly works well with some of the principles. And recently there was discussion on the dita-users list about how different types of information architectures may be expressed in DITA.

I don’t have to champion the principles of minimalism any more, because my one colleague and I are in alignment. But I have been finding that minimalism has limits to its applicability.

Perhaps the most famous pronouncement of minimalism is “Focus on doing their job rather than learning your system.” The job-focus versus system-focus has surface validity and applicability in many situations. As a counter-example, let’s take the example of a truck mechanic. The purpose of a truck is to get freight from point A to point B. The truck carries the freight and a driver drives the truck. The mechanic keeps the truck operating efficiently so the overall goal can be achieved. So where do we draw the line between the mechanic “doing the job” and “knowing the system”? A large part of doing the job is investigation of the system to determine a failure and its resolution. A running system is a precondition of achieving the goal but does not in itself achieve anything.

The audience for my information products is enterprise system administrators. These are people for whom working with the system is the job. It is the users of the system who are trying to get something done (support customers, close sales, develop products). The administrators aren’t trying to get anything done besides making sure other people can get something done. Ultimately it ties back into organizational goals, but if the objective for a task is “reduce costs by more effectively using existing server hardware”, then I’ve moved from documentation and training into marketing.

In fact the administrators for whom I write documentation want to know about features. I tell them about the feature, then they decide how to use it in their environment, or whether to use it at all. I wonder if an approach more like SeSAM is more applicable in this sort of context. It doesn’t really contradict minimalism but provides more specific guidance for a wider range of situations. While I still find the principles of minimalism a reasonable starting point, I’ve been finding more and more places where they don’t benefit me.