CLI/command line tool usability can be separated into several grades.
A1. Tool doesn't have usability issues if you can accomplish task with the first try. Without looking up into documentation, invoking command line help or using autocompletion helpers. Without trying to remember what the tool name is. The time to use it is less than 3 seconds (encoding thought for action to command line syntax less than 1 second).
A2. Tool has minor usability issues that can not be easily fixed. You can use it with autocompletion or quik command line help. -h, --help are supported and give you the relevant information on one page without scrolling. Repetitive commands are easy to memorize. Time to encoding thought to action is < 15 seconds with < 3 -h, --help commands.
B1. Tool has -h, --help usability issues. Help is badly formatted. Help contains repetitions. Arguments are confusing. Example
Python 3 argparse default help (https://github.com/yakshaveinc/python/issues/1)
No tool purpose is specified. Help on arguments requires additional commands or repositioning. Recalling arguments requires scrolling several pages or rerunning command through a pager. Example
go build -h
B2. Tool doesn't have -h, --help support. Need to go StackOverflow, learn how to use man, buy a book, use a mouse/trackpad to learn how to execute it. Examples:
lpstat - Fedora 27
command - Fedora 27
Request for Comments
Some things are not easily attached to grades. Example issue:
C1. Some frequently used optional flags in user workflow (such as debug or verbosity) require placement into specific position on the command line, instead of being able to attach them to the end (go run-v flag for verbosity can only be supplied before packages). The distracts user flow when the person wants to understand previous run and brings up previous command from history for editing to add verbose/debug keys (need to lookup that -d in the go case is not for debug).
Perhaps the above grades can be transformed to linter rules if any of those linters can be found. There is also a concept of consistency. Tool interface consistency if it is easy to learn and gets users solve tasks fast is important. Global consistency - expectation from users of different OS is important in the long run.
[ ] checklist for CLI tool interfaces
[ ] service that test CLI tools for compliance/best practices/grades
CLI UX/usability specification
CLI/command line tool usability can be separated into several grades.
A1. Tool doesn't have usability issues if you can accomplish task with the first try. Without looking up into documentation, invoking command line help or using autocompletion helpers. Without trying to remember what the tool name is. The time to use it is less than 3 seconds (encoding thought for action to command line syntax less than 1 second).
A2. Tool has minor usability issues that can not be easily fixed. You can use it with autocompletion or quik command line help.
-h,--helpare supported and give you the relevant information on one page without scrolling. Repetitive commands are easy to memorize. Time to encoding thought to action is < 15 seconds with < 3-h, --helpcommands.B1. Tool has
-h, --helpusability issues. Help is badly formatted. Help contains repetitions. Arguments are confusing. Examplego build -hB2. Tool doesn't have
-h, --helpsupport. Need to go StackOverflow, learn how to useman, buy a book, use a mouse/trackpad to learn how to execute it. Examples:lpstat- Fedora 27command- Fedora 27Request for Comments
Some things are not easily attached to grades. Example issue:
C1. Some frequently used optional flags in user workflow (such as debug or verbosity) require placement into specific position on the command line, instead of being able to attach them to the end (
go run-vflag for verbosity can only be supplied before packages). The distracts user flow when the person wants to understand previous run and brings up previous command from history for editing to add verbose/debug keys (need to lookup that-din thegocase is not for debug).Perhaps the above grades can be transformed to linter rules if any of those linters can be found. There is also a concept of consistency. Tool interface consistency if it is easy to learn and gets users solve tasks fast is important. Global consistency - expectation from users of different OS is important in the long run.
See also