doering@kodak.com (Paul F. Doering) (05/14/91)
In <y9JT27w164w@bluemoon.uucp> and several ancestral messages,
bbs@bluemoon.uucp (BBS Login) and others have been discussing human/computer
interfaces in which the user would be able to reach a hand into virtual space
and manipulate virtual objects. Although the concept seems to have arisen with
respect to "physically" managing file folders, etc, it clearly could (would)
apply as well to process-control functions: turning a gas valve, lighting a
lamp, and other real-world analogs. An objection cited the lack of feedback
through the sense of touch and predicted difficulty in mastering the technique
relying on sight only, a reply to which dismissed the problem by expressing
confidence in the human ability to adapt. (I hope I've been faithful to the
correspondents in this summary.)
We don't do awfully well in compartmentalizing our learning. In jest, someone
warned during the 3-D movie craze of the fifties that we'd all get so used to
not having to dodge illusory objects hurled into the audience from the screen
that someday someone would get conked by a real bottle falling from a real
medicine cabinet. Raise the ante in the current debate: what will be the
real-world consequences of training a user that a hand is a suitable agent for
"picking up" a hot ingot? My point is that in designing an interface we must be
as concerned with habits carried away from it as we are about intuition
brought into it. (Insert here the standard boilerplate about responsibilty in
programming.) So the question: can anyone refer us to a study (not a
hypothesis) in which an investigator quantified the extent to which remote
control or remote sensing has been unwittingly transplated as behavior back
into the real world?
--
========================= ======================================
Paul Doering (for self) Man will never arrive,
doering@kodak.com man will be always on the way.
========================= =============== -Carl Sandburg =======lev@slced1.nswses.navy.mil (Lloyd E Vancil) (05/14/91)
In article <1991May13.174958.10492@kodak.kodak.com> doering@kodak.com (Paul F. Doering) writes: >In <y9JT27w164w@bluemoon.uucp> and several ancestral messages, >bbs@bluemoon.uucp (BBS Login) and others have been discussing human/computer >interfaces in which the user would be able to reach a hand into virtual space deleted stuff summarizing net talk... >We don't do awfully well in compartmentalizing our learning. In jest, someone >warned during the 3-D movie craze of the fifties that we'd all get so used to >not having to dodge illusory objects hurled into the audience from the screen >that someday someone would get conked by a real bottle falling from a real >medicine cabinet. Raise the ante in the current debate: what will be the >real-world consequences of training a user that a hand is a suitable agent for >"picking up" a hot ingot? My point is that in designing an interface we must be >as concerned with habits carried away from it as we are about intuition >brought into it. (Insert here the standard boilerplate about responsibilty in >programming.) So the question: can anyone refer us to a study (not a >hypothesis) in which an investigator quantified the extent to which remote >control or remote sensing has been unwittingly transplated as behavior back >into the real world? To follow this, should virtual systems have some feedback to the real world? If an operator reaches for an object that would do their real body harm should the system give some negative feedback? How bout a quick touch at 60 hz if they reached for that bare cable? ;-) But seriously, you have a point. The idea that humans tend to grow habits and that the habits of being able to manipulate dangerous objects with one's bare hands might lead to off duty lapses and hence injury is probably valid. I know I've done some things "automatically" that could have caused me serious hurt -who hasn't-. The concept, that people might develop "bad" habits from work experience, sounds like a meme that lawyers would love. "Your Honor, my client, Mr Putz, was grievously injured when he poured molten lead into his unprotected hand. Our contention is that he learned this behavior from his employment as a remote foundryman. As a remote foundryman Mr. Putz was employed by the orbital foundry company as a ladleman. In his job he commonly used his hands, through his employers virtual enviornment computers, to shape molten metal......... -- | suned1!lev@elroy.JPL.Nasa.Gov | * S.T.A.R.S.! . + o | | lev@suned1.nswses.navy.mil | The Revolution has begun! . + | | sun!suntzu!suned1!lev | My Opinions are Mine mine mine hahahah!|
bmb@bluemoon.uucp (Bryan Bankhead) (05/15/91)
doering@kodak.com (Paul F. Doering) writes: > > We don't do awfully well in compartmentalizing our learning. In jest, someone > warned during the 3-D movie craze of the fifties that we'd all get so used to > not having to dodge illusory objects hurled into the audience from the screen > that someday someone would get conked by a real bottle falling from a real > medicine cabinet. Raise the ante in the current debate: what will be the > real-world consequences of training a user that a hand is a suitable agent fo > "picking up" a hot ingot? My point is that in designing an interface we must > as concerned with habits carried away from it as we are about intuition > brought into it. (Insert here the standard boilerplate about responsibilty i > programming.) So the question: can anyone refer us to a study (not a > hypothesis) in which an investigator quantified the extent to which remote > control or remote sensing has been unwittingly transplated as behavior back > into the real world? A good place to start would be the hobbyist groups involved in RC model vehicles. I have known quite a few suck people and their ability to use 'real' vehicles was never harmed by the learning of the ' RC mentality'. I guess it would depend on how similar to reality the interface was ;in terms of what was presented to the senses. This is from bmb@bluemoon.uucp bmb%bluemoon@nstar.rn.com who doesn't have their own obnoxious signature yet
aliceb@tea4two.Eng.Sun.COM (Alice Taylor) (05/16/91)
In article <9875@suned1.Nswses.Navy.MIL> lev@slced1.nswses.navy.mil (Lloyd E Vancil) writes: >The concept, that people might develop "bad" habits from work experience, >sounds like a meme that lawyers would love. This type of learned bad habits is familiar to anyone who has ever used a microwave oven. How many of you have become so used to reaching in for cool dishes that you've tried the same thing in the oven, only to remember too late that ovens make the dish hot too? I wonder if a microwave oven manufacturer has ever been sued because someone burnt his/her hand badly. -alice
v092pxca@ubvmsb.cc.buffalo.edu (Paul D Fly) (05/16/91)
Companies could use a variety of the "We are professionals, don't you try this at home" phrase: "Warning, this is Cyberspace, don't you try this is Realspace." :)
doug@testsys.uucp (Doug Thompson) (05/20/91)
In article <1991May13.174958.10492@kodak.kodak.com> (Paul F. Doering) writes: > Raise the ante in the current debate: what will be the > real-world consequences of training a user that a hand is a suitable agent for > "picking up" a hot ingot? My point is that in designing an interface we must be > as concerned with habits carried away from it as we are about intuition > brought into it. (Insert here the standard boilerplate about responsibilty in > programming.) So the question: can anyone refer us to a study (not a > hypothesis) in which an investigator quantified the extent to which remote > control or remote sensing has been unwittingly transplated as behavior back > into the real world? I don't have a study to point to per se, but some thoughts on the nature of what needs to be studied. We write a lot about interfaces. I sometimes think we don't pay enough attention to *that to which we are interfacing*. I think back to the history of the invention and eventual widespread use of writing. Before writing humans could communicate with speech and touch. Some symbolic signing and graphic art were also used. Writing appears to have begun very much as (or quickly became) a technology to preserve speech. The oldest 'literature' we have, The Illiad, the Bible, etc., consist of documents which were handed down verbally for many generations before they were actually written out. Now writing is a very *odd* sort of *interface* between human and speech, preserving almost none of the physical attributes of the original. We transferred an oral medium to a visual one with dark marks on light surfaces. The shape of those marks 'contains' sound values which we can learn to re-construct into the original words of the written communication and re-produce the sentences verbally. When we read, most of us don't do so out loud. And most of us can read reasonably clear text much faster than we can listen to speech. Few of us can write (or type) as quickly as we can speak, though. We use different senses (eyes instead of ears) to read, and very different muscles in our bodies to create written, as opposed to oral representations of our words. There are a number of studies and theories concerning Paul's question about "the habits carried away" by users of writing. I specifically think of the work of Harold Innis and Marshall McLuhan. Those sholars demonstrate a number of influences, including changing the way indivduals think from a "round oral" kind of consciousness to a "straight and linear" kind of logic. Innis goes on to say that the very survival of great civilizations is impacted by that kind of psychological impact on the consciousness of its citizens. At the very least, most of us can recognize that written communication is quite a different medium than oral communication, even though we use the same vocabulary, and mostly the same grammar rules in both - and even though we may be communciating to the same people. The most obvious elements involve speed of typing and speed of reading vs. speed of listening vs. speed of speaking and interactivity. Most writing is done in a non-interactive mode. We write something. Later the audience reads it and still later the audience may write back. This is a lot different from a two-way conversation in which very small amounts of data are transmitted before there is feedback. To shift this into computer user interfaces, I really think it is necessary to bear in mind that the interface is only partly between the person and the machine - and that it is also partly between the person and the *DATA*. There are many times when the computer screen is nothing more than an electronic piece of paper, displaying paragraphs for the user to read, and the only interface needed immediately is something to turn the page from time to time. Arguably, the presentation of text data for reading remains one of the most important (and common) applications of the computer. And this leads to a further question. If my computer contains a thousand 'volumes' of information, each with a title, what sort of interface is efficient and useful for me in order to quickly find what I'm looking for in it? I could have a 3-d image of book-shelves, and move my hand with a mouse to specific volumes, and look at their titles, eventually selecting one to open. Or I could do an alphabetic/wildcard sort of a list of titles. Assuming I know how to use each of the technologies equally well, my guess is that the latter is going to be much more efficient. It bears no relation at all to the sort of physical task which dealing with the old physical book technology involved, but it does bear relation to the *intellectual* problem of limiting the search according to criteria I understand. I'm looking for my book on dog grooming. I have only one, so the keyword search for "dog" and "grooming" will limit my search to one volume very quickly. The 'best' user interface is the one that lets me pass that information into the computer as quickly and simply as possible and get the information as to how to open that book most quickly. However, what is 'best' for me and what is 'best' for you *may* not be the same thing. The user's education, training, and familiarity with the specific software tools influence what sorts of tools that user will be able to use effectively. A lot of GUI software I have seen attempts to create visual metaphors between computer information management tasks and older technologies based on paper. The whole idea of the file-folder containing separate items is something most of us have experienced in paper-land. We know what it *means*. I do wonder if this is useful in the long run. YES, it certainly helps the person who knows all about paper and nothing about computers quickly figure out what's going on. But does it ever help that person learn about computers and the new possibilities for information storage and retrieval which computers allow but paper does not? It is reminiscent of reading out loud. You can create something that bears greater similarity to the supposed 'original' by reading out loud - but it slows you down and prevents you from using some of the new possibilities inherent in any kind of writing and not inherent in speech - such as speed and abstraction. Other kinds of GUI I have seen are more based on reducing the need to type long strings or commands, using pointing to make selections instead of typing full names. In reducing keystrokes, and speeding up transfer of the human's idea to the computer, these appear to have an overall positive impact. Given a list of strings, it *is* quicker to move the cursor to the one you want than to type out a long string to identify it. So far I have been looking at the problem of finding and reading text which happens to be stored on a computer - text which could just as well be stored on paper bound into books. Hypertext aside for the moment, there is another kind of thing that computer users interact with. And that relates to the operation of the computer itself. I have found my data and now I want the computer to do something with it or to it. Print it, mail it, sort it, spell check it or whatever. Specify and execute some procedure. Again we seem to have a situation where the highly trained computer user can type a modest number of keystrokes to invoke very complex processes while the inexperienced user is confused and befuddled and doesn't know what s/he might do here. GUI to the rescue - menus and boxes and little pictures to suggest the sorts of things that the software at hand can do. The final observation I would offer relates explicitly to education or training. Most of those who are reading this will have spent 10 to 20 years in formal education during which we were trained to deal with written and spoken language, the use of pens, paper, books and for many of us, keyboards. Some large proportion of us will have spent 3 to 7 years of that time using those tools to learn specifically about computers, and each of us almost certainly has some few years of intense experience with operating or programming computers for academic, commercial or personal purposes. I doubt that there are very many readers here who have serious problems handling command line arguments when we want to use software that requires those. The majority of the people using computers in the world today, however, have had only hours or days of training on computers, though many years of training with paper and writing. The great marketplace demand for GUI is mostly generated by those who *do* have problems with command line interfaces, problems relating mostly to lack of training and/or experience. In order to provide relatively inexperienced customers with workable computer tools, the industry has gone to great lengths to build interfaces which minimize the need for experience or training. Sometimes I wonder if this isn't exactly like building a machine into which you can plug a book, a machine which will proceed to act like a tape recorder and whose speaker will begin to 'read' the book to you out loud in the best Queen's English. If you have customers who can't read, but are comfortable with the spoken word, that machine might sell very well. But is it still not a better solution to have the user learn to read? If our population has grown up with unix computers in the classroom as well as pens and paper, and if the typical high school graduate had 12 years of computer experience as wella s 12 years with reading and writing on paper, I suspect that GUI design teams would be doing things a LOT differently. Just as it is not especially efficient to put written things into oral form often, it is not necessarily efficient to put a list of titles for a library into *visual* form, in the way the library stacks are in visual form. Perhaps the more efficient mode of presentation is a highly abstract kind of shorthand and the best interface for many things is not the one that makes something look like its pre-computer counterpart, but something that reduces the large and bulky to its most basic and meaninfgul essence. If we can reduce the content of a 3-D display and simulated physical motion to a single character or string which conveys the same meaning, have we not advanced? These are mostly just more questions. I think Paul's questions are very much up the right alley. =Doug --- ---------------------------------------------------------------------- UUCP: isishq!testsys!doug DNS: doug@isishq.fidonet.org Voice: 613-722-4724 Fido: Doug Thompson on 1:163/162 POST: P.0. Box 3041, Stn C., Ottawa, K1Y 4J3, CANADA ----------------------------------------------------------------------
bmb@bluemoon.uucp (Bryan Bankhead) (05/23/91)
Doug Thompson's post on virtual manipulation seems to suggest 'why doesn't
everybody just use unix?' It seems to me he has been stuck too long in a
mini-mainframe environment. My perspective on computer use is 180 degrees
from his. I am an inverterate micro user and welcome the comins supremacy
of the GUI.
Says Thompson:
"
The majority of the people using computers in the world today,
however, have had only hours or days of training on computers, though
many years of training with paper and writing. The great marketplace
demand for GUI is mostly generated by those who *do* have problems
with command line interfaces, problems relating mostly to lack of
training and/or experience. In order to provide relatively
inexperienced customers with workable computer tools, the industry has
gone to great lengths to build interfaces which minimize the need for
experience or training.
"
The Problem is thay anyone who uses a new application of any type is an
inexperienced user no matter how much computer experience they have.
Command line environments like unix invariably come with a package on
applications like VI editor which the user inevitably uses forevermore
world without end amen. And traditional mainframe/mini environment tend
to have a VERY slender body of applications compared with the micro world.
Thompson again:
"Sometimes I wonder if this isn't exactly like building a machine into
which you can plug a book, a machine which will proceed to act like a
tape recorder and whose speaker will begin to 'read' the book to you
out loud in the best Queen's English. If you have customers who can't
read, but are comfortable with the spoken word, that machine might
sell very well. "
I view a gui more like a machine you can plug ANYTHING into from a 16
track digital sound editor to a biochemical sythesizer and operate it.
Thompson again:
"If our population has grown up with unix computers in the classroom as
well as pens and paper, and if the typical high school graduate had 12
years of computer experience as wella s 12 years with reading and
writing on paper, I suspect that GUI design teams would be doing
things a LOT differently.
"
Seems pretty damn optimistic, this assuption that the future is going to
be THAT standardized. That 12 years experience is useless when he runs
into an unfamiliar application or an application with new capabilities.
With command line interfaces it's back to the phone book sized manual to
memorize 200+ more commands ... Personally since guis allow operation
independent of system type I think they represent a more probable outcome
than everybody using unix.
Thompson again:
"Just as it is not especially efficient to put written things into
oral
form often, it is not necessarily efficient to put a list of titles
for a library into *visual* form, in the way the library stacks are in
visual form. Perhaps the more efficient mode of presentation is a
highly abstract kind of shorthand and the best interface for many
things is not the one that makes something look like its pre-computer
counterpart, but something that reduces the large and bulky to its
most basic and meaninfgul essence.
"
Actually unix is as visual as any GUI!!! But I find an Icon and menu to be
a more efficient form of shorthand than most any unix system gobbledegook.
Anything that reduced huge unix system manuals to something on a screen
seems to be reducing the bulky and large to me!
Finally Thompson:
"
If we can reduce the content of a 3-D display and simulated physical
motion to a single character or string which conveys the same meaning,
have we not advanced?"
If you want to do that with a GUI familiar enough you can write a macro.
And an Icon and a menu does this without having to keep straight 1000 new
primitive every time I move to a new environment.
I know the coming supremacy of GUI's and VR's is causing stress among unix
freaks, and will gradually invalidate all the time and effort they spent
learning it. But in the world of the future there will just be too much
going on in dataland and it will changing to fast to fit through the
needle (and learning curve) of command line interfaces. GUI's ARE the
future
This is from
bmb@bluemoon.uucp
bmb%bluemoon@nstar.rn.com
who doesn't have their own obnoxious signature yetdoug@testsys.uucp (Doug Thompson) (06/01/91)
In article <XmsD32w164w@bluemoon.uucp> (Bryan Bankhead) writes: > I know the coming supremacy of GUI's and VR's is causing stress among unix > freaks, and will gradually invalidate all the time and effort they spent > learning it. But in the world of the future there will just be too much > going on in dataland and it will changing to fast to fit through the > needle (and learning curve) of command line interfaces. GUI's ARE the > future It should be remembered that some of the most advanced GUIs are running on unix boxes. Unix is not an antonymn for GUI. And a GUI access to commands does not in any way invalidate having learned what the command is about. No one can argue against the fact that GUI helps the novice get some functional handle on a new application. Many people will argue that GUI tends to confine the educated user of a familiar application within a restrictive set of limitations. And the user that never learns there is any other way but GUI often ends up spending much longer in repetitive keystrokes/clicks that could be eliminated with a little batch file/shell script. I am not opposed to GUI - though I have seen some implementations that take very simple tasks and make them very tedious - though probably easier to understand the *frist* time one encounters them. I *love* having a GUI on a new application. Makes it easier to learn. I despise not being able to automate specific processes by calling them from a command line in a shell script/batch file. > Doug Thompson's post on virtual manipulation seems to suggest 'why doesn't > everybody just use unix?' It seems to me he has been stuck too long in a > mini-mainframe environment. My perspective on computer use is 180 degrees > from his. I am an inverterate micro user and welcome the comins supremacy > of the GUI. Well you're rather wrong there - I have a lot of DOS experience and a modicum of unix experience, most all of it on micros. Like ever heard of Xenix 286? Or SCO Unix on a 386? I don't think the size of the computer, once you're at the XT with a hard disk level, matters much in terms of how a user interface and operating system should be shaped to do two things: a) make it easy for the user to get at the system with a handful of simple commands and b) make it easy for the user to get at the functionality of all applications and link them in new and novel ways that the programmers might never have thought of. Whether your interface is command line or GUI, UNIX does the latter well. I think my real concern is that users are prevented from understanding and taking control of their computers by some GUI designs. This is not inherent in GUI, it is just a common limitation. These limitations in understanding and barriers to taking control box users in, prevent them from learning (which is different from reducing the learning curve to make use of an application) and leave them in a position of feeling like the helpless victims of the interface designer. Unix may have 400 commands and DOS maybe 50, but the typical user can accomplish a tremendous amount with a dozen and the ability to write simple batch files/shell scripts. For an administrator, the manuals you have to deal with are numerous, yea. For the users, this is not the case in unix. A rather modest amount of documentation is all that is required In DOS, if you know DIR, COPY, TYPE, CHDIR, MKDIR, RMDIR, ERASE, TREE PRINT and MORE with a little about redirection and piping you have the tools to explore and manipulate a DOS file system pretty effectively. Anyone can be taught mastery of these commands in an hour or two. I despair when I encounter users who can't get out of their wordstar menus to the operating system to see what's really there. Menus are extremely handy and I'm *not* knocking their value. I am just trying to point out the fact that the failure to understand or teach the fundamentals of the OS ends up crippling users. And what needs to be learned to give a user a good deal more control over the system is not immense or even difficult. I'm all for user-friendly software. What I'm against is expert-hostile software that assumes the user is an ignorant child and makes sure the user stays that way. But you're right - I think everyone should use unix, and there is good reason to believe that most people will be before too many more years have passed. The NeXt, the ultimate in GUI and networking environments, is a unix shop. Unix unleashes the power of 286, 386 and 486 machines a lot better than DOS or MS-Windows. And hey, I'm not even using vi - or unix - to post this. I'm using MicroEMACS on a DOS 286 laptop running DistNet (UUCP for DOS) software. This message will be shipped out over the modem to another DOS 286 system (running waffle UUCP for DOS) which in turn will link to a 386 running Xenix which will call a SUN running SUNOS (unix), etc. So yes, I live in a world of micros. BIG, MEAN, POWERFUL micros :-). I think the real issue I'm getting at is user education. It is not my desire to make things unnecessarily difficult for beginners, rather it is my question as to whether we programmers sometimes make life harder by trying to make it easier, and in the end *prevent* people from gaining a better understanding of what is really going on, and prevent them from being able to take control of their processes. What you are talking about I think is the value of standardized interfaces between applications so that editing a line of text is editing a line of text - same commands no matter what application you're using. YES I agree wholeheartedly! And when there are a finite number of choices available to you, optionally list those in a menu for the user to select. YES, I agree with you. BUT, when I know exactly what I want to do, which menu options I want to pick, let me write my command line into a command file and execute it with a single keystroke, *please*. And let me automate that with cron functions so that it happens every day by itself from then on without my having to use any interface at all. *PLEASE*. And as for command lines being gobbledygook as you state, or illogical, as others have stated, well they are no more gobbledygook or illogical than Greek or Latin. They are just unfamiliar. And they are *not* that hard to learn for most users, given that very few commands need to be memorized. If you think about the specialized jargon associated with automobiles that all motorists learn, you will find it is a good deal more complex and takes people longer to learn than the minimum necessary set of commands for a user of unix or DOS to gain a great deal of control over the system. I still think our expectations of computers - that they will not just work for us, but that they will alleviate the need for thinking - are dangerous and unrealistic - and in the end destructive. I understand the desire for simiplification - but some things just are not amenable to simplification. I.E. some things really are complex and convoluted and if you are going to deal with them effectively and sensitively you have to have some understanding of the complexities. The average grade four student in Canada has a vocabulary of 6000 words. And there are real limits to what you can do with only 6000 words. A unix sysadmin needs a vocabulary of 400 more. A mere users needs only a couple of dozen for most things. And of course English *is* illogical and it sure looks like gobbledygook to the average Somalian. But if you want to get control and mastery of communication, you need to learn a natural language and you need to learn it well, and you need a lot more than 6000 words! Once again, I'm not knocking GUI as a tutorial device, nor standardization of interfaces. I'm knocking the idea that you can ever reduce complexity and subtlety to a few icons without losing something very important - like the power that is really there. =Doug --- ---------------------------------------------------------------------- UUCP: isishq!testsys!doug DNS: doug@isishq.fidonet.org Voice: 613-722-4724 Fido: Doug Thompson on 1:163/162 POST: P.0. Box 3041, Stn C., Ottawa, K1Y 4J3, CANADA ----------------------------------------------------------------------
isr@rodan.acs.syr.edu (Michael S. Schechter - ISR group account) (06/04/91)
In article <777060869DN5.52@testsys.uucp> doug@isishq.fidonet.org writes: ..much deleted, I believe I've preserved the intent - M.S.@ISR..... >BUT, when I know exactly what I want to do, which menu options I want >to pick, let me write my command line into a command file and execute >it with a single keystroke, *please*. And let me automate that with >cron functions so that it happens every day by itself from then on >without my having to use any interface at all. *PLEASE*. > ..... >And as for command lines being gobbledygook as you state, or >illogical, as others have stated, well they are no more gobbledygook >or illogical than Greek or Latin. They are just unfamiliar. And they >are *not* that hard to learn for most users, given that very few >commands need to be memorized. No.. it's the multitude of options for each command that's a pain. When you have to know 4 or 5 different command-line-based systems and all the commands and options in them, and when a mistake destroys someone else's work, then you find yourself checking manuals every time you use an option. a GUI simply doesn't have this problem. >If you think about the specialized jargon associated with automobiles >that all motorists learn, you will find it is a good deal more complex >and takes people longer to learn than the minimum necessary set of >commands for a user of unix or DOS to gain a great deal of control >over the system. ... But, most motorists spew gibberish when talking about cars, and God forbid they attempt simple maintenance. Operating a car is very simple- there's 9 basic controls and they all provide sensory feedback for the correctness of operation. A command shell usually doesn't give fedback during operation, only at completion, IMHO, it's far harder to learn than a car. >I understand the desire for simiplification - but some things just are >not amenable to simplification. I.E. some things really are complex >and convoluted and if you are going to deal with them effectively and >sensitively you have to have some understanding of the complexities. Why is a GUI neccesarily simple? A well desgned one could give you all the power of the underlying OS. Think of a LabView-like GUI to an OS instead of instrumentation. All the power of commandlines with the ease and intuitiveness of GUI's. true, it doesn't exist yet, but I think it's the way of future. And why assume that ease-of-use and learning implies simpleness? >Once again, I'm not knocking GUI as a tutorial device, nor >standardization of interfaces. I'm knocking the idea that you can ever >reduce complexity and subtlety to a few icons without losing something >very important - like the power that is really there. Again, I think it can be done, and i think if you look at fullblown systems, not stripped freshly installed ones, you'll find that a lot of GUI-based systems let you do much of what you could do with commandline based ones they just call 'em macros instead of scripts. (although theyre sometimes called scripts also). And for the expert who INSISTS upon the ability to access every possible strange thing, well, there's usuallu a commandline interface avilible- (true, you may have to shell out some extra $ (as in MPW for the Mac)). It's not the command lines that make unix powerful - it's the number of applications. Things like printing the first page of every file with extension .c but only those that where created after a certain date and that have the string 'Mike' contained in the first thirty lines have nothing to suggest a GUI coudn't be used for it. I can't remember the exact syntax of unix any more- but you'd want to pipe a grep of *.c's thru ls and then more i suppose, having to remember all those options for each one, or check man for them, and scrolling thru all the pages until you hit the right options.... in my future GUI, you'd goto the "Filters" menu, select content, type in Mike, type in 1-30 for the range, (it would assume the range is in linenumbers and automaically check the LineNumber item for what kind of range when you type 1-30) and click the 2nd Filter butten. The original Filters menu comes up right there, and you select Date/Time and enter your date and "After" which is default. Now click on 3rd filter. and select FileType. You can type in CSRC (or whatever type your c editor uses) or perhaps if it's by extension on a name, the you'd have selected NameExtension for filter type. After this, you have your filter set up, you can save it, install it into the Filters menu, do whatever, then when you want to do this each time, you just select the filter,and then Print or whatever as the action. This woudn't have to be menus- instead of menus you could pull a filter object and slide it into an application's icon, and then "draw" a peice of string connecting one application's output with another's input-selection side. Although, I don't think a "pipes" facility would really be needed. it could be done just be drawing lines, left-sides of applications Icons represent the user-input-for-input-file-selection and right-sides of the icons are an avilible list of files the application opened for output. Any of these could have filters (as above) applied to the lines drawn between them. You could save any of the various file-lists (by teeing off a line to the UserInputSave icon or something - after all these aren't so much file-lists as they are UserInput - they could have who knows what stored in them in the future). To use a saved one later, you just grab it and slide it into an applications icon. (as opposed to double-clicking, which open a specific file with it's default app, or selecting a app. and file, which opens that file with taht app.) This will make that application use that saved set of file-selectors (another name?) and filters. All intuitive, as the choices are there. Not made for children, as you have to know what things mean, but you don't have to waste you time learning the intricacies of a zillion stupidly named progarms and all their single letter named options that are all named incompatibly. And why re-write unix or alias is when the work could be put into writing something as i described. Mike Sorry for the length, but once i got going.... -- Mike_Schechter@isr.syr.edu | XLII,B,+3dB,Non-Nak | Make Tapes, Not War
bmb@bluemoon.uucp (Bryan Bankhead) (06/05/91)
There are a few myths I would like to adress,
1. Text is Flexible
When debating the subject of GI's I constantly come upon the idea that
something is going to be lost in the capacity to do things with the system
because it misses the 'flexibility' of text. Text is not flexible.
PEOPLE primarily communicate in text and PEOPLE are flexible. People can
extract meaning from the most mangled syntax. CLI's cannot. The syntax
use in a complex command line interface requires VERY rigid use. sometimes
subtle errors can derail the whole thing. A lot more is require to use
unix than just the 400 commands mentioned above. It requires mastering a
variable yet quit rigid syntax.
2. Xwindows is a GUI
Sorry dudes but opening a window to type in unix file trash is NOT a GUI.
X windows has the potential to become a GUI but I haven
t seen it happen yet. (maybe it has something to do with the 1000
primitives)
3. You can't automate processes on a GUI
I am using a macintosh program called Microphone which has an advanced
scripting capacity that can be built using a point and shoot GUI method
that is quit elegant. anyone who has so much a programmed in basic can do
the most complex things with it and even if you've never programmed you
can figure it out easily. Designers didn't put this capacity in early
GUI's howver more and more it
s starting to appear. (Mac sys 7.0 has an advanced capability in this
area.)
4. GUI's are for dummies
A GUI can be built to do anything, and allow the learning of complex
operations more quickly. There are several TOTALLY GRAPHIC developement
languages available that generate code in MPW code blocks (Mac
Programmer's Workshop) Anything from a children's control interface to
developement at the machince cod level can be done using the scripting
paradigms on a GUI
A GUI can incorporate all manner of complex an subtle relationships in a
way for mor understandable to a user than CLI's. With a CLI there is
learing in two steps. First learn the language, and then learn what the
language REALLY DOES when you type it in (two different things) With a
GUI you just do something and learn what is does while you do it. Big
difference.
5. We're all going to learn 1 CLI
Fat chance. I was converted to macintosh once and for all when I wanted a
full scale DTP word processor and acquired Wordperfect. When I saw the
HUNDREDS of commands I would have to learn I move to the mac world and
never looked back. Do you really expect the world of computing will
become a one interface world. Unix people in 1980 claimed 40% of high end
micros would use the system by 1990. The actual figure is closer to 5%!!
I think smalltalk is a more likely base for a future GUI, it was designed
for this from the ground up. How many network protocols are there? I
there ONE STANDARD for ANYTHING in the compute world. Havew we moved ONRE
STEP that way in the last 190 years?
This is from
bmb@bluemoon.uucp
bmb%bluemoon@nstar.rn.com
who doesn't have their own obnoxious signature yet