Why are clients usually attracted to graphical user interfaces? Why aren't more applications developed using a console (command line / terminal) interface?
Simply because it requires less mental work :-)
You are referring to a paradigm called WIMP, which was developed at Xerox PARC back in the 1970s.
WIMP (Windows, Icons, Menus, Pointing devices) experimented with a "digital version" of real-life elements, represented by icons. This was very intuitive.
As often, we need to read the first section of the Wikipedia article.
Reference: Graphical user interface
The steep learning curve on command-line-interfaces, implying that GUIs don't have that steep learning curve. We need to call in a test user to find out if that is true. Is it really easier to use a graphical user interface than a command line interface? Our test user is 1 year old, very cute, but she can't type on a keyboard. But she can tell that "A Magazine Is an iPad That Does Not Work".
On a more serious an less populist notion, the article reference Dillon, A. (2003) User Interface Design. MacMillan Encyclopedia of Cognitive Science, Vol. 4, London: MacMillan, 453-458 states the following:
Scientifically valid of course, but if you put two application experts side by side, one equiped with the GUI and the other with the CLI - the command line user is much faster than the graphical user interface operator. The reason for this is that (1) CLI don't "waste" computer power by drawing GUI and (2) CLI don't provide feedback unless you do things the wrong way. But the cognitive load still is on the CLI operator - she/he needs to know exactly what to type and may also be more skilled than a GUI operator.
As a consequence, SharePoint administration is now moving toward excessive use of PowerShell rather than it's GUI equivalent Central Administration. In the previous version (2010) you could do much more in Central Administration than in current 2013 version. Probably because "you need to know what you're doing" on PowerShell and can't accidentally break something you didn't intend to break.
Two worlds making greater distance between each other. Interesting.
According to Don Norman, from the book 'Design of Everyday Things':
Also, he lists out 7 user control design principles for transforming difficult tasks into easy ones:
So, referring the above principles, if you compare the Command-Line UI and GUI, the GUI wins over.
BTW, one of the reasons why Apple's products were successful, is because they applied these design principles from 'Design of Everyday Things' (Don Norman worked for Apple).
To me, being user friendly means:
It has to be familiar and easy for anyone to navigate. If it's confusing, and unfamiliar, it won't be user-friendly. It must also do what it is designed to do, and a person has to be able to do what it was made for without struggles.
It is because 1) in humans, visual thinking and language-based thinking are separate (albeit linked) processes, and 2) a mediocre command line interface is much worse than a mediocre GUI.
A command line interface delivers no useful cues to the visual thinking brain areas, rendering half of our usual orientation ability useless. It works with language only. And that language is very weird when compared to normal human languages. It requires high precision, unlike the language communication we are hardwired for. And both the actions of the classic console (giving no useful cues what you are expected to do) and the reactions of the classic console (spitting out a cryptic message, doing nothing or doing the wrong thing when you do something wrong) are not very helpful for a typical human learning process.
So, humans starting to work with a console soon feel frustrated. Command line tools only remain popular with the people who 1) have a very high preference for the verbal channel and its focus on abstract thought and 2) are very good at the specific style of learning known as RTFM (which is the same style needed for learning abstract concepts such as maths, and mostly useless for physical skills such as playing soccer). The preference for this learning style has always been rare.
Note that when there is no need for the user to learn the correct language before they start experiencing some kind of success, the CLI is accepted by everybody. Google search is basically a CLI - but it is gentle. It never says "bad command or file name", and always delivers some results, even if they are worse than what you expected.
Beyond the learnability issue, the CLI is not generally worse than the GUI. The GUI is better for situations where spatial relationships in the information are important (e.g. photo manipulation), and the CLI is better for situation where conditional, temporal, causal and other abstract/logical relationships are important. There is a reason why all programming languages in wide use are word-based, despite lots of effort to develop graphic representations in the form of flow charts and the whole family of UML diagrams and then some more. It is just that this kind of information can be processed through verbal thinking much more successfully than through visual thinking.
But most applications are not extremely focused on manipulating either spatial or abstract relationships, and so we use interfaces which combine visual clues with words, like the traditional GUI which has labelled buttons.
A major ease-of-use area where GUIs tend to have an advantage is that for poeple it's easier to recognize rather than remember. I.e., it may often be that you don't remember a specific command or option, but would easily and immediately recognize it if it's shown to you; so interfaces that show you the available options are easier to use, even if it doesn't make them more efficient to use for people who know/remember them. It's particularly important for systems you use rarely - no matter how much effort you put into learning it, if you use some CLI system twice a year, you are likely to need documentation (or google) to remember how to do what you successfully did last time; but you would immediately recognize the correct things if the UI had shown them to you.
Another issue is discoverability - common GUI paradigms allow to find out what your possibilities are right there in the interface, as opposed to reading documentation outside of the interface. This is important for ease of learning, as for any even moderately complex software most users will not know all the possibilities, and they can't search 'how to do X' if they don't know that X is possible in the first place.
For an example contrast standard unix cd/ls usage with a text-mode gui of midnight commander:
You get pretty much the same functionality, with a drawback of taking extra visual(and mind) space, but with an advantage in discoverability, and preemptively showing the options and filenames you're likely to need, so you can recognize and select them.
Recognition vs Recall
The essence of the answer is in recognition vs recall. Most people will be attracted to GUIs because they are cognitively easier to use.
Command line interfaces force you to memorize and recall commands in order to do anything. Even to conjure up a help menu or a list of commands, you must know what to type.
GUIs, on the other hand, present options and only require that you visually scan around and recognize the command you want to execute. ("Oh, there it is. I want that option.")
Recognition is always easier than recall. (Think multiple choice tests vs test where you must write in the answer.)
Indeed, when GUIs are hard to use, it's often because the desired option is hidden or there are so many options in view that the person looking at the interface has trouble finding the option s/he wants.
– Teo van de Bunt
The essence of your question has already been answered, but just a few small notes:
It's not fair to say that "graphical user interfaces" are universally user-friendly, or even more user-friendly than the equivalent command line interface. There's a reason why the command line persists to this day, well after we've all developed the ability to develop GUIs for most problems.
In order for an interface to be user-friendly, it needs to be friendly to its user. As anyone here can tell you, users (despite almost always being human) don't all think alike, and don't share needs.
The Unix philosophy describes the design of most good command-line interfaces. In a nutshell, it's about composability—building small, stateless, discrete tools that can be effectively stitched together in sequence to meet a wide array of different problems—as opposed to contextual design—what most of the UX discipline focuses on.
Some of the key benefits of composable design are:
OK, so getting down to the actual question you asked: if a CLI is so powerful, why do we generally design systems with graphical interfaces?
Well the answer comes down to fitness for purpose, and the especially important point that the average computer user generally doesn't need to worry about things like scriptability, portability and integration. They're best served by systems that abstract the complexity away and present a meaningful, simple representation of the operation that better corresponds to how the user thinks the operation works. After all, a picture is worth a thousand words.
For example, we've all seen this animation a million times:
That simple little animation carries with it a huge amount of information:
Whether or not you believe that the animation is effectively communicating all that, it's important to realise that trying to communicate all those facts in words in a similar amount of space would be largely impossible.
As computers get more powerful, animations like these don't all have to be choreographed in advance like this. Instead they can be responsive to the actions of the user and the operation(s) he or she performs.
Take this animation (from Mac OS X):
These animations are hugely powerful at describing the abstractions that exist in this interface implicitly and naturally.
Performing this operation on the command line is extremely difficult. In this GUI, it's a half-second operation.
Here, the user is identifying the block of text they want to save for later without doing much more than simply pointing to it. The structure, links, typeface, font size and other properties of the text are defined in HTML and CSS, but the user isn't consciously made aware of that fact; they simply see content in the format it makes sense in, and can interact with it directly there.
Once it's selected, they simply drag the text itself to the location they want it (in this case, the desktop), and the user gets to see the text itself—still formatted—moving from where they're taking it (the browser window) to the exact spot they're putting it (on the desktop); no abstract flying document graphic necessary. When the user lets go, an image of a document is created in the spot they dropped the text, but this time the actual text the user dropped there is used to populate the icon itself (unlike the older Windows example, the file isn't visually "blank"). Double-clicking on the newly-created document shows another animation: a smooth transition from the document icon on the desktop to the same document open in a text editor, indicating that the text editor window and the icon on disk are conceptually the same thing (only zoomed in).
I know a lot of the other answers here have already made the claim that the main advantage of graphical interfaces are their discoverability—items are able to be designed with their affordances made clear. While I agree it's true that GUIs are inherently able to make the supported actions discoverable to the user, I don't agree that discoverability that can always be assumed to exist in graphical interfaces (you need only see the criticism that has sprung up around Windows 8's gesture-driven charms menu for an example of a GUI where actions aren't inherently apparent at all times).
To me, the biggest advantage graphical interfaces have over CLIs (for average computer users with more usual needs) is that concept of abstraction—of metaphor—that allows complex systems and processes to be boiled down into simple-to-execute interactions that can depend on higher-order thinking to remove the need for explicit descriptions altogether.
protected by JonW♦ Feb 18 '14 at 13:39
Thank you for your interest in this question.
Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.
Would you like to answer one of these unanswered questions instead?