UI design considerations

Rainer Blome (rainer@physik3.gwdg.de)
Tue, 31 Jan 95 23:20:39 +0100


the following is a souped up version of a stack of notes on guis that i
took over the past years. stretches of it are more of a philosophical
nature than of an immediately (implementation-wise) useful one, but after
all, the goal is simplicity (as far as it maximizes usefulness), and that
requires this kind of abstraction.

one page of implementation (type-design) i did not type in, yet. this is
the plaintext version of "http://namu19.gwdg.de/rblome/cs/ui.html".

rainer

---------------------8<-------------------------------------------------

User Interface Design Thoughts
********************************

This is an assortment of thoughts about and specifications for a graphical
user interface, especially the window-system. The division of the stuff in
sections like `Analysis' and `Implementation' is inevitably arbitrary and
may in some places not be consistent.

--------------------------------------------------------------------------

Analysis, or, What Is A Window?
=================================

A window provides a view into some space (the contents). It is embedded in
another space, the context.

Although every window seems to be associated with a space, a window should
not possess or even be a space, because a single space may be viewed by
multiple windows.

A window should generally behave like any a graphical object. This implies
especially that it may be put in some contents-space, thus be visible in
another window. (Should that be called a parent? I am not sure if that's
the right word. This kind of parent is dynamic and definitely not unique
since the `child' may be visible in multiple `parent' windows. And
`ancestor' is too awkward. Anybody know a better name?)

A window has a well-defined shape (surface, boundary). Normally we prefer
that the window is flat (thus being defined by its outline) and
rectangular. But for special purposes, it might be circular, bent or
whatever shape you might want.

An extreme generalization would be to allow windows that are themselves
non-two-dimensional. A two-dimensional window stays two-dimensional when
tilted or bent in its context (like a sheet), the perspective on(of?) the
contents would be distorted, though. A three-dimensional spherical window,
however, still seems circular when turned. The view on the contents will
not be distorted, just the direction of view changes. But then, the name
`window' may not be justified anymore, sth like `view' might be more
appropriate. These and one- or maybe even more-than-three-dimensional (how
would these be embedded?) windows would be useful for scientific
visualization purposes.

A frame is not generally required. The frame is used to manipulate the
window itself (move, resize, describe). These operations may be initiated
in some other way (messages alias events). If one is present, it is
definitely a part of the window object and therefore resides in the same
space as the window does.

With scrollbars this is not so easy. They deal with the perspective on the
contents, they manipulate the view (camera), not the display (pane). Since
the camera seems a part of the contents, I prefer to see scrollbars as
being inside the window.

So a window might be composed of two parts:

o the pane and
o the view.

The pane is an object in the context, it looks like a screen that displays
the view provided by some camera in the contents-space. (Imagine tilting
the screen!)

The view ...

Of course the view does not change when the window is moved.

This division of windows in two parts seems undesirable to me, I'd prefer
to have the functions of both performed by (specializations of) a generic
type of window.

(See below under `stickiness' for a possible solution.)

If it is possible to design the system so that even simple graphical
objects (widgets) potentially behave like windows, this would greatly
simplify the whole thing. Because then there would be but a single
abstraction of all graphical objects. The main point here would be to allow
every object to act as a container for others (e.g. a menu is just a group
of flat pushbuttons with the group's frame sloping down by one unit of
height).

--------------------------------------------------------------------------

Design
========

The root window is not resizeable (unless you have a resizeable monitor),
and should have neither frame nor title. (How about motif-style monitor
casings? ;-)

The (virtual) desktop is in the space into which the root provides a
view. A `virtual' (why `virtual' here? Anything `on the screen' is virtual
in a sense) desktop is simply a window on a space that's larger than the
window. I don't even see any problem with dynamically resizeable spaces.

To control the camera one may of course use scrollbars or panners, but also
things like`joysticks' or `direct manipulation' by `hand' (a special
pointer). A difficulty with direct manipulation here is to designate the
`depth' (the `window nesting level') at which one wishes to manipulate an
object. The third dimension would help a lot, here.

Use windows that fill the whole screen (parent-window) for rooms. Select
them by icon or by shuffling them up or down.

Drag'n'Drop:

o How do I organize movement of objects between spaces?
o At what time or at what position does the container of a grabbed object
change?
o Where is my `hand', the pointer?
o Should an object be transferred immediately to the root when grabbed?
o Then how to determine the destination upon release? Drop it into the
`bottommost' window (the window with the `longest chain of parents')?
o Make objects moveable/attachable/detachable

Buoyancy: some objects float at the surface of the space, some sink to the
bottom. They should not fight each other, the last one to map gets on
top/bottom.

Stickiness: some objects may `stick to the glass', they stay at the same
position relative to the window even when the `camera' moves in the
contents-space (e.g. a virtual desktop is scrolled). Since the `glass' is
the surface of the window, this poses a problem with the semantics: the
window itself is supposed to have no connection to the contents of the
space being viewed. And what if two windows on the same space exist? Sticky
objects definitely have a one-to-one relationship with a window.

This may be solved by introducing an auxiliary space for each window for
just the sticky objects that stick to this window. This auxiliary space has
a `transparent bottom' through which the `real' contents can be seen. This
is also the space where the scrollbar resides.

Any number of transparent windows might be stacked in such a way. A
scrolling controller may be connected to just a subset of these layers so
that some layers (usually the topmost and second-most (next-to?) bottom
ones) don't scroll, whereas the others (usually the middle ones and the
bottommost one) scroll simultaneously. This produces the effect of some
objects `sticking to the glass' and some `resting on the desk'.

When this stickiness/buoyancy scheme is applicable for every window, this
immediately allows for different setups (`atmospheres';-) in different
rooms, especially different `wallpapers' (backgrounds) and `furniture'
(sticky objects). Last time I checked, the `surfaces' of the various
virtual desktops/window-managers all`stuck to the glass'. More realistic
would be if the background scrolled with the contents and thus felt like a
part of the space.

--------------------------------------------------------------------------

Implementation
================

One more page to type in, but not now ...

--------------------------------------------------------------------------

Related Work, or, Have a look at ...
======================================

I would like to read a good treatise of the subject of containment and
recursion in GUIs. Any pointers? (The Plan9 paper about 8.5 I know.)

o Generic Window Manager (GWM) and Window-Object Oriented Language (WOOL)
=======================================================================

GWM was supposed to be the emacs among the windowmanagers, being fully
programmable and thus able to emulate any other WM, mwm and twm for
example. I suppose the main reason why it didn't is that it was too
buggy. But the design is still interesting. It is based on a lisp-like
language that manipulates Window-OBjects (WOBs). Each wob is associated
with a finite-state-machine that enables it to handle the X-events.
Among its features are (I didn't check these, I just read the manual):

o Lazy Evaluation: When an object encountered is not of the expected
type but a quoted expression instead, it is evaluated and the result
used instead.

o Representation of lists as vectors: compact, fast and easy to
memory-manage when fully generic consed lists are not needed

o OO: polymorphism, `active values' (feels like method-slots being
indistinguishable from variable-slots)

o Singly-valued symbols (cannot associate same symbol with different
value and function, like in Scheme)

o Reference Counting, NO Garbage-Collection (I'm just describing, not
recommending ;-)

o Statically-typed symbols allowed (numbers only)
o First-class Namespaces
o First-class Finite-State-Machines

It is available via ftp at avahi.inria.fr/pub/gwm (Sophia Antipolis,
France).

o 8 1/2, the Plan9 Window-System
================================

fully supports recursion. Any window can serve as a screen for another
instance of the window-system server. (Marginally ;-) useful for
debugging.

o Fresco
========

supports some kind recursion as well, but I know extremely little about
it.

--------------------------------------------------------------------------