Half-baked UI goals/proposal

[Chris Harris]

Here's some half-baked thoughts on the UI stuff.  If anyone wants to rip 
it to shreads, feel free.  As for me, I think its time for bed.  =)

-Chris

UI Project
==========
Coordinator: Chris Harris
Members: 

Purpose: To create a (set of) user interface(s) for the TUNES project.  Note
         that UI includes every aspect of user interaction, and not just
         some pretty little pictures.

Goals/Proposal
==============

    We don't know where UI technology will be going in the next few years, so
its best to keep an open mind/API where the interface is concerned.  Therefore,
I propose a modular UI system.  When a user logs in, he(r) is presented with
a primary UI of their choice.  Their interaction is then funneled through
this UI from the programs they wish to run to the native hardware
    Eventually, though, its likely that the user will run into a program
which does not support his/her primary UI.  If this is the case, a secondary
UI will be loaded, and allocated display space within the primary UI.  Totally
incompatible programs cannot be run, and will result in an error.
    Such a system could certainly be expandable enough to enclose any sort of
UI we might need, and with enough standards, there might not be too much
incompatibility.  If things are thought-through enough, it might be possible
to have the same APIs for a 2D or 3D program, and let the user switch
between the two at runtime.


    With that said, there are some goals that each UI module should try to
accomplish:

1. Easy to use - Attractive-looking systems are great, but if there isn't a
     productive way to get something done, people won't like it.  Each
     availible UI should have some sort of purpose and/or specialty.

2. Attractive/Fun to use - A UI should obviously have some human appeal to it,
     weather its because its powerful, elegant, or whatever.

3. Minimal abstraction - The OS will be designed well enough (Right guys?) that
     that the higher-level internals of the system will be logical enough for
     the user to understand.  Why now present it to him/her like it is, then?
     (Note: this is a general rule; certain UIs may better accomplish a certain
     problem via abstraction.)

4. Easy to learn - This one's a big tricky, since it can violate goal #1 in
     some cases.  If we don't go out of our way to make it difficult, we'll
     probably be fine.  =)



"If patterns of 1s and 0s were 'like' patterns of human lives and death,
if everything about an individual could be represented in a computer by a
long string of 1s and 0s, then what kind of creature would be represented
by a long string of lives and deaths?"  --Thomas Pynchon