Rooms: The Use of Multiple Virtual Workspaces to Reduce Space Contention in a Window-Based Graphical User Interface

D. Austin Henderson, Jr., and Stuart K. Card
Xerox Palo Alto Research Center

The idea

Monitors are really, really small. So when people are doing more than a few things at a time, say, writing code, looking up references, and looking at specs at the same time, the screen gets crowded.

The paper discusses a few solutions to this:

Alternating screen usage - switch the entire screen from being dedicated to one app, to another. E.g., Macintosh multitasking.
Distorted views - Involves everything from iconifying or collapsing windows, to overlapping windows which emphasize the important info by putting on 'top' of other windows, to fish-eye distortions where the most important info is dynamically given more screen real-estate (e.g., Elastic Windows...)
Large virtual workspaces - This approach treats the monitor as a small window on a large workspace; this window can be moved around the larger space. Sketchpad, Pad++, and similar systems take this to an extreme, allowing zooming and similar operations to allow overviews of the workspace.
Multiple virtual workspaces - This is the approach outlined in Rooms. Multiple workspaces are not localized in a larger workspace, but instead are allowed to inherit properties from each other.

Analysis of Desktop Information Use

A series of interesting measures are devised to measure and examine exactly what users do when they are working. These were used to establish an idea of window locality sets, sets of windows that are associated with each other and with a particular task.

One of the most extreme of these was a hack whereby windows 'faded' to black when the user wasn't paying attention to them. This allows easier tracking of where the user's attention is focused.

Also interesting was the extended analogy of comparing a user's window manipulations when switching tasks to the swapping a computer does when switching contexts. This allows a number of useful comparisons to be made, and allows the borrowing of a bunch of lingo.

Design

The Rooms system implemented has a couple of basic features, and a bunch of fancier ones. They are all in the system in response to some problem that the authors predicted the users would have:

Problem Feature
Window Management Issues
Crowded workspace Multiple workspaces
1. Sharing tools across tasks Multiple placement of same window
2 & 3. Workspace-dependent shared-window position and presentation Allow differing positioning and presentation of shared windows across workspaces
4. Collections of windows (some windows need to be defined as a collection whose info remains constant across workspaces) Room inclusion - include a portal to one Room in another
5. Carrying windows to other workspaces Baggage - select a bunch of windows when leaving a Room to have them travel with you to the new Room
6. Keeping certain windows with the user all the time Pockets - a special Room which is temporarily included in whatever Room the user is currently in
Navigation Issues
7. Returning to a Room "Back doors" - temporary door that returns user to last Room
8. Get to an arbitrary Room Overview; popup of Room names
9. Identifying windows in Overview Expanding pictograms - when a representation of a window gets mouse focus, it expands in place (see Fig 13)
10. Identifying the connections between Rooms Wiring diagrams - show these connections in the Overview
Manipulating Rooms, Windows, and Doors
11. Creating and deleting Rooms, windows, Doors, etc.

Maintain a normal Interlisp-D environment - i.e., end-user programming;
Window modifications persist across sessions
Popup menu of actions on these objects
Overview commands on these objects

12. Allow implementation of more complex effects by systems programmers Manual editing of Room descriptors - (written in Interlisp-D)

Problem	Feature
Window Management Issues
Crowded workspace	Multiple workspaces
1. Sharing tools across tasks	Multiple placement of same window
2 & 3. Workspace-dependent shared-window position and presentation	Allow differing positioning and presentation of shared windows across workspaces
4. Collections of windows (some windows need to be defined as a collection whose info remains constant across workspaces)	Room inclusion - include a portal to one Room in another
5. Carrying windows to other workspaces	Baggage - select a bunch of windows when leaving a Room to have them travel with you to the new Room
6. Keeping certain windows with the user all the time	Pockets - a special Room which is temporarily included in whatever Room the user is currently in
Navigation Issues
7. Returning to a Room	"Back doors" - temporary door that returns user to last Room
8. Get to an arbitrary Room	Overview; popup of Room names
9. Identifying windows in Overview	Expanding pictograms - when a representation of a window gets mouse focus, it expands in place (see Fig 13)
10. Identifying the connections between Rooms	Wiring diagrams - show these connections in the Overview
Manipulating Rooms, Windows, and Doors
11. Creating and deleting Rooms, windows, Doors, etc.	Maintain a normal Interlisp-D environment - i.e., end-user programming; Window modifications persist across sessions Popup menu of actions on these objects Overview commands on these objects
12. Allow implementation of more complex effects by systems programmers	Manual editing of Room descriptors - (written in Interlisp-D)

Conclusions

"...a major purpose of research into human-computer interaction is to discover and analyze key constraints that are drivers of human performance and to use the representation of the problem glean from that analysis as tools for thought in design."

My thoughts: Most of these innovations have not seen implementation in any current systems. This, of course, is not a reflection of their lack of usefulness.