csc (06/11/82)
As promised in the preceding item, herewith is a compilation of personal
communications relating to window management strategies. I was fortunate
to hear from quite a number of people, so this may well be a good summary
of the current state of things. The answers I received were, however,
somewhat oriented to a specific question I asked: are overlapping windows
useful? I also asked for details on window cataloguing schemes.
Henry Lieberman at MIT-AI:
I've used 2 systems incorporating overlapping windows: the Lisp
Machine at MIT and Smalltalk at Xerox PARC. It's a sexy feature,
but I and others don't find myself using it as much as might be
expected. For situations where you want to share screen among
several programs, some "window made of windows" construct seems
better (Frames in the Lisp Machine, PanedWindow in Smalltalk).
Overlapping windows are good when the screen layout is more dis-
organized; you want to pop up temporary windows, etc.
Paul Johnson at MIT-XX:
My own feeling on overlapping windows is that not providing them would
greatly limit users' flexibility in managing their own work space in a
manner that suits their work style. Forcing non-overlapping windows on
people is not that great a step forward from our glass tty's..
Tim Rentsch at USC-ECL:
I think you would like overlapping windows if you tried 'em. It seems a
common (intellectual) reaction to prefer the non-overlapping kind, but
after an hour of use you will probably be convinced. The problem with
windows that don't overlap is that there is NEVER enough room on the screen
because there is always something of global importance that is of little
local importance. This is not something that most computer users have
been exposed to, since most computers are heavily into modes.
Jim Guyton at rand-unix:
[who wrote the original window package for the Star] ...Nothing ever
published unfortuneately; there were some nifty ideas used for screen/
window management. For example, an "algebra of rectangles" developed
for adding/subtracting rectangles and a relatively easy method of
hiding window clipping problems from the programs that live in them.
Cluttered windows: A good window system should allow the user to have
as many windows as wanted-- and no more. One thing that is still debated
within Xerox is what to do upon opening a window-- should all the other
windows make room for it (to minimize overlapping windows) or should the
new window just go on "top"?
Star took the first approach. The major windows (that were expected to
stay around for a while) were allocated a large chunk of the screen. If
there wasn't room, then all the major windows were shrunk a little and
moved in order to make room. There was (at least initially) a limit of
how many of these windows could be up at once. Advantage: usually
does the right thing and frees the user from always having to move/size
new windows. Disadvantage: may spend too much real time doing something
"nice" for the user that isn't really what is wanted.
Other programs have taken the other approach. While much more flexible,
people have complained that they spend a lot of their time setting the
screen up to be exactly what they want.
The basic problem of course is coming up with one set of rules for what
everyone wants in a window package. What I'd like to see is a
"profile-able" window package-- such that I can supply the rules.
Bruce Hamilton at Xerox PARC:
Re overlapping windows: Star doesn't have them, but the Mesa development
environment that we use to create Star does, and I love it! [Regarding
the inquiry on] "cataloguing schemes": each window has three states:
big, tiny (an icon about 1/2" square) and deactivated. A tool can be
quickly changed back and forth between the tiny and the big states by
clicking the mouse in the top of the window, and preserves all its internal
state. A tool can be deactivated by bringing up a window manager menu and
selecting "deactivate". A deactivated tool may lose much of its internal state.
It gets put on the "inactive" menu which can be called up whenever the mouse
is outside all windows. I like the fine control of being able to grow and
overlap my windows arbitrarily. It is true that tools in the tiny state
may tend to get lost. Tiny windows can be moved around but by default they
go to the bottom of the screen and don't overlap (unless they've been moved).
All this is much easier to demonstrate than to talk about.
Larry Rosenstein at MIT-XX:
[I am working on a display manager for the Etude office workstation, as
a Master's thesis.]
[Because of limited time and hardware resources] our model of windows is
NOT the conventional one of arbitrarily overlapping windows. We also wanted
to avoid as much inherent overhead as possible, in order to get adequate
response time from the system, and felt that a simple display model would be
adequate (whether this is so still remains to be seen).
Part of the reason was philosophical. It was not immediately clear that
overlapping windows are needed in an office workstation (as opposed to a
general purpose programming workstation). I think that goals such as
response time and consistent display layout are more important to office
workers than the ability to control the screen layout precisely.
In our workstation, windows can be created anywhere on the screen, but the
system does not automatically resolve conflicts between overlapping windows.
What we do is dynamically change the size and position of windows, so that
they do not overlap. Each application can create whatever windows it needs;
in Etude, for example, there will be one window for each element (text
column, figure, etc.) on a page and the windows are arranged to model the
desired page layout.
The system takes care of creating "top-level" windows for new applications,
menus, and help information. For simplicity, these top-level windows are
constrained to use the entire screen width. [Thus, the user sees] horizontal
bands, each containing a different application, menu, or help message.
(This approach also avoids horizontal scrolling when an application's window
is too narrow. If you think about it, most applications are more sensitive
to their windows width than its height-- if the window's height decreases,
the application simply displays fewer lines.)
[When a new top-level window is allocated, existing top-level windows are
shrunk to create space, and the corresponding applications are notified of
their new window sizes so that they can act accordingly.]
The Xerox Star does support overlapping windows, but does not allow windows
to be arranged arbitrarily. Different types of windows appear in different
positions, by default. [Usually windows are designated by the user to
appear in one of two columns. Users may also specify the distances between
windows.] ...Menus that were associated with a window were an exception---
they appeared in one corner of the window. One disadvantage ... (and
advantage of arbitrary screen layouts) is that the user must develop
[an icon-organizing methodology] because some parts of the screen are more
accessible than others.
~ ~ ~ ~
Again, thanks to all, mentioned and not, who sent in material.
For those who are wondering why I'm interested in all this, I am currently
working for the Software Portability Lab in the Department of Computer
Science at the University of Waterloo, which is developing
general purpose, reasonably portable, workstation software. All software is
written in "Port" (a direct descendant of the UW language "Zed", itself a
BCPL descendant) and makes extensive use of a message-passing kernel.
The user interface, certainly the most heatedly debated part of
the software, is still in its early stages and not well defined yet. The
goal is to develop something that will be easily learnt, allow applications
all the freedom they need, and run reasonably on an 8086 Multibus machine.
I will try to get something on the net about it when it becomes more
interesting.
peter rowley, u. waterloo, (decvax!watmath!csc)