There are a lot of 'visual' people who learn very good with pictures and not so much with text. Mee too. A screenshot helps me getting into the setting. Later on I need some detailed documentation. That's why tutorial videos are so popular for beginning something new
Should you add screenshots to documentation?
91–100 of 127 posts
Re: Should you add screenshots to documentation?
#92There are tools which I use infrequently enough (e.g., GIMP, which I use about twice annually) that I don't really want to learn the tool. I want to get the job done and move on. Screenshots to help me navigate a UI, even if modestly outdated, are enormously helpful.
Re: Should you add screenshots to documentation?
#93Re: Should you add screenshots to documentation?
#94When learning something new, concrete is good, abstract is bad. Abstract thinking is good in the next step, when you already know the topic. Screenshot are very concrete and makes understanding the text so much easier. You know that you are in the right place, your brain gets to connect the text to the program. The same goes for command line programs: provide some concrete examples of how to use the program, not just…
I haven’t used it in a long time and I’m guessing there might be something better now but I used to use “bro” instead of “man” when first starting out with a cli tool: http://bropages.org/ It’s documentation but with only examples.
Re: Should you add screenshots to documentation?
#95Earlier quoted context omitted.
Yes, please and about documentation for command line programs, also adding example output (not only the command) can help a lot, especially if the reader is unexperienced with the tool.
cheat.sh [0] has been a godsend when the man pages are too dense and I just want to use the tool and move on with my life. [0] http://cheat.sh/
Look at the sections in a typical man page:
NAME - Totally useless. I know what the name is, I just typed it in
SYNOPSIS - Explains the syntax and grammar of the command line options in an abstract way [OPTION...] HOST:SRC, and so on. Great if you're deeply studying the tool to learn all the edge cases of running it. Not as helpful if you want to do some specific thing.
DESCRIPTION - Pretty much marketing prose by the man page author. Useless.
OPTONS - Detailed, usually alphabetical(!!) list of each command line options. Great as a reference or if you want to know exactly what action X that known option Y does, but useless the other way around (I want to find the option Y that does known action X).
ENVIRONMENT - Interesting trivia about how the environment affects (or is affected by) the command.
EXAMPLES - THERE WE GO, THIS IS WHAT WE USUALLY WANT.
COMPATIBILITY - Interesting detail if you're on a weird platform or up against the edges of where the command is supported.
SEE ALSO - Useful if you don't even know which command you want.
STANDARDS - Nerd alert! You only care about this if you care what IEEE Std 1003.1-2001 is.
HISTORY - Yawn.
BUGS - Useful to know if it's not doing what you expect.
Re: Should you add screenshots to documentation?
#96Re: Should you add screenshots to documentation?
#97Re: Should you add screenshots to documentation?
#98Please, please do not use screenshots of terminal sessions in documentation, there are so many reasons not to do this, no copy/paste, loss of textual data, harder to update/correct, size of document, etc. Instead make that little extra effort to use provided formatting in your wiki/blogging/word processing software using a non-proportional font and ideally appropriate syntax highlighting. Incidentally this also goes…
> there are so many reasons not to do this > no copy/paste That would be a benefit of using screenshots, not a reason not to use them.
Re: Should you add screenshots to documentation?
#99Always add screenshots. Even better, generate them automatically, I did that with an open source project and it was amazing.
Re: Should you add screenshots to documentation?
#100Even more important - documentation should have examples of what valid parameter values are. Probably my biggest pet peeve in docs is describing what a param value should be, but leaving it up to you to figure out what that actually means. Sometimes there's a certain format expected, or several candidates for the parameter value.
It drives me up the wall, that there can be very verbose documentation, and you still often don't get the parameters right on the first (or third) try.
This article for example is doing it right:
https://learn.microsoft.com/en-us/previous-versions/windows/...