Thoughtful CLI design πŸ”—

A command-line interface (CLI) is one of the oldest, and still one of the most useful, ways to interact with a computer. CLIs provide a text-based interface to the user (whether a human or program) to perform various functions or can provide starting values used to launch a graphical user interface (GUI).

Anatomy of a CLI πŸ”—

A basic CLI is a program that takes commands, flags, and arguments, and produces some sort of output in response.

  • Commands (and sub-commands) often represent a particular category of subcommands, or an action to take. For some CLIs, the only command is the CLI name itself. In other cases, a CLI could have various functions that it can perform, each represented by a sub-command. Sub-commands can have further sub-commands of their own.

    A command can perform an action on its own, or can have further sub-commands, flags, and/or arguments that act as options which provide additional data for the CLI's operation.

  • Flags, also referred to as switches, are optional operators that can modify the operation of the command they are attached to. Flags can stand alone, in which case they behave as boolean values (either the flag is present or is not), but can also take data in the form of arguments.

  • Arguments are data provided by the user to satisfy the needs of either a command or flag. Arguments can be either required---something needed by the command or flag to function at all---or optional, in the case where there is either a default value that's used in the absence of an argument, or where the value can be auto-generated by the program unless the user wants to use a value of their own choosing.

A familiar example of a CLI is the ls command that is ubiquitous across Unix and Linux operating systems, including macOS. Short for "list", its function is to list files and directories on your system.

Required vs optional input πŸ”—

CLI success or error codes πŸ”—

Accessibility and CLIs πŸ”—

Because of their simple, text-based interface, CLIs seem to be ideally suited for accessibility. However, there are a number of things you can include in your CLI design that will make it easier to use by people facing one or more sets of visual, auditory, or cognitive disabilities.

Interface consistency πŸ”—

Help text πŸ”—

Accessible output πŸ”—

While many CLIs provide their primary output in the form of text (such as ls, mentioned earlier), many other CLIs might produce output files (such as audio, graphics, PDF documents, and so on) as output.

In the first case, where the CLI provides output directly to the terminal, the accessibility of your output is similar to the accessibility of the terminal itself.

In the case where CLI output is a generated (or modified) file or any other form of output that isn't sent directly to the terminal, it can be helpful to provide some output that explains what the program generated, and where (especially in the case of generated files). Reporting nothing at all in the CLI output can be confusing to people with disabilities. What did the program do? Where is the output? For example, if you have a program that takes in the name of a text file and then converts it and saves it to a PDF file, announcing the results of the action can be the difference between the user understanding that the program succeeded and output was produced, or if the program failed along the way. If there are any important details about either the success or failure of the CLI, then report them to the user.

For example:

Complete! PDF file was generated at `output/chapter-1.pdf`.

or:

Error: Input file, `source/chapter-1.md`, could not be found!

In both these cases, success or failure, the user is alerted about what was produced, or what problem in the input or functioning of the program occurred. Each gives the user some information that can be used to find the CLI's output file, or to understand why it did not succeed.

Programs that silently succeed or fail give