You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

projectdoc Toolbox

Templates allow to guide authors producing information of a given type. They also help readers to find the information they are looking for quickly.

Templates to guide Authors

If you start a new document from scratch you have to think about a lot of things. Since you are adding a page to a wiki some of the decisions have already been made for you. Less freedom in this context is actually a good thing! The author is an expert with important information on her mind that needs to be turned into an externalized form to communicate with stakeholder and team members (including the author's future self).

Style already defined

A decision that is already made: the layout of the page. Authors in a wiki typically do not need to bother with this. There is one, sometimes more, templates for applying styles. Even if there are more than one, it is usually pretty clear which one to apply in a given situation.

Structure somewhat defined

Form follows function. So authors usually expect freedom on how the document is structured to pass the information effectively to the reader. But on the other hand the reader expects similar information to be presented similar. The reader should also not notice which author has actually written the document.

Therefore the author needs a tool to help her to align the new document with the existing documentation and the expectation of the reader seamlessly. A template can help. But we must not force the author to follow the structure of the template mindlessly. The author is still in charge to create the structure that delivers the information best, but the template is a guide to allow the author to follow if no better solution is at hand.

Here are some structures a template defines that are usually best kept in sync with other documents.

  • Properties of document types
    • Names of properties
    • Values of properties
    • Order of properties
  • Sections of document types
    • Name of the sections
    • Order of the sections

Usually these rules can be followed without any negative influences on the readability.The author must not be forced to follow this structure. If a value of a property is not available and not important for comprehension, it must be left off. If a specific section is irrelevant or may not provide further understanding, it is important to leave it blank. Do not add any decoy text. If a paragraph, sentence, or even a single word does make the point clearer then drop it. In some cases it may also add to the understanding of a document, if sections are set in a different order or the content of several sections is written to one with an individual title.

Last but not least we are not writing to win the Pulitzer Prize for literary achievements. There are certain kinds of documents that are best consumed if they follow a rigid structure. Glossary items do not gain much appreciation if every entry presents its information in an arbitrary sequence. Meeting minutes are best parsed by readers if they follow a predefined structure. Every document that comes in numbers, that are aggregated in a number of views benefit the reader if they are similarly structured.

Content marginally defined

If the information in the document is not genuine, there is no entitlement for it to exist. So there is no constraint on the content with the exception of controlled vocabulary and probably a style guide. Again this is necessary to provide a consistent documentation for the reader with the least surprise according style, structure, and content.

How does the projectdoc Toolbox support this?

A template typically puts a demand on the author: fill out everything! Or remove what you did not fill out now! Neither is appreciated. The author has a set of information in her mind she wants to contribute. Maybe the document is created collaboratively. Certainly it is created iteratively. This especially applies to project documentation, where the team writes for the team. In this case the documentation is typically never finished. Rather the documents are in different states of the iteration cycle. Yet the information provided is already relevant for other team members. Do we want our readers to be confronted with empty sections only attached to a decoy title? Do we add value by some decoy text like "TBD"? On the other hand, if the boiler plate parts are removed, we have no access to them when we or other team mates need it.

The solution is to defer this problem to the projectdoc Toolbox:

  • Properties are only rendered, if they provide a non-blank value
  • Sections are only rendered, if the body has actually content

This way, the author may leave any blank property values or empty sections as is. This allows future work on the document to further rely on the defined structure.

On screen this looks like this:

In edit mode the author has access to the structure that is defined by the template. The author decides which information she needs to add to the document and stores it at the defined locations. She may add any number of additional properties or sections. Any properties or sections that are not yet (or never relevant), are left empty. Once the document is saved, only those properties and sections are presented to the reader that actually contain relevant information.

  • No labels