While these may be my own definitions, I make the following distinction:
- Document: a single, definable collection of information, intended to be certified in some way.
- Information: a wide ranging collection, though often scoped to a particular domain, intended to impart knowledge.
A document might be a contract, or a product specification, or an agreed standard. These are things which are very clearly defined, will almost certainly be certified by one or more people, and must stand as a final product for reference to the agreements that made it. They will usually have a well defined structure, often according to relevant conventions in the respective field.
Information might be instructions for some software, or a telling of historic events, or a catalogue of plant species. It may have a well defined scope but it also may never be finished. Its scope may be well defined or may be limited only by the time available to its contributors. It may be structured, or free flowing, or somewhere in between.
When producing written work, particularly in a professional capacity, it behooves you to identify which of these you are setting out to produce. There is certainly some overlap between the two, but in my mind the key question is that of certification, or “does someone need to sign this off?” If the answer to that question is yes, then you probably want to create a document. If no, then you most likely want to create information.
With the goal identified, choose your tool, or tools, wisely. Microsoft Word and its ilk are very well suited to producing documents but terrible for producing information. These days, wikis are an excellent1 tool for creating information.
Because it is an example I am very familiar with, consider a “manual” for a complex piece of software. Traditionally these were produced as documents — you would actually receive a printed book along with the media containing the software. As computers became more capable, the next step was to receive a “soft copy” of the manual — typically in the form of a PDF file that you could print if you wanted or read on the computer. PDFs were a marked improvement on the printed manuals, especially if they had a linked table of contents, but still suffered from the need to “page turn” a lot and were as clumsy to keep up to date.
The web had the best tools from the moment it arrived. Hypertext was invented specifically to make information available in an easy to use form. The issue that took a while to solve was authoring. I’ve written informational material in raw HTML and it’s not for the faint hearted. I have also written material in various markup languages over the years, which was a little easier but still had a learning curve. Wikis solve this by behaving, in many respects, like the aforementioned Microsoft Word with which many people are familiar, and which require no arcane syntax.
Wikis, from their inception, leaned heavily into the hypertext model by making linking easy and it is this which is the hallmark of well produced information. While it is recommended to provide some kind of hierarchical structure to a body of information, it should not be restricted to this hierarchy.
The hierarchy exists partly to help the author make sense of the domain, and partly to give the user a sense of its breadth, and a “way in”. But, once the user is “in” they should be able to move freely among related topics and even outside of the domain if it makes sense, such as to vendor information. If at any time the user feels they have gone in the wrong direction, the ‘back’ button can reverse their path, or, if totally lost, they can return to the hierarchy.
While the ability to move freely through the information with links can be provided in a PDF, there is another aspect that hugely favours a web interface. A PDF has an inherent page size and a fixed layout. It can be inconvenient for the user to have to deal with this, particularly if screen space is limited, and nowhere more so than on a phone or small tablet. HTML provides semantic information that can adapt to many different shapes of display. A big part of “Web 2.0” was termed “responsiveness” and is what makes (good) web sites adapt well to your phone, or tablet, or PC display. There is simply no way for a document to adapt to these hugely varied viewports.
In summary, consider your audience before you reach for Word or an equivalent. You probably know if you are required to produce a document for sign-off. If you aren’t, then you should almost certainly reach for a wiki, or other web authoring tool. Don’t saddle your audience with a constrained experience based on old paradigms.
- Unless it’s the one in Microsoft SharePoint. ↩