jhs@MITRE-BEDFORD.ARPA.UUCP (03/08/87)
Here's my 2 cents' worth on the subject of where Atari should go with future
products, specifically in the user interface area. First, some general
principles I believe in, based on 25 plus years of thinking (off and on) about
user interfaces and occasional consulting with some heavy-duty experts in the
field:
1. Diversity Principle. Or maybe "Diffr'n't Strokes" principle. People
don't all like, or work well with, the same kind of user interface.
Also, not all tasks lend themselves equally well to any given style
of interface. Some people LOVE icons, some HATE them. Same for
old-fashioned menus. It can be hard to express certain nuances,
parameters, etc. with icons. On the other hand, sometimes they are
the best way in the world to convey meaning to a user, especially a
(computer-)naive user. And it's hard to beat a command language for
conveying all of what you REALLY mean all at once, if you're an expert
in the full power of the command language. (Assuming it is designed
to HAVE some power!)
2. Learning Curve Principle. Users DO learn (some of 'em). It is by now
recognized even in hobbyist BBS systems that an "expert" mode and a
"novice" mode are highly desirable. Maybe even some kind of automatic
downshift would be useful.
3. Sorcerer's Apprentice Principle. It should ALWAYS be possible, easy,
and obvious how to abort any action non-destructively. The means should
be obvious both to the expert and the novice.
There are a number of other ones I like to preach, but that will more than
suffice for now. The point is, there is no one right answer, and any system
that locks the user base into one way of doing business is going to disappoint
some users badly.
It seems to me that with the ST line, Atari has really caught the fancy of
the knowledgeable computer scientist types (witness the sophistication of
postings in this Digest, present company excepted). They have also pretty
much one-upped the Mac in icon-oriented interfaces, among other things,
certainly prior to the appearance of color on the Mac. They stand to pick up
a LOT of market share in those two areas if they do things right. It looks to
me as if the novice-user and graphics-oriented user is pretty well supported,
but better support for a fully flexible command-line interface for the expert
user/developer would be a highly valuable addition. Unix would be ideal, or
something unix-like that didn't involve large fees would probably be even
better. My vote would go with the unix-like shell as the "true personality"
of the sytem and the graphics oriented shell as something built on top of, or
parallel to, the command line oriented one. In that way, developers (who had
BETTER be expert) and expert end-users would have full flexibility, but casual
or non-technical users could still be provided with a simple-to-use interface.
I don't know much about operating systems, but I must admit that one line out
of Kernighan and Pike ("The Unix Programming Environment", Prentice-Hall 1984)
really seems to me to be good advice in designing systems of any kind: "When a
more complicated structure is needed, it can easily be built on top of this
(speaking of the Unix file system -- JHS); the converse, creating simplicity
from complexity, is harder to achieve." Now THAT is a profound statement.
-John Sangster / jhs@mitre-bedford.arpa