Graphical User Interface
Graphical User InterfaceA form of UserInterface 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 DougEngelbart.
Given a good strong push by Xerox at XeroxParc in the 1970s.
Improved and popularized by AppleComputer 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 WimpInterface, CommonUserAccess. Contrast with: CommandLineInterface
What about a CommandLineGuiCombo?
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 CommandLineInterface is still around.
GUIs should really be implemented using some variation on ModelViewController because the rate of change of the presentation is different from the rate of change of the underlying logic. TheHumbleDialogBox 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 CommandLineInterface 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 CommandLineInterface is still around -- when in fact, another undefined term is what we mean by "still around", another is "CommandLineInterface", and so on and so forth. Further, the essential characteristic of the GraphicalUserInterface 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 GraphicalUserInterface 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 GraphicalUserInterface) 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 CommandLineInterface 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 CommandLineInterface (whatever that means) is still around (whatever THAT means). Some reasons are:
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:
[Indeed. A CommandLineInterface is essentially a textual programming language with an extremely low overhead to do useful things (zero lines of BoilerPlateCode: no 'void main', no 'import Filesystem', etc.). If our OperatingSystems' GUIs were based on GraphicalProgrammingLanguages, 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 OpportunityCost!).]
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 && makeYou could still use type-ahead to do:
cvs update makeWhen 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 AppleScript 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 AppleScript, 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 <noun_list>" or "NOUN <action_list>", 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.]
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. --PhlIp
Absolutely. And with new utilities like QuickSilver, the lines between GUI and CLI can be blurred, to the benefit of both. -- RobertDaeley
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
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".
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.
EditText of this page
(last edited March 21, 2013)
or FindPage with title or text search