The post lists practices to improve user-experience of command-line interface.

Problematic patterns

1. Borders in TUIs should always be drawn with characters specifically intended for textual interfaces (e.g., boxdraw characters).
2. Borders should be used sparingly, as they end up causing issues when the window is re-sized
3. Decorative content in CLI output should be limited, since the output of CLI utilities can be piped through other programs.
4. Nearly all animated spinners are extremely problematic for screenreaders. A simple progress meter and/or numeric percentage combined with flags to enable/disable them is preferable.
5. Excessive animation and color can harm users with attention and/or vestibular disorders, and some on the autism spectrum. Tools should respect the NO_COLOR environment variable.

Accessibility

6. Does the tool is usable once sended in espeak-ng?
7. Have a look to the WCAG
8. Avoid ASCII-art
9. Keep it boring to other common utilities to reduce the learning curve.
10. Follow convention: POSIX-like options
11. Be predictable with the options. The command only do one thing well.

Documentation

12. Write man pages. If your utility has a config file with special syntax or vocabulary, write a dedicated man page for it in section 5 and mention it in a “SEE ALSO” section.
13. Ennsure whatis and apropos work as intended after installing your man pages.
14. Try adding shell completions for your program, so users can tab-complete options.
15. Use a well-understood -h. It helps to generate shell completions. See https://www.busybox.net/ as example

Miscellaneous

1. Delegate output wrapping or detect the number of columns and format output to fit
2. Be safe. Addd a --dry-run or equivalent option.
3. Disable the colors when the tool is not a TTY, or when the user explicitly enables them.
4. Check the binary name or the packages first. It can already be used. dnf can help.

Opinionated

1. --help should be blazingly fast as user can be stressed using it
2. Include example usage in the man page and accompanying documentation.
3. Send example usages to the tldr pages project if the tool gets popular.
4. Include an extended list of example command invocations and expected output. Make that document double as a test suite.
5. Make your man pages as similar to other man pages on the target OS as possible. Many programs parse man pages, and expect them to follow a predictable structure. w3mman handles hyperlinks; editer like vim support looking up man pages; Pandoc can convert man pages to a variety of different formats.
6. Conform to tools that share a similar niche. If you’re using Rust to make a fast alternative to popular coreutils. ripgrep or fd for Rust, go vet for Go are good examples.
7. Make the output readable to both humans and machines
8. Consider splitting related functionality between many executables (the UNIX way) or subcommands (like Git). See https://www.lucasfcosta.com/blog/ux-patterns-cli-tools#consistent-commands-trees for more
9. Don’t conflate CLIs and TUIs. A CLI should be non-interactive; a TUI should be interactive.