GIS APIs increasingly get used by analysts, not just developers. Writing API docs that serve both audiences without patronizing either.
A documentation style guide can be three pages or three hundred. Where the useful middle sits, and how to build one people will actually follow.
Training teaches a path; reference answers a question. Trying to make one document do both jobs usually means it does neither well.
Screenshots date fast, clutter easily, and are often the wrong tool. When to use them, how to keep them maintainable, and what to use instead.
Software ships continuously; documentation can’t be rewritten every sprint. Strategies for writing docs that survive the next release.
Increasingly, the people using GIS software aren’t cartographers — they’re planners, surveyors, field crews. Documentation has to meet them where they are.
Not all documentation does the same job. A practical map of the core document types, who each one serves, and the order to build them…
Most GIS documentation is written by engineers under deadline pressure — accurate, but unusable. Here’s what separates documentation people actually read from documentation that sits…
