-- DesktopDiscussion.tioga

-- Filed on: [Indigo]<CedarViewers>Documentation>

-- Last edited by: Maxwell on: January 20, 1983 11:04 am

I am looking into writing a replacement for the current Viewer's Desktops. The one that we have now was directed at a perceived need, but isn't quite right yet. There is no rush on this since what we have is adequate, but I want to generate some discussion about what the best design would be. This memo has my ideas about what the needs are. It also sketches some possible solutions generated in discussions with Rick Cattell, Jim Horning and Scott McGregor. I look forward to your comments.

It seems to me that there are two orthogonal issues in the management of the screen's real estate:
 a) switching between different configurations of open viewers (positions and heights), and
 b) rapid access to viewers which are useful but not immediately necessary.

Desktops are an attempt to solve the first problem, icons help with the second. Desktops are useful when you want to switch between independent contexts. You can have a collection of viewers on one desktop, move to another for another purpose and then return to the first without having to open and close a lot of viewers.

Icons allow you to keep track of related viewers without taking up a lot of real estate. For the most part, they are just accelerators; they save you the time it would take to remember a name and type it to the executive. Occasionally they are more than accelerators: when they have some state of their own (new, unsaved versions of a file or open connections to a server), or when they convey information by their very appearance or presence (clocks, alarm clocks, and reminders).

There are a couple of problems with the current implementation of desktops and icons:

 a) A viewer can only be on one desktop at a time. Consequently, the user has to carry shared viewers with him as he moves from desktop to desktop. This nullifies some of the advantages of a desktop since these viewers have to be repositioned on each context switch.

 b) Desktops aren't persistent. When VM runs out, You have to rollback to a previous checkpoint, losing any incremental changes to your desktops.

 c) The "working set" is too small. Usually you have room for 5-10 open viewers and 15 icons on the bottom row. On my screen I have seven "pinned" icons: the EditTool, UserExec, Watch, Walnut, Clock, BBV, and the FileTool. This further reduces my working set. I often find myself creating new viewers on files which I deleted only a few minutes ago.

 d) The bottom row of icons gets cluttered with dead viewers. New icons are then positioned on the second row where they are often hidden by the open viewers. This is bad since the useful icons are hidden while the useless icons take up valuable real estate.

Right now we don't notice these problems very much because we rollback or boot so frequently. But as Cedar matures, these problems will become more annoying. The following are some ideas for doing things better.

Desktops:

The right way to think of a "desktop" is as a configuration of viewers rather than a distinct place. Moving from one "desktop" to another means closing all of the open viewers and opening a collection of viewers into a particular configuration. There would be two operations: saving the state of the current configuration, and opening a new configuration. These operations might be associated with "flying" from one "desktop" to another, or they might be buttons on a special tool. In reality there is only one desktop; all we are doing is reconfiguring the viewers with a single command.

A particular viewer can be in more than one configuration. For instance, there might be a mail-handling configuration which has an expanded view of the Walnut viewer, some MessageSets, and some Messages. In another configuration we might have the Walnut viewer again; only this time it is displayed with its minimal height. This lets us keep track of whether or not there is new mail. Another configuration might duplicate a Message that is pertinent to the work going on there.

Eventually, configurations could be named and stored in the Cedar database. This would make desktops persistent even through rollbacks and boots. For now, desktops would probably only last as long as the current session.

Since there is in reality only one desktop, every viewer is accessible to the user and to programs. This solves the inconvenience of having to bring icons along as you move from desktop to desktop. It also solves an application's difficulty in dealing with viewers that aren't on the current desktop. (A difficulty that has been an irritation in Walnut, for instance.) Unfortunately, it exacerbates the problems with icons since the working set becomes larger. The single desktop must be able to handle the union of all of the viewers that appear in all of the configurations. The first row of icons is already overloaded; something must be added to make this work.

Icons:

One solution to the problem of expanding the working set of viewers would be to have a viewer of viewers. This "ViewerSet" viewer would be much like Walnut's MessageSet viewer: it would be a viewer with a series of buttons each of which represents another viewer. Clicking a button would cause the viewer it represents to be opened. Desktops might be implemented this way, with a button per open viewer in the configuration. In addition a desktop ViewerSet would have a command for opening all of the viewers in the set after closing the current configuration. It might even be possible to invoke this command by selecting the desktop icon and typing a key.

The ViewerSet could also be used to eliminate the clutter at the bottom of the screen. There could be a "Clear" button at the top of the screen which would clear the icon row of all of the unedited document viewers. These viewers would be stored in a special MRU ViewerSet. (Actually, only the names would be stored; the viewers themselves would be destroyed to free up VM. They would be recreated if needed.) If a viewer was closed and the row of icons was full, some of the icons might be automatically pushed off into the MRU ViewerSet. The ViewerSet would save the user time since he wouldn't have to remember or type the full name of the document he was interested in; he would only have to scan some buttons and click the name he recognized.

In addition it should be possible to "pin" an icon in a particular location. This would mean more than just preventing the icon from automatically migrating to the MRU ViewerSet. It would also mean that when the icon was open, its slot would be reserved for it until it got destroyed. Thus the FileTool icon might be pinned in the lower left corner. Whenever the FileTool was iconic, it would appear in that corner.

Hopefully the ViewerSets would eliminate the need for a second row of icons. If not, I would still like the first row of icons to be a MRU cache of closed icons. Old icons would simultaneously migrate to the second row of icons and the MRU ViewerSet. The problem with the second row of icons is that it takes up too much screen space to be always visible. Perhaps there should be a command for raising and lowering the curtain.

Another solution that has been suggested is to reduce the size of if the icons. If the size were to be reduced, the shape would also have to change since it would be difficult to label smaller icons. Maybe icons are just embellished buttons?

Comments?

John.