More UI Thoughts

[Chris Harris]

As Fare has proposed, I think the UI project ought to become the I
(interfaces) project, responsible for the interaction of humans and
computers, humans and humans, computers and computers.  I guess that
would, in a sense, make the HLL a sub-project of the I project, but
managing them seperately for now will probably work, considering the
amount of work involved.

Despite all this wonderful talk, this message will be dealing mainly
with the UI, as I don't yet have some cool sort of vision to tie the
entire I project together.  (Any of you with large brains and much
time to ponder this can feel free to help....)

Most of my recent thoughts have been about what sort of objects a UI
would be composed of, and how it would integrate with more low-level
objects (things that would traditionally be the kernel).  This is all
a bit of a paradox to me, in that we want to both maintain consitancy
and have everything decentralized, but I guess it may work out in the end.

Here's just some thoughts on a number of things.  Please bring up
anything you feel needs to be discussed.

--

At the lowest level, a Tunes UI would probably be pretty standard,
consisting of device drivers for the availible audio/video/VR/whatever
equipment.  The hardware should be directly accessible, for times
when extreme speed is necesary, but this should have security
checks, and there should also exist higher-level toolkits for doing
most things, both to save the programmer time and to make everything
more compatible.  Might be toolkits for playing an audio piece,
drawing arcs and polygons, displaying movies.  Anything, really.

--

When you log into a UNIX machine, you are presented with a shell
program, which is responsible for letting you do stuff.  This won't
work in TUNES, since we won't have the whole application concept.  But
having your own login object is still a neat idea.

So when you log in, I think an "abstraction manager" should be
associated with your account.  Such a manager is responsible for
providing a certain UI abstraction, by transfering
low-level (or perhaps not so) events into messages useful to other
objects.  Abstraction managers might present an abstraction like
current unix text mode interfaces, X windows, some VR game, or
whatever.  And an abstraction manager can use any part of the system
it needs to present the abstraction: the raw hardware, bare
minimum drivers, or complex libraries.

An ideal abstraction manager would be highly modular, so that its
pieces are easily replacable, and the whole thing should be replacable
if necesary.

There should also exist a standard way to create abstraction managers,
so that one abstraction might be enclosable within another.  (Example:
running a unix shell in an x window)  In this way, people can stick
with their prefered environment most of the time, but still be able to
access the neat features of other abstraction managers.

--

Each user has assosiated with him/her a preferences area, where
(s)he can set options for all the various objects.  We could have each
object keep track of its own prefs, but that would be a lot of
re-coding, something we want to avoid.  Actually, the prefs area
probably isn't all that special; just another I toolkit...

--

What is a user to TUNES?  Well, right now, it looks as if the machine
could just assume user = abstraction manager + preferences, and not be
too far from the truth.  Is this something we want to change?

--

Each logical object that can be used for user input/output (ie
integers, complex numbers, graphics, spreadsheets, word processing
snippets) must be connected to one or more "I/O Managers".  Such
managers are responsible for presenting the data represented in
that object to the user, in a way consistant with his/her availible
abstraction managers.

Each I/O manager is responsible for interfacing
with a single abstraction manager.  If an object has more than one
manager attatched to it, the user is allowed to choose which they
would like to work with by default.

In order to input/output data, an I/O manager may call on other
objects to perform I/O, in turn activating their I/O managers.  

--

Question:

Current GUIs have a pretty useful concept where one on-screen object
can enclose a number of others, and all can be dealt with at the same
time.  (Sorta' like windows/widgits in X)  Should such a visual
hiarchy be around in the TUNES UI?  How would that idea carry over to
a text or audio based environment?


-----------------------------------------------------------------------
"Ignorance is bliss, but where do you get the idea that knowledge can't
be even better?" -- me (Chris Harris <chharris@u.washington.edu>)
Check out my web page: http://weber.u.washington.edu/chharris