Why the command-line interface is overrated
Think back to a particular day on which you made heavy use of the command line. Were you able to recall the commands and arguments from your memory? Or did you have to brush up by looking at the documentation repeatedly? If you’re like me, then it’s probably the latter.
Weaknesses of command-line programs
Fact is, we humans are not good at memorizing sequences of characters without visual cues. That is why tools with a graphical user interface (GUI) are so much easier to get started with. A well-designed graphical tool will direct the user’s attention to the most important or relevant information. Also, it guides the user through different screens to help them with their task.
Compare this to command-line interface (CLI) programs which, in the worst case, require the user to know the commands exactly before using the tool. That said, there are some command-line tools available that offer a pretty advanced user interface by using ASCII characters to draw up the visual components. Examples of this are Midnight Commander and vtop.
However, for the majority of command-line programs, we are stuck with the traditional “type a command, get a response, and repeat until you are done” paradigm. As result, you will probably find yourself consulting the documentation a lot at the beginning. To wrap your head around the various commands and options simply takes time. And what’s more, if you take a long break from using the tool, chances are you will have to refresh your memory the next time you use it.
Most CLI programs come with a user manual. But these can lengthy and too detailed for a beginner who just wants to know how to solve their problem quickly. It is clear how much difficulty users can have with learning a new CLI tool, if you look at the large number of StackOverflow questions asking which exact commands to use. While it is often clearly described in the tool’s documentation.
Not only can users spend a significant time browsing the manual and the web, but it also distracts them from their task. And this notable because in order to work optimally you need to minimize the number of context switches and breaks.
Command-line programs also lose in this regard, as they generally require more cognitive effort to use than their graphical counterparts. That is because converting your intent to the right command can be quite puzzling, even for more experienced users. Graphical programs require less mental energy since it is easier to associate visual concepts like colors, fonts, icons, and layout to their intended purpose. And don’t forget about tooltips, dialog boxes, slide-in panels, images, animation, and diagrams as well.
But what I think is the biggest drawback of CLIs, is that they don’t make it obvious which functionalities are available. Only by reading the manual can you find out what the program is capable of. (Though like I said before, there are exceptions of tools that do offer selection menus or autocomplete). GUIs, on the other hand, solve this problem by presenting all the available functionality through menus, windows, and other visual elements.
Knowing the right command doesn’t mean you will have a painless experience using a CLI tool though. As you can still make typing mistakes, with potentially dire consequences. Command-line tools tend to have fewer safeguards in place to prevent you from making grave mistakes, like wiping part of your hard disk or accidentally restarting a production server. That is because the most powerful commands are usually also the simplest.
When a command-line interface makes sense
I am not saying that command-line programs are inherently bad. They certainly have their use in a good number of cases. In the case where a system doesn’t provide a desktop environment for example. Like when you need to use SSH to make a change on a server VM. In those cases, you will need to resort to command-line tools like vi to edit text files or rsync to synchronize files between computers.
Another reason to opt for a command-line interface is when you want to minimize the consumption of computing resources. Since graphical applications are much heavier to run, they are usually a bad idea for performance-critical systems like servers. If you’re trying to shave off every bit of processing overhead, the graphical front-end is often the most obvious to remove.
It’s also different when you expect your program to be mostly used by tech-savvy people like software developers, system admins, or informatics scientists. That user group is generally much more comfortable with the command-line, and some even prefer it over a graphical tool. Besides that, Linux and macOS users tend to be more familiar with the command-line than Windows users.
When you plan to support automation, then it also makes sense to go for a command-line interface. If the program can be executed with a text command, then it can be run as part of a shell script, alias, cronjob, or in the background after a specific event. The UNIX philosophy actually advocates for programs with a single clearly-defined purpose and which operate on standard input/output. The benefit is that multiple programs can be easily chained together to achieve more complex tasks.
Another thing to consider is development time. CLIs are usually quicker to build because you don’t need to think about the layout and style, as you do for GUIs. For this reason, I usually go for a command-line interface for small utility programs.
And you shouldn’t just think of the initial development time. But also the additional time spent on porting the program to different platforms. There are fewer differences between the shell languages on different operating systems (e.g. Windows has cmd and PowerShell, and all UNIX-like OS’s have bash), than between the GUI frameworks. For that reason, command-line programs can be more portable as well.
Best of both worlds
Even though there are some proper benefits of a CLI, I still believe that a GUI gives the users a far superior experience. Anyhow, you don’t need to choose. Because you can also consider a hybrid approach by offering both. In a way, that is really the best strategic choice, if you have that luxury. Because by doing both, you can support the largest number of use cases.
In fact, many programs start off with a command-line interface before receiving a GUI. Because the CLI offers bindings that can be used by the user-facing front-end, this is a sensible strategy. An example is git, which started as a command-line application. But as its popularity grew, many graphical front-ends popped up like Git GUI, SmartGit, GitKraken, and Sourcetree.
In the end, the decision of whether to develop a CLI, GUI, or both is mostly situational. So if you don’t have the time or resources to develop multiple user interfaces, pick one that makes the most sense for your current situation.
Sources:
