Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!yale!cmcl2!uupsi!rodan.acs.syr.edu!isr From: isr@rodan.acs.syr.edu (Michael S. Schechter - ISR group account) Newsgroups: comp.society.futures Subject: Re: Virtual Manipulation Message-ID: <1991Jun3.204619.4949@rodan.acs.syr.edu> Date: 3 Jun 91 20:46:19 GMT References: <777060869DN5.52@testsys.uucp> Distribution: na Organization: Institute for Sensory Research Lines: 105 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