A form of User Interface in which information is presented in the form of pictures, usually on a bitmapped display, and often controlled by a pointing device (mouse, touch screen, etc.). Known also by the acronym GUI (pronounced "gooey").
Invented over many years by a bunch of researchers, prominent among them Doug Engelbart.
Given a good strong push by Xerox at Xerox Parc in the 1970s.
Improved and popularized by Apple Computer with their 1983 Lisa and 1984 Macintosh lines of computers.
Mated with Unix (as all technologies eventually are) in the form of the X windowing system (a.k.a. "X Windows") in the late 1980s.
Further changed by Microsoft, who probably have the most GUI instances in the field at the moment.
See Wimp Interface, Common User Access. Contrast with: Command Line Interface
What about a Command Line Gui Combo?
GUIs are generally recognized as being very good for visual tasks, especially document editing and some common kinds of file management, and helping the user perform uncommon or unfamiliar tasks.
Many more-complicated tasks can be more easily accomplished with a character-based language, which is why the Command Line Interface is still around.
GUIs should really be implemented using some variation on Model View Controller because the rate of change of the presentation is different from the rate of change of the underlying logic. The Humble Dialog Box explains how to do this, under the assumption your controls are simple and ready-made. In practice, many GUIs are implemented in a hairball of mixed model/presentation code that makes everything, beginning with testing, difficult.
Many more-complicated tasks can be more easily accomplished with a character-based language, which is why the Command Line Interface is still around.
This is a widely held and unsupported myth. First, the specification of what "more-complicated" means is unspoken. Next, this undefined "complexity" is cited as the reason why the Command Line Interface is still around -- when in fact, another undefined term is what we mean by "still around", another is "Command Line Interface", and so on and so forth. Further, the essential characteristic of the Graphical User Interface is NOT that its information is in the form of pictures, but is instead that the interface is constructed using a noun-verb paradigm. A Graphical User Interface can be and has been constructed using a character-based language.
The "selection" of the object to which a command is to be applied is commonly (in a Graphical User Interface) made using a mouse or similar pointing device, but does not have to be. Once a selection has been made, in fashion, the set of "commands" appropriate for that object can be narrowed and presented to the user, and then interpreted in the context of the selected object. This is what allows "open" to be a meaningful user operation for a file, a folder, an email, and so on. While its true that select-and-click using a mouse is well-supported, its also true that a command line could be constructed that says "/usr/foo/bar/somefile.c open".
The key attribute of an icon-oriented user interface is that it presents a limited number of objects. Various human factor studies have demonstrated that for a limited number of items, we recognize spatial position more effectively than other choices. Interestingly enough, this recognition is hurt, not helped, when those objects are gridded in a uniform array. Our senses recognize and remember disordered collections of a limited number of shapes (estimates of the number vary from something like 7 to something like 20). Most of us, with only a little practice, "see" groups of up to five things without having to count them individually. When a choice has to be made from more than whatever that number of objects is, then textual labels are much more effective than anything else, especially when they are sorted in some order. This does not, however, mean that a Command Line Interface is more suited for "complex" tasks. It means only that navigational selection is not as effective with a large number of choices.
There are a host of reasons why the Command Line Interface (whatever that means) is still around (whatever THAT means). Some reasons are:
Old software and systems that are still in use
Groups and individuals that view Command Line Interface as "strong" and Graphical User Interface as "weak".
Job security
Elitism
Some people dislike using a mouse
The factors that drive this perception strike me as related to factors that drive the use of "terse" languages like Perl. This is not to be necessarily judgemental for or against Perl or Command Line Interfaces -- it is to say that whatever the factors are, there are many of them, and most of them have little or nothing to do with things like complexity or ease of use.
It is unclear to me exactly what the above is arguing. I would ask the writer, or anyone else supporting GUIs as the best way to interact with a computer, how can I, using a GUI, accomplish the following:
find . -type f -exec md5sum '{}' ';' | \
gawk '{m[$1]=m[$1] " " $2;c[$1]++}END{for (i in m) print c[i],m[i]}' | \
sort -rn | less
which finds all multiple occurrences of files starting in the current directory. Forcing one interface or the other loses the opportunity to combine the strengths of both, and denies the existence of different ways of thinking.
[Indeed. A Command Line Interface is essentially a textual programming language with an extremely low overhead to do useful things (zero lines of Boiler Plate Code: no 'void main', no 'import Filesystem', etc.). If our Operating Systems' GUIs were based on Graphical Programming Languages, perhaps we would achieve a similar level of facility. As it is, most GUI content is programmed in textual languages, and the overhead is significant enough to stop most people before they bother starting (a huge Opportunity Cost!).]
I like express the "GUI problem" with simpler examples. Take a typical "use cases":
update files from cvs and compile
(Any similar "do X then Y' use case would suffice. For example, a few days ago I wanted to "defrag hard-disk (overnight) and shutdown when done".).
The GUI mindset approaches this use case by says "lets create menu item (or button, whatever) that expresses this use case. This is natural, because GUIs are gramatically weak: they (in general) have no way to express this type of relationship. Some will let you create a user-defined macro for the conjunction (and then associate it with a menu/button/keypress/whatever).
The CLI appraoch doesn't need any of this, because the underlying grammar of the CLI has this built in. Even if you had such a weak shell that you couldn't do
cvs update && make
You could still use type-ahead to do:
cvs update make
When the first command is complete, the second will run. This would be a fundamentally undesirable behavior in a GUI, because when something doesn't happen immediately, there's a natural tendency to hit the menu/button/keypress again.
This problem is trivially solved, through the use of command objects and a scripting interface. For example, Macintosh users did things like this with Apple Script or Hypercard. The scripting tool allows the user to create a command object, which understands verbs like "Do It" and "Undo It". One command object is created for "CVS Update", another for "make". The two command objects are chained into another command object (yes, they compose). Click "do it" and it's done. The CLI interface is "easier" only if you have already memorized the shell language.
I think that reply proves my point. The GUI approach to the use-case "do foo and then bar" is to create a new "command object" that implements the composition (A lot of newbie OO programmers suffer the same affliction). The CLI approach doesn't need such a "command object" to be created via a "scripting language" because the interface metaphore is already a script. It doesn't require the composition to be expressed (encapsulated) as a tangible thing because the metaphore is already based on serialization (and there's no additional shell language to learn: you just type the commands and hit the 'return' key at the end of each one). If one wants to reuse the specific sequence multiple times then, of course, in either interface you would create a separate object, script or alias to represent it.
"You just type the commands..." -- conveniently skipping over the part where you memorize all of them. Then memorize the switches and arguments of each one. Then remember the ones where the arguments go in a different order. Then remember the ones that pipe and the ones that do not. The "scripting language" in a decent GUI doesn't need to be memorized or learned, the system just remembers it. Go back and look at Apple Script, in the Macintosh ca 1988.
You keep trying to avoid the issue. My initial postulate was that you knew the two commands that you wanted to run, so the question of knowing options, etc. is moot. Whichever interface one is using, creating a script is trivial -- but what if you just want to do "a then b" without creating a "script"?. My point was that the CLI metaphor is more closely aligned with that concept than is the GUI. That isn't even really a value-judgement: if ad-hoc composition is not a primary value, then it doesn't matter that such scripting is not the defining characteristic of the GUI metaphor.
Your "initial postulate" assumes away the issue. "Assuming pigs could fly, then ..." I think you're assuming the outcome of the argument you're trying to make. I don't see this exchange getting anywhere. I made the mistake of thinking you were interested in learning how a GUI addresses a certain class of problems. I'm not interested in perpetuating the GUI vs CLI religious war that has been going on for two decades now.
I think you're right: no light was shed. These wars are of no interest to me either. I tried hard to avoid making any value-statements that might perpetuate such wars but I was obviously unsuccessful, for which I am sorry. Your belief in my aim in my original statement does indeed appear mistaken. I did indeed "assume away" the issue you wanted to address (syntax/vocabulary), because that is not the issue that I was trying to explore (grammar). I appologise for my inability to clearly express the thoughts that I was attempting to express.
"The GUI mindset"? "Grammatically weak"? I accept your apology, it does appear that you failed to avoid making value statements. If it is "grammar" that interests you, then perhaps it might be more constructive for us to explore the question of visual versus lexical grammars -- perhaps a contrast-and-compare or something similar.
[Regardless of whether he was making value statements, it is possible to objectively say that it is rare for GUIs to support a syntax more complicated than "ACTION " or "NOUN ", whereas it is common for CLIs to support more complex syntax. That's not a value judgement, that's a linguistic description...is it ok with you so far? If so, then I, for one, would be interested to hear more about what more complex kinds of visual grammars you are aware of, beyond those common ones.]
Drag And Drop: ACTION
In the Mac Osx Interface Builder, I've also seen this used to define relations.
The best of GUIs complement and support the best of CLIs, and vice versa. I prefer KDE Konsole because it leaves several shells open in one window, for example, with copy-n-paste between them.
In a CLI, you can arrow up and edit your command. You can write long complex commands; writing commands is separate from initiating them. This is a good thing when you decide to use it. In theory, the decision to use one or the other kind should not be imposed upon you. In normal practice, lazy programmers only implement one side of this equation. --Phl Ip
Absolutely. And with new utilities like Quick Silver, the lines between GUI and CLI can be blurred, to the benefit of both. -- Robert Daeley
Touch-screen versus Mouse - Merger Prediction
Tablets and smartphones are making touch interfaces more common and popular. It's often presented as an either/or run-off between the mouse and the finger (touch-based). But I predict in the future that an office interface will have both kinds of interfaces and that a tablet will replace the mouse. One will sometimes use (look at) the tablet directly, and other times use it like a mouse, controlling the cursor for the upright screen, similar to the touch-pad on some laptops, but with greater size and movement room because a tablet is a larger surface. The upright screen will sometimes mirror the tablet screen, and sometimes be a 2nd screen which has different content than the tablet. One will switch the method or mode as needed. In some cases, the "tool bar" may only appear on the tablet, but larger, such that the main screen is freed up to show the document or content.
The tablet may have to better recognize multiple fingers and identify the pointing finger (or user-chosen finger choice), otherwise, holding all but one finger up all day is taxing on the hand. One will also typically grab the "ex-mouse" tablet for meetings so that they have their full (or virtual) desktop with them for reference or quick demos.
--top, Jan. 2013
and you will take the tablet home and use it as a remote control for your television set, and your boss will pop up on the television set and tweet to you on the tablet that you are watching the same tv show
This is already sort of the case with Apple's Magic Track Pad.
Track Pad has no screen. A tablet is basically a Track Pad with a screen. But it helps illustrate the general idea, so thanks for the tip.
Gripe: Don't include default screen-savers or wall-paper with pretty flowers or birds or whatnot. Most guys hate that, especially if it takes a while to figure out where to change it. Find something more generic that is less likely to offend somebody.
You're offended by flowers and birds??? And you think "most guys" are offended too? *boggle* Speaking as a guy, I've never noticed. What aren't you offended by?
Here is your new screen-saver. Call it "God handing out your report card".
apod.nasa.gov
That's brilliant. For the next twenty minutes, I'm going to respect you a little.
[Awesome pic. But I'm a bit lost on how it's on-topic.]
It's evidence that God's UI is gesture-based.
See original on c2.com 