How to work on a new software feature that affects different topics
We're working on a software manual with several chapters and topics and, so far, these are mostly self-contained. This means we have a dedicated chapter for "connectivity" and do not mention connectivity elsewhere, a dedicated chapter for "software upgrades" and do not mention upgrades elsewhere, etc. You get the idea.
But we have now a new software functionality that affects different topics in the manual (say, topics A, C, and G). Each one of these topics is self-contained and isolated from the others but affected in a different way by this new functionality.
The question is, what would be the best approach to read about this new functionality?:
- Create a new topic H and discuss in detail how this new feature affects A, C, and G. Add references in A, C, and G to the new H topic (central approach)
- Add information about the new feature to the to the existing topics A, C, and G, without the need of a new H topic. (disperse approach)
We see advantages and disadvantages in both. In (1) we have everything in one place, which makes things easier in the long term, but H would be a topic of disparate things. In (2) we provide the information in the topic itself, where is most needed, but this is difficult to maintain the in the long term.
Thanks, Jorge
This post was sourced from https://writers.stackexchange.com/q/19092. It is licensed under CC BY-SA 3.0.
2 answers
How do your users read and use the manual?
If they use it as a textbook, where 95% of the readers start at the beginning and progress through to the end in linear fashion, then put all the new information into one chapter at the end.
If they use it as a reference book, so chapters are read out of order, individually, or not even in total because the person is looking up a feature, then you need the disparate method.
To use SaberWriter's example, if all I need to do is look up how to create menus in HTML, it would be useful to have at the very least a note saying that I could do the same thing with CSS or even more easily with JavaScript, a quick summary of the process, and then a reference to a longer explanation in the CSS and JavaScript chapters.
0 comment threads
It depends, but probably you want the distributed approach where the chapter on X tells you everything you need to know about X, even if some of that is only relevant if you're using feature Y. However, if Y is a corner case or involves a lot of changes to several other features, you might be better off collecting everything about Y in one place and linking to it from every other chapter it touches. Don't just put it in its own chapter and say nothing in the others, though; that can lead to surprises when users who jumped straight to X later find out that they should have done X' because they're using Y.
On top of this, one approach my team uses is to have a section of the doc set (an HTML bundle of all the individual docs) that describes new features in this release. Each new feature gets a high-level description of what it is and when you might use it, ending with links to the relevant places in the "main" docs. People interested in "new feature Y" can go there for easy access to the information (via links), but the main content is in the other docs.
0 comment threads
0 comment threads