barmar@think.COM (Barry Margolin) (04/09/89)
In article <1364@uw-entropy.ms.washington.edu> charlie@mica.stat.washington.edu (Charlie Geyer) writes: >except that not all useful "extensions" can be usefully be done by >adding options to menus. That's why I said "programmable." Any extensions that involve adding new keystrokes to an emacs- or vi-style application, or adding commands to a CLI-based application, can be done by adding options to menus. If the extension doesn't involve the command interface (e.g. it changes the behavior of existing commands) then what difference does it make whether the application uses commands, menus, icons, or direct brain interface? Either it's programmable or it isn't. Just because most Macintosh applications aren't programmable doesn't mean that this is a requirement of menu-based applications. Most Unix applications aren't extendable, either (emacs is the exception, not the rule). Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
austing@Apple.COM (Glenn L. Austin) (04/10/89)
In article <3765@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >I think windows are more generally useful. I have abandoned the icon interface >to my Amiga and written a text/window interface that provides much the same >functionality. > >BUT, windows != icons. I tend to agree with Peter that windows != icons, but in some ways, an iconic interface tends to be easier to use than text. However, you need to spend time designing the icons -- not an easy job for the average programmer. In fact, a lot of times, I call on the expertise of a graphics artist, even though I spent 2 years as a graphics designer while installing a computer system in an advertising shop, oh, about 9 years ago. Icons need to represent what would be difficult to represent in a written language. A good example of this would be an icon for "winding road ahead," or the Mac icon for a notice alert (which includes an "!"). I also spent some time on an Amiga, and turned off the icon interface. Not because it was poorly implemented (it was!), but because the resolution of the screen was so poor that the icons often couldn't be distinguished. The same is true of Gem on anything less than a Hercules or EGA display on the IBM PC. -GLA ----------------------------------------------------------------------------- | Glenn L. Austin | The nice thing about standards is that | | Apple Computer, Inc. | there are so many of them to choose from. | | Internet: austing@apple.com | -Andrew S. Tanenbaum | ----------------------------------------------------------------------------- | All opinions stated above are mine -- who else would want them? | -----------------------------------------------------------------------------
sjs@spectral.ctt.bellcore.com (Stan Switzer) (04/11/89)
In article <4971@pbhyf.PacBell.COM> rob@PacBell.COM (Rob Bernardo) writes: > +I've also seen a lot of effort expended to come up with an icon for 'Help'. > +Those people got mad when I suggested the string 'Help' would do nicely. > In any case, with this distinction in mind, we might rephrase what Walter > Bright had to say as: > > 1. Use only an icon that clearly depicts the intended referent, > or else it isn't a good icon. > > 2. Use an icon if it communicates more effectively than a symbol > purely sign (such as a word or letter). > > In other words, using an icon for the sake of using an icon is not > using an icon for the sake of better communication. [This is an interesting discussion, but I'm directing folowups to comp.windows.misc] The trouble with icons is that they depict things (i.e. files or "closed" windows) reasonably well and actions (commands) rather badly. Sometimes a gesture serves well as a verb, as the "drag a file over the trashcan" style indicates. In general, though, what sense can I make out of a "printer" icon? Will clicking it display the printer queue, pop up an image of a status panel, or ship some file (which file?) to the printer? None of this is *really* self-evident. Don't get me wrong. Graphical, mouse driven interfaces can be quite wonderful. As with any other software construct, it really comes down to the power, predictability, and believability of the illusion of the user interface. All programming is magic, after all: the creation of an illusory reality -- which is why the Model-View-Controller paradigm works so well. On a related note (and one which *does* belong in comp.lang.c), I always wondered why some people put ones and zeros on power switches and others use #defines for ON and OFF. Each practice is equally misguided. Stan Switzer sjs@ctt.bellcore.com
peter@ficc.uu.net (Peter da Silva) (04/13/89)
In article <28836@apple.Apple.COM>, austing@Apple.COM (Glenn L. Austin) writes: > As a programmer who has worked on the IBM PC, VM/CMS, MVS, UN*X, Mac, ect, I > have to say that as a programmer, I had more control over what the user could > do under command line interfaces. As a user I have more control over what the program will do under command line interfaces. I can combine commands in ways the programmer never expected. Because a well-defined and well-implemented command line interface is also a programming language. > Now that graphic interfaces (like the Mac, Windows, GEM) are becoming the norm, > I have to take more care in writing code that doesn't know what order the user > normally works with. When writing a graphics-oriented program I really have more control over the user, because he can't really get to me. I know what sort of environment I'm going to run in. I don't have to worry about input streams coming from strange places like pipes or files. I don't have to make sure that I seperate my error messages from my useful output... it's all going onto the screen anyway. > The user likes this because they have more control over how they use my > program. I, as a user, hate working with a menu-only program that didn't have to be that way. How the hell do you put MacPaint into a script? > (flame on) > I have found that most programmers care only about their programs. ... > this "I know better what the user wants than the user does" attitude of > programming. This is rubbish. It's the graphic interfaces that force me to live in the straitjacket world of what this other dopey programmer thought up. What if I want to do something else while this ultra-cool spellchecker is running over my design document. On UNIX, no problem... just throw it into the background. On the Mac you have to sit there and manually intervene for every damn typo when it discovers it. Repeat after me... PROGRAMMERS ARE USERS TOO. Not only that, but they spend MORE time using software tools than any other class of user. Don't you think they'd have some complaints if your precious graphics were so superior? > Since graphic > interfaces challenge that belief, a lot of programmers are against them. Graphic interfaces reinforce that belief. The user is tied to the environment the programmer decides to allow them, instead of being free to build their own environment using the program as a tool. I have the best of both worlds at home. An Amiga, with a fancy graphics interface AND an integrated programming environemnt called AREXX. You can write scripts that control your fancy menu-driven programs. More and more people are using AREXX as a common macro/command language that co-exists with the intuitive menu-oriented one. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
bruceb@microsoft.UUCP (Bruce Burger) (04/18/89)
> This is rubbish. It's the graphic interfaces that force me to live in the > straitjacket world of what this other dopey programmer thought up. What if > I want to do something else while this ultra-cool spellchecker is running > over my design document. On UNIX, no problem... just throw it into the > background. On the Mac you have to sit there and manually intervene for > every damn typo when it discovers it. I don't think running a spell checker in foreground has anything to do with a graphical interface, just an interactive one. It would be quite simple to develop an interactive spell checker that was not graphical, and vice versa. (As a matter of fact, I've used an interactive spell-checker with EMACS, which is a rather graphicless program!) The advantage of an interactive spell checker is that it lets the user see the context of each word so they can easily correct it, something that's difficult with the plain UNIX spell command. The disadvantages are that you have to wait for the CPU and you have to be distracted with the computer displaying the context for lots of words that you can quickly identify as correct. Apparently most PC software vendors think the advantage outweighs the disadvantages. I suspect they're right, although I agree it would be nice if a word processor had an option to check spelling as a batch background process and produce a list of misspelled words. Anyway, don't condemn graphics because you don't like a specific feature to be implemented interactively. A graphical interface is based on the premise that not all information is best presented or provided textually. When you're driving a car, would you prefer to see a textual description of what's in fromt of you, or look at the road? Of course, it can be overdone, and of course, there are unique merits to a command language. They *don't* have to be mutually exclusive! True, they often are today, requiring a developer to choose between them, but that's changing. As for interactivity, that's another feature that's useful in some situations and not in others. Software technology has a long and exciting road ahead; there are tremendous opportunities for graphics (and interactivity, and command languages) in that world. Bruce Burger
peter@ficc.uu.net (Peter da Silva) (04/18/89)
In article <5518@microsoft.UUCP>, bruceb@microsoft.UUCP (Bruce Burger) writes: > Anyway, don't condemn graphics because you don't like a specific feature > to be implemented interactively. a) I'm not harping on a specific feature. A spell-checker is just an example. There are others... compilers, for example. > A graphical interface is based on the > premise that not all information is best presented or provided textually. b) I understand this. If I didn't, I wouldn't have an Amiga (which lets me use textual, graphic, video, and audio data) now would I? The problem is that not all information is best presented either graphically or interactively... and on the Mac you really don't have an alternative. > and of course, there are unique merits to a command language. > They *don't* have to be mutually exclusive! c) Surely not. Look at X, News, Display Postscript, etc... It's easier to choose if you're not working on a machine that ties every program to the user-interface. Can you imagine a non-interactive application on the Mac (not device drivers or spoolers, but something like a compiler)? Sure, under MPW. Problem is, now you lose the advantages of the graphics interface. Again, the application is tied to the user interface of the machine as a whole. It's not just the Mac... how many compilers run under Microsoft Windows? Well, there's Actor... -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.