Writers complain that community content is of poor quality, unreliable, badly written, etc. etc. as if it were something that could therefore safely be ignored. This is like complaining that the sea is sometimes rough. So it is, but it is still the sea, and we can still only sail upon it and take our chance with the weather. If we try to pretend it does not exist, it will simply drown us.
It’s no secret that I am not the biggest fan of videos as a vehicle for technical communication. Not that my personal preferences have much to do with whether a video is the best medium for other people, but I’ve complained enough about videos in the past that should acknowledge when I find a video to be the best solution, as I did for a problem I had to solve today. Plus, I think I have figured out a useful property of videos that is worth making a note of: videos help fill in the gaps.
The classical structure of a website is that of a tree. The trunk is the homepage. From there you climb the tree, upward and outward until finally you reach the leaves. That is how we design websites. That is how we test websites.
It’s just not how we use websites.
Do we write documentation to fulfill a responsibility, or to create a business asset? Are we striving to meet a set of requirements pronounced by either convention or regulation, or are we striving to increase corporate revenues and contribute to shareholder value?
The question is provoked by an interesting discussion with Jonatan Lundin in the comments on Tom Johnson’s post Using Tags to Increase Findability. (The discussion has virtually nothing to do with using tags to increase findability — sorry Tom!) Jonatan’s position (if I have understood him correctly) is that tasks can be divided into product-centric and organization-centric, and that documentation should stick to covering product-centric tasks and not touch organization-centric tasks. My position is that the user’s task is to use the product’s features to meet the organization’s goals and that if we are going to produce task-oriented documentation, therefore, we cannot ignore the user’s business domain.
Content producers often find collaboration a hard slog. This is because they do it wrong.
There are two fundamental ways you can collaborate. The first way is to enable everyone to contribute to the project by giving everybody access to everything and a means of communicating freely with everyone else on the team. I’ll call this the total integration model. When content folk say that they need to collaborate, this is almost always what they are thinking of.
The second way to collaborate is to break the project up into pieces and allow people to work independently on their own piece. To make this work, you have to set some constraints so that when each person finishes their piece, the pieces will all fit together. As long as each project team meets its constraints, the pieces of the overall project will mesh up with each other and the whole will work. Each piece of the project can be developed independently without people working on one piece needing to know what people in the other pieces are doing and without needing to look at the things they are working on. I’ll call this the constraint model.