UI: Qs to get the ball rolling

[Chris Harris]

Fare has been making some good progress lately on everything, and it
reminded me that I really should be doing some work on this UI project
I'm supposed to be heading.  =)  I've been trying to come up with an
okay-looking web page myself, but I realized that we need a good deal
more discussion before anything should actually be set out all
formal-like.  So I'm here with a few UI thoughts, and a bucketload of
questions we need to consider.  Replies to any of this would be
most welcome....


First, what IS a UI, anyway?  Is there some part of an OS you can
point to and say, "Ah, this is the UI!"?  To me, the UI is
composed of everything involved with presenting a useful computing
abstraction to the user (aka programmer).  So this could include a
monitor, a mouse or keyboard, a sound card, a printer, a 3D rendering
engine, a speech synthesis program, some interrupt routenes, etc..
The point here is that depending on how liberal you are with your
definition, the term UI could encompass dang near the entire computer.
So the scope of the UI subproject is a bit of an issue.

For an example of the parallels between UI and non-UI things, consider
what Fare has put forward (with pretty good-seeming support)--that the
UI should concentrate more on getting things done, not how to get them
done.  This is obviously very important to a revolutionary UI--if we
want it to be one.  (I'd like that.  =))  But could it not be applied to
other standard functions?  For example, why should programmers have to
re-create algorithms like quicksort again and again?  The C libraries
are meant to get around this, but are hyper-inflexible: with qs,
everything must be the same size, you can't sort structs (without much
difficulty) , etc..  And when you get down to it, why should you have
to specify that you want quicksort at all?  What if a better sort
comes along someday, and your objects are left with calls to the old
one?  (Okay, so this may not be the best example, as sorting
algorithms don't change from day to day, but you get the idea....)
Instead, perhaps you should specify the properties of
the data you wish to sort, and let the system find an appropriate
algorithm?  This same principal can be applied all over the OS.  The
question I have is if there should be some universal way to do so.


Fare says, and I agree, that using = programming, and the other way
around.  Since a good UI's primary behind-the-scenes function is to
pass messages to different objects, and since passing messages is
very much programming, UIs can be looked at as real-time programming
environments.  And just as there are different programming languages, each
suited towards different tasks and tastes, the same should hold true
for UIs.  Users should be able to acess the computer as a text-based,
UNIX-like environment, a 2D windowing system, a 3D, texture-mapped and
rendered world, a fractal or stack interfaced system, an audio-only
system, or whatever.  There should be an extreme level of flexibility
in how users access their machines.

But at the same time, there must be a high degree of standards, so
that a program/object created on one machine will not be totally
irrelivant on the next.  At what level these standards take place, and
how to do this, is a bit of a question.  Assuming our UIs are at some
level event-based, do you write the application around the UI, having
the program call some event-dispatch routene, or does the UI dispatch
events at a higher level to the program?  I'd certainly vote for the
latter--event-dispatch routenes are very non-OO.  I guess we need to
abolish the whole concept of applications, and replace them with
objects of varying integration levels.


Is there a single API for all classes of applicaton/objects--business,
graphics, arcade games, etc., or are different things availible for
different uses?  And is the whole UI API monolithic, like (evil)
UNIX kernels, or is it small and flexible, so that only the necesary
parts are used?  The latter is obviously preferable, but can this be
maintained while maintaining standards?  Stated another way: how can a
UI be even-present enough to provide good standards, while not being
monolithic, and against the TUNES philosophy?


I guess now I should probably present some sort of direction to take
this subproject in, so that we can actually do something.  =)  I guess
one of the first things to know--before what things should look like,
before how the APIs should work--is what classes of apps/objects we
wish to support.  Do we want to cater to any particular kind, or are
we going to be very general purpose?  Are we even going to support any
of the traditional kinds of program?  We obviously need some way to
compose text, for example, but modern word processors--those wonderful
everything-but-the-kitchen-sink programs--are far from the way to
solve the problem.  If we take a more modular approach to things, what
level of modules does the user get to view?  It would certainly be
anoying, in a word processer, to have to deal with each pixel as a
seperate object.  =)


Please comment/trash/agree away....

-Chris


-----------------------------------------------------------------------
"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