The GUI versus the Command Line: Which is better? (Part 1)

(Editor’s Note: Are you a point-and-click person or more of a propeller head? What on the surface seems like a simple subject and mostly a matter of personal choice; using either a Graphical User Interface (GUI) or a Command Line Interface (CLI); can have a significant effect on how quickly or at what scale you get SE work accomplished. One of our WEB SE’s give’s you his take on this subject in this two part blog.)

MSDOS has a command line interface. It is its only user interface. In Windows, most everything can be done with its graphical user interface, although it provides a command line as well. One of the primary design requirements for Windows, however, was to provide the user with a consistent and reliable graphical interface to all of what the OS provides. In general, an interface serves as a communications boundary between entities. It provides an abstract and well defined set of controls to the resources and functionality of its underlying mechanism. With operating systems, we employ user interfaces (UI) to carry out interactive tasks. At times these tasks can be repetitive and at other times they can be simple one-time jobs. The majority of the mechanisms contained within Windows come with both a graphical and command-line interface. So which type of UI is better? The answer to this question really depends on the nature of the task at hand.

The GUI Learning Curve

The GUI was designed with “learning-curve” in mind. Its goal is to allow the user to very quickly learn how to manipulate and control whatever function exists behind the interface. Just about all user interfaces come with a variety of sub-functions and options. Depending on the task at hand, this set of functionality can be very large or very small.

A Typical OS Operation

Take the simple task of listing all of the files and subdirectories that exists in a given directory. Explorer, which is part of the Windows GUI, is a great tool for doing this. With the Windows command line shell (cmd.exe), dir is also a great tool. Now how do these tools differ? The obvious answer is that Explore is the easiest and, incidentally, the most commonly used interface for browsing the directory structure. So why is it easier to use than the dir command? Well, let’s look at the many different functions that Explorer provides for looking at different views of directory contents. Take the “List” and “Detail” views for example. With Explorer, to switch between these two views, all we have to do is push a button at the top of the Explorer window and select the desired view from the presented menu. What’s more, if we want to have our directory contents sorted by file name or size, just press on the “Name” or “Size” column header and, voila, your contents are order the way you like. In fact, it takes very little effort to learn how to switch between any one of these view thanks to the intuitive and easy layout of Explorer’s GUI functions. The Explorer interface, because it is a GUI, is “quick learn.” It has a short learning-curve.

Now what about the dir command line utility? Can it present and arrange the contents of a given directory in the same way that Explorer can. As you may have guessed (or already know the answer), absolutely. Let’s take a look at how this is done by using a hypothetical directory called c:\temp. To list the contents of this directory, including their details, we would use the command:

dir c:\temp

It just so happens that the details view is the dir command’s default. But what about the list view? To do this we would use the command:

 dir c:\temp /b.

Now to order the files and directories by their names, we use the command:

dir c:\temp /o:n

And to order by size use:

dir c:\temp /o:s

The last two commands order the contents of c:\temp by name and size, respectively, using the default view – with details. But what if we wanted to list the contents this way without including the details? This is how Explorer would display the contents if we had both the “List” view and the “Name” column selected. To do this we would combine the parameters we used above (parameters are also called options and/or switches). To list contents, ordered by name, without details:

dir c:/temp /b /o:n

To create your list without details, ordered by size:

dir c:/temp /b /o:s

The Command Line Learning Curve

So was it harder to produce our various directory-list views with the dir command than it was with the Explorer GUI? Yes, to a degree. For one thing there was a lot more typing to do when using dir. More importantly, if we didn’t know which parameters to use we would have had to look them up. Because of this, it’s far less of an intuitive process to get proficient with the dir command then it is to do so with the Explorer GUI. This is a key weakness for the CLI. The act of researching how a CLI utility works typically requires nothing more than a review of its help page, however this requires a deliberate effort and some extra time.

The GUI layout, on the other hand, provides the user with several cues as to what options it provides simply by the way it looks. Most users become proficient with GUI utilities without ever having to read through their help file(s). A command line interface is harder to become proficient with because its “layout” is different from the GUI’s, in this respect. The CLI layout consists of a command name, a usage message and one or more help screens/files -- not a nicely organized set of buttons, slider-bars, fields etc. Both dir and Explorer contain a collection of options and sub-functions for controlling the behavior of how directory contents are listed. In fact, the two interfaces share a lengthy set of these options (the examples above demonstrate only two of sixteen dir options, three of which have sub-parameters of their own). However, an important difference between the two UI’s is that the dir command provides these from typed characters, syntax if you will. Learning this syntax takes time and effort . The Explore GUI does not require this additional work from the user.

The GUI Strength is the CLI weakness

 So we can carry out the same tasks with the CLI that we can with the GUI. This is at least the case when it comes to listing the contents of a directory (and I assure you, there are, literally, hundreds of other OS tasks that we can do this with, as well). The GUI is, in general, more intuitive to use and has a shorter learning curve than the command line does. This is a key strength for the graphical user interface. Because the CLI does not have these qualities, this is one of its key weaknesses. So in keeping score, we have a key strength for the GUI and a key weakness for the command line.

In the next installment of this blog we’ll look at a key strength of the CLI. As it turns out, just as one the key strength for the GUI is a weakness for the command line, the major strength of the command line is one of the GUI’s key weaknesses.

Comments

• Anonymous
  January 01, 2003
  (As promised this is Part 2 of the GUI CLI blog. Part 1 is here .) Intro In Part one of this blog, we

• Anonymous
  July 16, 2007
  There is NO GUI vs. CLI any longer. They can equally co-exist on the same interface. GUI vs. CLI was caused from the stand alone keyboard and mouse.  A hardware problem. When the keyboard and mouse are integrated into one unit, the GUI vs. CLI goes away. Advanced keyboards are being used that solve this problem. The GUI and CLI can be equally integrated into the same interface. from the ”father of the perfect keyboard” 70716