Description Kevin McGuire 2006-08-17 18:07:38 EDT

The current min/max behaviour isn't very useful for typical usage.  The problem is that most tasks require access to information in more than one view. Maximizing a given view or editor prevents access to the other necessary information.  

For example, consider the simplest starting point of Navigator-Editor-Outline.  

Task (A): First, you need to navigate to the item you care about.  We'll call this task "Finding".

When browsing through the navigator, one needs the editor to see if the item you've selected is the one you're looking for, but you generally don't need the Outline.  So you'd like more space for the Navigator, medium for the Editor, and little or none for the outline.  One solution is to minimize the Outline.

Task (B): Now you want to modify the item you found (say, edit the Java class).  We'll call this task "Authoring".

Once you are editing, you'll want more space for the Editor, and you no longer really need the navigator, but you do require the outline.  One solution is to minimize the Navigator.  But if you followed the steps above, you must now also restore the Outline.  Note that maximizing the Editor won't give you what you want because you require the Outline (you may decide to live without outline because its easier than doing the require sequence of min/max).

A common sequence is one of Finding, Authoring, Finding, Authoring, ...  
Using current min/max support, the user must spend a considerable amount of time just manipulating the UI, which quickly becomes tedious.

Fast views are one solution but they have their own limitations.  In our example, using the Navigator as a fast view causes it to cover the very Editor whose contents you must check to see if you've navigated to the right item.  Because fast views obscure the workbench, they are generally only suited to highly modal finding where all the information required is contained in the Fast View itself.