Tuesday, March 24, 2020

[vkoimpmq] Common and uncommon cases in documentation

Consider structuring documentation around the adage "make the common case easy, but keep the uncommon case possible".

First, document how to do the common cases.  Then, show how there's enough rope to do whatever uncommon case the user might dream up.

This assumes your product has such features, which is a big assumption.  A lot of products these days are depressingly designed around allowing the user to do common cases but intentionally preventing the user from doing uncommon cases, e.g., with DRM or closed source.

If free (libre) software is the way one is providing the means to do uncommon cases, documentation should include documentation about the source code, including how to modify.

No comments :