This is not an article on the merits of the command line nor of the merits of the GUI -- that I'll leave to someone else. The issue I would like to raise is to what extent can these two paradigms be combined synergistically. Now before you start in on how this is old hat, let me raise the point that Microsoft products have been moving away from the command line quite steadily since Windows 3.1 and have only recently released a version of Windows for the consumer devoid of its original 16-bit DOS underbelly. While Linux and Macintosh have both had a recent contrary effect, I think it is fair to say that historically due in part to the reluctance of Microsoft and Apple to emphasize the power of the command line, it's popularity has waned to the benefit of the modern GUI. I am not implying causality here, for in fact a strong argument could be made to the effect that the success of these two companies has been due in large part to their de-emphasis of the command line and consectary focus on the GUI. With the possible exception of macros, I am not aware of a case of any strong attempt by either of these two companies to synergistically combine the power of a command line with the power of a GUI. Is this because the modern GUI doesn't need a command line?
Modern GUI's emphasize the mouse as an input device. The user clicks on things and watches the screen change to reflect the action. This is an inherently limiting design in that for a program to represent its things (or actions) it must given them some sort of on-screen representation. This simple statement has several important implications and caveats, some of which are: (1) the human eye is only capable of differentiating things when they are of a certain minimum size, lets say 100 pixels on a normal monitor (2) vision is largely affected by human's innate preoccupation with aesthetics (3) the human mind is incapable of effectively dealing with a screen containing say 300 buttons (4) alterations to functionality can require reorganizing large portions of the UI.
Now if you've ever worked on user interface design, you know that screen real estate is a scarce resource. With all the functions you would like to express on a screen, sometimes you are left making decisions like choosing between slightly cryptic icons to represent your buttons; less cryptic larger icons; showing only half as many buttons with full text descriptions; or showing only one button "Tools," or some such, that lead to a page with more buttons.
This can be a very aggravating decision process as many people have their own (strong) opinion on the correct thing to do. My favorite is the 5-level deep chain of dialogs with "Advanced" buttons leading to one another. The reason this happens is that modern software can be complex and can have many "twiddle-able bits" or "options". You can't show 300 options the main page, so you throw a bunch of it into menus named after the "category" of the option (File, Edit, View, Tools). How many times have you hunted through the menus in a modern GUI looking for the darn function you want, trying to guess what "category" the software company wanted it in? Worse, you can't show everything in the menus either, there's just too much, you can only have 5-15 menus before that gets out of control, and only maybe 20 things in a given menu. So the menu selection pops up a dialog. The dialog can't have 300 buttons, so it only has 12, with 4 tabs and an "Advanced" button, etc.
When I want to add a new function to my program, I have to choose where in this labyrinthine system my new button goes. If there is no space, maybe we need another tab on a dialog, and maybe that tab puts us over the tab limit of 5 tabs, so we have to make a new dialog, etc
Much of this little hell that I have been embellishing and exaggerating to make a point, is sidestepped in a command line based system. Now command line based systems have their own drawbacks as well, including (sometimes nightmarish) path, version, and namespace conflicts. For the sake of brevity and laziness I will not delve into these problems other than to state that in some cases they are as damning as the limitations of a modern GUI. If this needs further elaboration, I will be happy to oblige, command lines are no panacea.
That said, in my limited experiences with GUI design I have often been tempted to plop in a text widget with a "GO" button. What would the user type in the text widget? That is the question every user would want to know when they saw it, and the one that is the most damning indictment of the command line in a modern GUI. Who knows what you should type? I might, and I might describe it in great detail in the documentation and even have a `?' help button there that also describes it. You could do all sorts of cool things in there if you knew the way it worked. The problem as I see it is that this concept does not particularly appeal to most end users, especially at sale/demo time. It is not flashy, it is not easy to understand, and it requires up front thinking rather than blind `poking around'.
Put more succinctly, modern GUI's use: "recognition rather than recall".
I must admit that I almost always operate in "poking around" mode, (and sometimes pride myself on my ability to effectively do so) so I certainly am not going to denigrate it too much. Yes, I have before been encouraged to "Read the Fallow/ Faustian (insert your favorite F-word) Manual." Though at times "poking around" does seem sloppy and wasteful, sometimes it pays of big and a hard problem is solved very rapidly with little organized work and research as a result. Most people are all too eager to take credit for this sort of thing; it is a mark of ingenuity.
The trend then is away from user interfaces that require recall and towards those that require only recognition. If a GUI allows the user to intuit its meaning, then that is better than forcing the user to read the manual. While this is all well and good, and makes the sale, it may not be the optimal long-term solution.
Once I have used a system for weeks I develop a knack for it, I know where things are, I know what I want to do, I want to use recall not recognition, my brain has grown and the GUI has not allowed me to leverage my growth. Macros, keyboard shortcuts, and adaptive user interfaces are meant to address this issue, but what I am interested in is the introduction of the command line INTO the GUI, at a basic and fundamental level.
For instance, who is editing the 5th level of "Advanced" dialogs and how much time did they spend finding where the accursed check box is. Why aren't all the options named with simple names and editable with a text widget? For instance in Word, some default setting might look like this:
Then if I was a great command line guy I could set all their values to their opposites in one line, but being a somewhat normal guy I might do this:
Say I want to export all of my settings to a text file so I can take them home:
> SetSettings Auto* "OFF"
OK 6 VALUES SET
>SetSettings AutoSave "ON"
OK 1 VALUE SET
And apply them to my home machine:
>ShowSettings * > mySettings.txt
Neat, right? Useful, fast, better than digging in options dialogs. Now I cheated in that all these options started with "Auto" and there were these nice "Get" and "Set" settings calls that I somehow knew all about, but the idea is that if I were an advanced enough user I could learn these things and actually be able to leverage them.
>SetSettings -f mySettings.txt
As a perhaps more interesting example, suppose I could access grep, awk, and xargs (or anything in my bin or system32 directories) in Word instead of using the silly find and replace dialogs? Clearly there are some issues to be overcome in terms of Word supporting such a feature. Right now to do this I would need to save my Word document in text format or copy and paste or something like that. Most people probably don't have any idea what grep and awk are, but that is ok, because the command line interface does not require screen real estate to present these functions.
The goal is to try to increase people's productivity by leveraging their scalable recall and not inherently limited recognition skills. This must be done in a way that does not provide a barrier to entry, but does provide a stepping-stone to greater usability. The command line interface is inherently flexible and extensible, and as such can and should be used synergistically with the modern GUI.
Once I receive feedback on this article, I would like to follow it with one exploring more recent and future developments in the CLI/GUI area with the continuing emergence of the Web, XML, Email, Instant Messaging, and Web Services. But for now, I'll leave it at that.
Some interesting links on this topic: