Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

How to work on a new software feature that affects different topics

+1
−0

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?:

  1. 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)
  2. 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

History
Why does this post require moderator attention?
You might want to add some details to your flag.
Why should this post be closed?

This post was sourced from https://writers.stackexchange.com/q/19092. It is licensed under CC BY-SA 3.0.

0 comment threads

2 answers

You are accessing this answer with a direct link, so it's being shown above all other answers regardless of its score. You can return to the normal view.

+1
−0

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.

History
Why does this post require moderator attention?
You might want to add some details to your flag.

0 comment threads

+1
−0

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.

History
Why does this post require moderator attention?
You might want to add some details to your flag.

0 comment threads

Sign up to answer this question »