|
Top-level
 @davidaugust Some things though will unavoidably require initial training. Like keyboard-driven interfaces, where one of the most important things would be to ensure documentation can be easily reached and the way to do so is one of the first things one sees. 3 comments
@davidaugust One of the unfortunate things is that until not so long ago, it used to be relatively standard to quite literally build the manual into the software (along with the printed version also existing). At some point as the web became more common, that habit got dropped. And since sites & links routinely die, the replacement of "just go on the site" is terrible (nevermind other common connectivity problems, which is even more "fun" when a router has that problem).  @lispi314 agreed. I get that maintaining a single documentation location is easier and less expensive for those building a system, but the users need it available wherever they look whenever they look. I prefer inline but not cluttering documentation as it is convenient for users (most of the time) and if something is changed that something’s documentation is right there obviously needing change too. Your connectivity example is a use case that really demands no remote resource be needed. |
Gregory's Server
@lispi314 right. And that’s a good way to avoid “where is the printed manual” that can easily go missing or be misplaced. Guiding users almost always makes sense, and ideally requires no special ancillary steps. I like to remember the round doorknob vs level style doorknob as an exemplar of trying to build to allow a user to find the solution without needing them to be good at seeking a help system or manual.