1. Original Entry + Comments2. Write a Comment3. Preview Comment

May 07, 2015  |  Not every option has to be documented  |  4615 hit(s)

Now and again I'll get a request from an engineer that says, essentially, "We need to update the documentation, because there's this additional way to do the task." For example, I got a request not long ago that we were missing documentation for some alternative ways to specify parameters for a command. The command goes like this:

DoSomething.exe --filename <somefilename>

The engineer wanted us to add that you could also do this:

DoSomething.exe -f <somefilename>

In other words, the -f option was a shortcut/alternative for the --filename option.

Similarly, I was recently asked to add a note that told users that under some specific circumstances, they could exclude the filename extension (.pdf or .txt or whatever) from a filename parameter. But leaving off the extension was optional.

When faced with a request like this, the writer might want to take a step back and ask whether the update is really that helpful from the user's perspective: does the reader benefit from this additional information, or does it just add noise? Is this essential information, or is just a nice-to-know?

It's not that these alternative approaches are not useful to users. But does every user have to know every option for every command? Is the benefit worth the extra effort to add them to the docs, and the users' extra effort to sort through the options? What if the alternatives are really just artifacts of the previous version of a command—do we still need to document them?[1]

People who document procedures that involve UI might be familiar with a similar issue. When you're telling the user how to do something, does each step of your procedure describe the menu command, and the right-click context menu, and the keyboard shortcut? This can quickly become cumbersome.

Here's an example of a step from the MadCap Flare documentation that provides an exhaustive inventory of every way to accomplish the step[2]:

Should every procedure step get this treatment? I argue not only that it isn't helpful, but it actually noises up the procedure substantially[3].

The goal of documentation—particularly reference docs and procedures—is to get the user to the solution as efficiently as possible. If you do get requests to include options for commands or gestures, consider pushing back and asking just how necessary these additional options really are.

[1] To alleviate the suspense, I'll note that after consultation with the relevant parties, I said no to the first request and yes to the second.

[2] No keyboard shortcut, because Flare. Grrr.

[3] In my group at Microsoft, we settled on documenting the approach that was the most accessible, in the sense of design for accessibility. That generally meant documenting menus.

Broschat   12 Jun 15 - 6:59 AM

How about a reference section (either independent or as a non-footnoted footnote) that looks something like this:

DoSomething.exe -filename <somefilename>
DoSomething.exe -f <somefilename>

Programmers don't like to read words, anyway!

mike   12 Jun 15 - 8:24 AM

But do you need to list every single option in such a reference section? That's the point--the -f option is functionally identical with the --filename option. (In some cases, it's just a vestigial trace of an older implementation.) Is it a documentation error not to include it? The functionality that the user needs--in this made-up example, the ability to specify a filename--is quite available, even if we don't document the -f option.