> mouse navigated and operated Frames are the most common and well
> known way of communicating with an application.
This does not, however, mean that it's /best/ way.
> They are the closest thing to the real world applications can offer in
> terms of human computer interaction.
The real world metaphor is usually not the one you want to use in
designing an application, and many people fail to remember this. (See
http://www.iarchitect.com/mshame.htm for a few examples of why.) In
general, my computer can do things myRealWorldObject can only dream
of, and make possible things easier. Playlists are a good example of the
latter, where one can drag & drop song titles to order them, something, so
far as I'm aware, that one can't do even on the rare stereos that /have/
playlists. With respect to the former, nobody would dream of writing a
text editor today with the functionality of only a typewriter, because
there are so many things the computer can do that the typewriter can't.
The same for spreadsheets; the same for (e)mail applications.
Realism in games serves two purposes: one is to render things
recognizable, and the other is to provide a set of rich and consistent
interactions among those things in the game. That is, an accurate
simulation allows for and limits you to the range of real-world
interactions. For shooters, the rules are typically bent (impossibly good
armor) to flatten the learning curve and prolong the game, but such bends
don't alter the expectation that jumping off a bridge will cause you to
fall. For adventure games set in the here-and-now, a fully accurate
simulation would the Holy Grail; the designers would then set the scene
and the game would almost write itself. (Not that a fully realistic scene
of any size is /easy/ to set, but anyway...)
So realism doesn't sound too bad. But let's look at two
things: the flip-side of games and applications. The flip-side of games
is quite simple: the extent of your (kinesthetic) interaction is the
keyboard & mouse, and possibly a joystick/wheel/pedals. For shooters,
where you're running all the time and carrying eighty pounds of gun and
ammo, this limit to the kinesthetics is a Good Thing. For the adventure
game, it's probably not, because it makes it that much more difficult for
the player to manipulate the enviroment. (That is, most interface design
in adventure gaming is an attempt to make what limited interactions are
available as easy and 'intuitive' -- consistent -- as
possible.) Similarly for applications. For many big problems, I prefer
the hardcopy & table route, simply because my monitor isn't large enough
to display as much information as I want simultaneously. There is no way,
(at least on /my/ system) to flip through a document and see a full page
at a time; to organize those pages such that the ones I need to reference
are no more than a shift of eye focus away; to incorporate a
(reference) book as one of those reference pages; and so on. On the other
hand, copying and pasting between the documents on the table is so
time-consuming as to be effectively impossible; I won't hear a beep when I
mis-balance my parentheses; I can't add a column of numbers up by writing
'=ADD(A1,A10)' at the bottom; and so on.
To repeat myself: my computer can do things the 'Real World'
can't, and vice-versa. I can interact with the 'Real World' in many more
ways than I can with the computer, to the detriment, usually, of the
computer. Generally, the mouse and keyboard themselves are not 'Real
World'-intuitive objects. The sense of an interface being intuitive is
that it's consistent enough that you can predict how to do something, what
will happen when you do it, and that everything you might want to do is
allowed. That is, single-instance cut/copy/paste is not and more or less
intuitive than a stack or queue-based cut/copy/paste -- it's just simpler,
in that there are fewer things to predict. (Now that I think about it, a
queue-based cut/copy/paste could come in really handy...)
The goal of standardization in an interface is to reduce the
number of rules you need to know in order to predict (know) what happens
when; once you've learned 'minimize', 'maximize', 'restore', 'close', and
'iconify' for one window, you've learned it for all of them. There is
less to predict. (This is why people don't like windows with non-standard
controls -- it adds more things to know.) This is an argument for using
the standard WIMP metaphor; the question is if there is another metaphor
whose ruleset is sufficiently smaller to make it worthwhile. An example:
I, personally, find having three mouse buttons much better than one (or
two), because the meaning of each button is more narrowly defined (and
that the sum of those three narrow definitions is larger than the sum of
the wider one or two button definitions). Apple seems to think that the
conceptual simplicity of having a /single/ action is worth the
complications of having that action potentially mean many things.
Because Apple's single button mouse has fewer actions, it's more intuitive
in the sense of having fewer rules governing its usage; conversely it
could also be argued that increasing the number of ways in which one can
interact with things -- (possibly reducing the rules per action) -- is a
trade-off of sufficient importance in allowing one to do more things --
'everything that you might want to do' -- to be worthwhile. (For example,
and leaving aside for the moment the question of whether or not
context-sensitive menus are intuitive -- is it more intuitive to access a
CSM with a mouse button which (almost) never means anything else, or with
and action -- click and hold -- which means different things depending on
if you move the mouse or not?
Most of the burden of intuitive interface rests with the
application, rather than the operating system; as I said before, a
function of the operating system (interface) is to allow applications to
do 'Good Things' w.r.t. to interfaces. (The other primary purpose is to
make things easier/better for the application programmer -- the display
server, the window manager, the 'everything is a file' abstraction, etc --
are enablers of better applications by upping the level of
abstraction; the idea of embedding is similar, that only applications
whose goal is to do X need to be concerned with how to do X -- that if
doing X is part of an application, how X is done is not terribly
important. (X, for example, being to display a jpeg file.))
I just said that most of the burden of intuitive interface rests
with the application, which is certainly true with current WIMPs, but may
not be true in general. It could be argued that in a system with ONLY
embedded applications that the largest part of the interface rests with
the OS component which provides the thing(s) in which to embed. Other
configurations may be possible; it's not unreasonably to difficult to
envision a system where every part of every UI is scripted by the user, so
that the burden of intuitive design falls to him (her).
In sum: shouldn't a next-generation OS have a next-generation
interface?
-_Quinn
P.S. Regarding the ideal interfaces you suggested -- I believe that all
of them are AI-complete problems, at the least...
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
