Request For Comment: Loss of Context

["Dirk Baeumer/ZRH/OTI" <Dirk_Baeumer@xxxxxxx>]

Hi,

enclosed a new proposal.html containing my comments. The are marked with
<db>
</db>

Dirk
|------------------------+------------------------+------------------------|

|                        |   "David               |
|
|                        |   Springgay/OTT/OTI"   |           To:
|
|                        |   <David_Springgay@oti.|
platform-ui-dev@eclip|
|                        |   com>                 |   se.org
|
|                        |   Sent by:             |           cc:
|
|                        |   platform-ui-dev-admin|           Subject:
|
|                        |   @eclipse.org         |   [platform-ui-dev]
RFC|
|                        |                        |   - Loss of Context
|
|                        |   20.11.2001 21:59     |   Proposal  (end date
|
|                        |   Please respond to    |   = 11/27)
|
|                        |   platform-ui-dev      |
|
|                        |                        |
|
|------------------------+------------------------+------------------------|










Please provide comments on the following proposal by 11/27. This is not a
call for committers to vote.

(See attached file: Proposal.html)


(See attached file: Proposal.html)

Title: Request For Comment

Request For Comment: Loss of Context

Topic: Loss of Context
Last Modified: Nov. 19, 2001

<db>
Dirk Baeumer: my comments in blue
</db>

Executive Summary

In this proposal we describe a problem known as "loss of context", and
propose some solutions to it.  Loss of context occurs when a user
doesn't know where they are in the UI or where to go in the UI to complete
a task.  It is commonly caused by object actions that differ between
views, perspectives / views which open unexpectedly, programmatic focus
changes, menu items which vary with the active perspective (File > New,
Perspective->Show View, Perspective->Open, ...), perspectives which do
not fully support a task, etc.

To solve this problem, we broke it down into smaller problems, and dealt with them individually.  The problems and the solutions are described briefly here, and then discussed in detail in later sections.

The actions in an object context menu, or in a perspective, are often inconsistent.  To solve this we will:

1. implement a global MRU list for the contents of the Perspective > Open menu.  This makes it easier for switch from one perspective to another and back.
2. expose the action classes in the navigator for reuse within ISV views.
3. implement an IAdaptable mechanism in the popup menu extender, so that IResource actions will appear on non IResource objects which return an IResource through IAdaptable.
4. correct the ordering of action extensions, so that actions appear in the order defined, not the reverse.  This will be done in a non breaking way.
5. define a standard template for context menus and then encourage ISV's to use it within their views.  The standard groups might be "new, navigate, open, cut, copy, paste, delete, team, other, properties".

Many developers find that the action extension point criteria for enablement
is too weak, so we will:

1. instantiate every action delegate in a plugin when the first is invoked.  In the past we failed to do this unless a selection was made.
2. add new features to the extension point for action enablement.  For instance, the filter element may contain tag names for system properties, installed plugins, and platform properties (which are set by other plugins).
3. add the ability to define a negative enablement.  For instance, you may say "if not nature", "if not installed plugin", etc.
4. encourage ISV's to use the project nature as a way of targetting actions to an object.

Label decorators, like the VCM version #, should be shared,.  To achieve
this we will implement a decorator extension point, similar to the popup
menu extension point, which can be targeted to IResources or other objects.

The default behavior for Open Perspective is currently "Open New Page in Window".  The creation of a second page in the same window often leads to loss of context ("where did my editors go?", "where did my data go?", "where did my perspective go?").  To resolve this, we will:

1. change the default mode for "open perspective" to "replace".  In this mode, the "open perspective" menu item in the Perspective menu will be removed, and a drop down list box containing a perspective list will be added to the toolbar.  If you select a perspective from this list, the existing views in the perspective / page will be re-arranged to suit the new perspective.
2. implement a perspective reuse strategy to reduce the number of pages in the workbench.  This will be based on the VAJ experience.  If an object is opened once, you get a page.  If the object is opened again, and a page is already open, the old page is activated.
3. encourage the use of multi-window mode for perspective creation rather than multi-page mode.  In combination with the other changes listed, this mode will only be apparent to people who open a new perspective using "Open Perspective" in the Navigator.

Many complaints have been made about intrusive behavior in the platform. 
For instance, if a selection occurs in one view it is not uncommon to select
and reveal the object in a second view.  This leads to loss of state
in the second view.  Users are also confused when a view appears unexpectedly,
or for the wrong reasons. For instance, if the console view appears with
a normal status message, users don't want to see it.   To deal
with this problem we will publish UI guidelines.  The first draft
of these guidelines is due soon.

Finally, we will use the UI guidelines to clarify the use of views, editors, and perspectives.  The development of a clear heuristic for their use will lead to a more integrated, intuitive (consistent) platform.

These ideas will be available for demonstration in an upcoming version of the platform build.

---

The Problem

Based on our own interviews, and feedback from external teams, we found
a number of scenarios where people lose context. This section briefly describes
each problem; subsequent sections propose solutions.

User Issues (in prioritized order)

1. Action Loss: There are many actions which appear in one perspective, but not in another, or in one view, but not in another.  The missing actions make it difficult to start / complete a task.  Often users don't know where to go to regain the missing actions.
• many project actions appear in Navigator but not in Packages view.
• many of the standard resource oriented actions are missing from ISV views.
• one team derived a new Java source editor from the existing one so they could add "promote to remote interface" (via the popup context menu in the outline view).
• the implementation of drag & drop, delete key is often missing from special views because it must be manually added. Attempts to encourage consistency have met with failure due to tight deadlines (since it's not trivial work for the special views to accomplish these).
• the actions available for a file in the Navigator often differ from the actions available in different views where the same object is visible.  Is it possible to define a set of rules, or a model, so the user can predict where actions will be?  e.g. in the outline view, editor, view?
• an action may appear in two views, but have different semantics.  For instance, rename in navigator is different than rename in packages view (which does refactoring).
• the PDE perspective has no run/debug buttons, so you can't launch your plugin.  You have to find the correct perspective somewhere else or know about the customize action.
2. Menu Ordering: within context menus the items are ordered by plugin order.  Several teams have asked for some sort of ordering feature.
• developers complained about "the inability to order the popup menu items". To the end users, the inconsistent ordering of undo/redo/delete seems "unprofessional" or annoying.
• sample: "add annotation, add unique, add key, delete, undo, redo"
• sample: "add element to content model, add group to content model, undo, redo, cut/copy/paste, delete".
• the following ordering appeared in the Navigator for a .xmx file: "..., generate XSLT, Team >, Compare With >, Replace With >, Apply XSL >, ...".  The XSLT and XSL actions should be grouped.
3. Decorator Loss: the version # decorator should be propagated to other views, not just the navigator view
4. State Loss due to linking:
• many users are annoyed when the data within a view changes for unclear reasons.  The navigator and packages received the most criticism.  These views are often used to maintain the working set of files.  If you activate an editor they will select and reveal the resource.  The working set is lost and the visible content is expanded, overwhelming the user.
5. State Loss due to perspectives:
• users complain that the state in one perspective is not reflected in others.  For instance, the Java Perspective is currently not synchronized with the Debug Perspective (i.e., the Debugger may be stepping through a particular line of code and when the user moves to the Java Perspective, s/he must then take time to navigate to the appropriate location of source).
• the ability to open an editor in more than one perspective, and the inability to get back to it from another perspective, leads to loss of editors, creation of extra context and potentially loss of work.  This problem is aggravated by perspective change: open editors are not carried between perspectives.
6. Perspective Activation Causes Disorientation
• the user is thrown off by unexpected perspective activation.  This is aggravated by an inability to discern the active perspective, the subtlety of perspective activation, and an inability to return to previous perspective easily (for example, some users prefer to be automatically put back to where they were after the program terminates in the debug perspective).  Perspective change also leads to action loss.  This may be reason for emphasis on action loss above.
7. View Activation and Opening
• users are confused when a view appears unexpectedly or for the wrong reasons. For example, if the console view output is a normal status message, users don't want to see it.  If the console view opens at this time, users are confused why it's shown, annoyed by the "intrusion" and by the re-layout of the perspective it causes. On the other hand, if the console appears when there's an error message shown in red, to let users know that a server has crashed, this is useful context information, and users would appreciate it.
• a number of users complained that relayout causes confusion if new view appears.
8. Accidental Layout Change: many users are annoyed if you click on a view and it shifts position.
• if you click on the title bar of a view, and then move your mouse to access the main toolbar or menubar, sometimes you don't release the mouse button fast enough.  In this situation a d&d is started and a detached window is created.  Unfortunately, sometimes the detached window looks a lot like a view within a folder, so you may not notice it until much later, after you do some other actions, and the floating window manifests itself.
• if you click on a view and then drag it, there is no obvious way to cancel the drag just by putting the view back where it came from.  This creates a floating window, which you have to redrag to regain the original layout.  This also occurs with folders.
• users find it difficult to add views / folders to the workbench.  For instance, if you have a view in the top left corner and one in the bottom left, you can't drag another view to occupy the entire left hand side of the window.
9. Confusion about Existing Perspectives:  It is never clear which perspective to use.  This is the most apparent when you compare the Java and Resource perspective, and the Resource and Team perspective.  These perspectives are all very similar.

We derived the following issues from developer feedback:

11. Action Enablement: plugins don't have the ability to verify that certain actions are not applicable and thus remove them.  This is a tier 1 issue for many plugin development teams.
12. Developer Confusion:
• developers find it difficult to decide when they should use an editor vs view vs perspective.
• many developers use an editor as a big view, often with linking.
• users tend to use the product in very individualistic ways.  Some like perspectives, others don't.  This is true of developers too, who develop individual motivations for using / not using perspectives which reflect their own usage patterns.
• developers recognize the problem with loss of context.  In most cases they plan to work around it with custom solutions.  This is very bad, as it will lead to inconsistency within the product.
• it's important to provide developer guidance in these areas.  Far too many "do-it-my-way type" decisions are made by each plugin development team.  This leads to inconsistency and confusion for users of Eclipse based products.
13. Inconsistent Perspective Open and Duplication
• perspective open is implemented in different ways by different ISV's.  Some implement multi-page, others multi-window.

Background Info

The UI for Eclipse 1.0 is a reflection of many requirements:

1. Eclipse is an extensible platform.  It provides a UI framework and then defines standard extension points.
2. Extensions must co-exist within the platform and integrate well at the workspace (resource, builder) and workbench levels (wizards, views, editors, perspectives, actions, preferences, properties).
3. While the platform is extensible, too much extension will lead to clutter (overwhelming functionality in front of the user).  To avoid this some mechanism must be put in place to filter which UI extensions are visible.  We need to filter the visible actions in the window menu and toolbar and the visible views in the window.
4. The workspace itself may be very large, so some mechanism must be developed to restrict the visible portion of the workspace if needed.
5. Users have roles, and a role is embodied by tasks.
6. Users are multi-tasking and task transition (between two existing tasks, or completing one to start another) may occur at any time.
7. Every user is different, and should have the ability to customize the UI to suit their working style.

In reflection of these goals:

1. The perspective concept was developed.  A perspective controls what you see in the UI (which action sets and views are visible).  Perspectives do not, currently; filter the visible actions in a view, editor, or context menu.
2. The page concept was developed.  A page is a collection of views and editors.  It has an input (which determines the visible subset of the workspace) and a perspective (which determines the initial page content).
3. The workbench is made up of many windows.  Each window has one or more pages, one of which is active and visible.  The ability to create two or more pages is useful is important for comparison, exploration of other workspace subsets, and context switching / multi - tasking.

Possible Solutions

Rather than trying to solve every problem with a single approach, we will
examine each problem individually so that it is more manageable. 
If a consistent approach can be developed from the solutions, so be it. 
Our goal is to get from our current implementation to a solution with minimal
changes, if possible. Note, for each problem several solutions may be identified.
The "preferred solutions" are ones which the development team feels can
and should be implemented. The "other solutions" were evaluated by the
development team and were rejected.

Problem: Action Loss

Preferred Solutions:

1. implement a global MRU list for the contents of the Perspective > Open menu.  The contents of this menu will be initialized by the product, but will adapt over time as the user opens new perspectives.  Sort items by temporal order. Shortcut for navigating perspectives (e.g. next/previous)
• pro: establishes better workflow between previous and current perspectives.
• pro: reduces need for user to "customize".  The feedback seems to indicate that customization is a power user feature, and we cannot rely on it to help novice users.
2. expose the action classes in the navigator for reuse.  Perform a code review to make them more abstract.  Define a menu manager for IResources, IProjects, and IFiles which can be used to easily populate a particular menu.  Expose the navigator for subclassing.
• pro: we give ISV's a predictable way to reuse the functionality in their own views.
• issue: if we modify the existing action classes a breaking API change may result.  It may be better to copy these classes and start again.
• issue: what happens when ISV's want to intercept/override these actions. (e.g. rename in navigator vs rename in packages view)
• issue: need to track requirements from other teams (e.g. VCM - there is a desire to support pessimistic work model)
• issue: need to make sure that ISV defined action groups can also be propagated. (e.g. VCM team actions)
• issue: reusing the "go to" and "go into" capability
3. implement an IAdaptable mechanism in the popup menu extender, so that IResource actions will appear on non-IResource objects which return an IResource through IAdaptable.
• pro: resource actions appear everywhere that a IResource is visible.
• pro: we can say IResource is the common medium for integration between plugins in the UI.
• issue: if an action is targeted to IResource and something else, the same action may appear twice in a context menu.
• issue: ISV's often want to present logical view and actions targeted to physical resources may not be appropriate.
4. encourage ISV's to add context menu actions to the navigator.  These actions should be filtered by project nature to avoid confusing clutter.  For instance, Run could appear on all .java files with a Java project nature.
• pro: establishes a good coupling between the object and the actions which are available.
• pro: deals with situation where window actions, like debug and run, are missing in some perspectives.  Novice users, who are unaware of customization, find it difficult to run a java program in these perspectives.
5. continue to encourage ISV's to change perspective when a project is created.  In Eclipse, where there is a disconnect between the input and the UI, this may be the only chance where we can sync the two for the user, rather than relying on their knowledge to sync it for themselves
• issue: what happens when user creates their own perspective (eg. Java, Debug)
• issue: this is related to manipulating natures and builders (see project nature doc)
• issue: is this only a problem with the "simple" project type.

Other Solutions:

1. encourage ISV's to add a "Show in Navigator" action.
• pro: when all else fails, there is an action to get back to the resource centric world.
• issue: ISV's may implement this in an ad-hoc fashion.  Developer guidelines are needed to ensure consistency.
• issue: consider adding show in view X instead of restricting to Navigator
2. define the standard resource actions as popup menu contributions.  Then add them to the other views, like Packages, J2EE, and Data, using the standard extension point.
• pro: an existing mechanism can be used.
• issue: it is currently impossible to define accelerators for popup menu actions.  Additional work is required.
• issue: some of the actions require additional context.  For instance, rename requires a parent control where an edit field can be created.  Go into, go back, etc., require an abstract navigation stack.  The protocol for this context would be IAdaptable or "implements".
• issue: the extension mechanism is too weak to support true action sharing.  Each action is targeted to a single object type, but a single object type rarely occurs in more than one view.  For instance, resources are visible in the Navigator and in the Packages view, but in the Packages view they are wrapped in a java type. In practice, this forces you to target a resource action at IResource and IJavaType, and extension is only possible when you know specific type in each target view.  To resolve this the view which publishes the menu may say "add all actions for types x, y, and z, thus clarifying the appropriate action types".
• issue: generic contribution may lead to action duplication.  For instance, the rename action in the Navigator may appear as a duplicate of rename in the Packages view.  Hence, some generic mechanism is required to reject actions.
3. add a "workflow view".  Initially it will display architectural patterns for the creation of components.  If you create a component or select one the workflow view will display textual help, common actions, perspective hints, etc., for the object.
• pro: makes it easier to create objects
• pro: makes it easier to regain context for a particular object.
• issue: this is a usability feature, and does not decrease "loss of context".  We would defer this feature until time is available.
4. reduce the number of views, and make the remaining views, like the navigator, much more flexible in the way they display structure, labels, decorators, etc.  If the existing views are any indication, we would need the ability to add structure, remove structure, add actions, remove actions, etc.
• pro: we reduce the inconsistency by reducing the number of navigator-like views.
• con: we increase the complexity of the navigator by increasing its flexibility.
• con: we increase the workload for those ISV's who already have a navigator-like view.
• con: we increase our own workload by creating a navigational hot spot and we are not domain experts.

<db>
Additional cons for Other solutions 4:

• we could have Java, C/C++ and other projects in one "navigator". This would be a create advantage for people working on a project that uses different languages.
• this would also reduce the number of perspectives since there would be no need to define a new perspective for every language we are supporting.

</db>

Problem: Menu Ordering

Preferred Solutions:

1. correct the ordering within action extensions, so that actions appear in the order defined, not the reverse.  This will be done in a non-breaking way.
• add some new element, such as <group id = "x">
• OR specify that you can use an existing action as the reference location for another action.
• OR add some new attribute, such as "after existing", to get presentation order.
2. define a standard template for context menus and then encourage ISV's to use it within their views.  The standard groups might be "new, navigate, open, cut, copy, paste, delete, team, other, properties".  .
• pro: encourages consistency within the user interface, making the product easier to use.
• issue: can more be done, this may work within a single plugin but what happens across multiple related plugins (e.g. three, related plugins, each contribute 2 menu items)

<db>
These standard groups are "driven" by the navigator and might not be useful for other "navigator like" views. For example the standard template that we are using in JDT is as follows: new, goto, open, show, build, reorganize, generate (coding), search, additions, viewerSetup, properties. If we used the proposed standard groups then build, reorganize, coding, search would end up in the other portion with no fined graind control over their positioning. Additionally I don't understand why we need the groups cut, copy, paste, delete instead of one group reorganize. 

And I am not sure if the standard navigator menu layout is useful for all "navigators". For example when working in the packages view I am more interested in having menu items like search reference, declarations, ... on the top level than having copy, cut, paste in the top level since I need them more often. Have you thought about the possibility to make context menus customizable by users.
</db>

Other Solutions:

1. implement a global, product defined order for action extension.
• pro: solves product case
• con: does not address case of general extensibility

Problem: Decorator Loss (Version #)

Note: currently all decorators are implemented outside the platform, so
it is impossible to share these decorators in code.  We must use an
extension point.  The experience with popup menu extension demonstrates
that decorator sharing will be difficult because of the protocol mismatch
between an abstract decorator and the actual presentation model in each
view.

Preferred Solutions:

1. implement an object oriented decorator service.  To do this, we will define a decorator extension point.  Each extension declares a name and target type.  A view may contain many types, so the view should register those types with the decorator service.  In response, the service will return a list of decorators which may appear in the view and, if the user selects one, the decorator will be applied to the presentation. At most one decorator could be active in a view.  Decorators may change asynchronously, so some interface should be defined to support the callback.
• pro: the version decorator can be shared in an abstract way
• pro: additional decorators can be added

Other Solutions:

1. implement a customizable multi-column view, like in Outlook, where the user can add fields to the presentation of an object.  For instance, the user could add a "version info" column to the presentation.
• pro: lots of user customization is possible
• pro: supports generic extension of presentation with sandbox model
• con: lots of work
2. if the underlying widget would support "owner draw" the decorator mechanism can be improved significantly. As it is now the UI is constrained to provide (at most) one icon and (at most) one string per item in the widget.

Problem: Action Enablement

Note: currently the enablement of an action before it loads is controlled
in XML.  When an action is invoked the
delegate is created, and it can control enablement from that point on. 
The other delegates in the plugin are created if a selection is made in
the workbench.

Preferred Solutions:

1. if one delegate in a plugin is instantiated, instantiate the rest.
• pro: lazy loading strategy is maintained
• pro: increases the accuracy of action ennoblement after the first action is invoked
• con: does not address accuracy before first action is invoked.

<db>
All action delegates contributed by a plugin should be instantiated when the plugin gets loaded, not when the first action is triggered. Addtionally the platform should allow contribution to the global action bars via code. There are a couple of actions that make only sense in the global action bars when the plugin is loaded. For those actions, enablement could than be fully controled in code.
</db>

1. add new features to the XML for action enablement.  For instance, the filter element may contain tag names for system properties, installed plugins, and platform properties (which are set by other plugins).
• pro: increases the accuracy of action ennoblement before the first action is invoked.
• issue: it may be impossible to describe every scenario.
• issue: perhaps core should provide us with more file attributes for action enablement.  Currently the name, extension, and project are not enough to determine what a file contains.
2. add the ability to define a negative enablement.  For instance, you may say "if not nature", "if not installed plugin", etc.
3. encourage ISV's to use the project nature as a way of targetting actions to an object.

Other Solutions:

1. implement _javascript_ support in the XML for action enablement.
• pro: increases the accuracy of action enablement before the first action is invoked.
• pro: does not load additional plugins
• pro: supports boolean _expression_ evaluation
• con: forces developers to learn _javascript_.
2. implement the action enablement code in a baby plugin
• pro: action enablement is performed accurately in java
• con: there is no way to bound the loading time for the plugin.  Who's to say one plugin won't define a prerequisite for 6 other plugins.

<db>
I think that problem can be solved by implementing the bay plugins in the following way.

• baby plugins can only require other baby plugins.
• the loading of a baby plugin somehow shows progress feedback and is cancelable. If the loading still takes a long time users can deceide if they still want to use the plugin. If they are willing to wait that time we should not hold them back.
• loading of the bay plugin could be done in a separate thread. Additionally we implement a watch dog that terminates that thread if it takes to long (or at least gives the user the possibility to do so).

</db>

1. instantiate the delegate as soon as it becomes visible in a context menu, pulldown menu or toolbar.
• pro: complete accuracy of action enablement whenever visible
• con: this may cause a tremendous performance whenever a context menu is opened.  For instance, if six plugins contribute actions to the navigator menu, six plugins will load when the navigator menu is opened for the first time.  This is unacceptable.
2. start a subset of the plugins at startup
• pro: actions will be enabled correctly
• con: very poor startup time
• con: the preferred subset may change dynamically, depending on user task.  There is no way to predict this.
3. start all plugins at startup
• pro: actions will be enabled correctly
• con: very poor startup time

Problem: State Loss due to Linking

Preferred Solutions:

1. encourage developers to use "Show in XX" rather than linking, where possible
• pro: the action is more context sensitive and better reflects the task the user is trying to accomplish.
2. encourage developers to turn linking off by default, and add a user option to turn it on in the preferences.
• pro: default behavior is non-intrusive.
• pro: power users can turn it back on.

Other Solutions:

1. implement a global switch.
• pro: a single place to turn it on or off.
• con: is not context sensitive.

Problem: State Loss due to Perspective Separation

Preferred Solutions:

1. in order to avoid the creation of too many perspectives, we can change the default mode for "open perspective" to "replace".  In this mode, the "open perspective" menu item in the Perspective menu will be removed, and a drop down list box containing a perspective list will be added to the toolbar.  If you select a perspective from this list, the existing views in the perspective / page will be re-arranged to suit the new perspective.
• pro: in this mode the open editor list and the state within each view is carried forward to the new perspective, so there is no loss of context.
• pro: the active perspective is more visible.
• pro: it reduce the number of pages in the workbench, so the novice user is not overwhelmed by pages.
• issue: how will the user open a project in a new page, for scoping purposes?  Answer: Advanced users will be able to select a project / folder in the navigator and say "Open Perspective".  A new perspective / window will be created.

<db>
Which perspectives will be in the drop down list in the toolbar. I hope only those I opened, not all perspective currently available. Opening a new perspecitve should still be triggered by Perspective Open.

Instead of having a drop down box the plaform could provide the same mechanism as used for Next/Prev Editor and Next/Prev View which I find very handy.
</db>

1. in order to avoid the creation of redundant perspectives on the same object, we will implement a perspective reuse strategy in the workbench.  This will be based on the VAJ experience.  If an object is opened once (using Open Perspective in the Navigator), you get a page.  If the object is opened again, and a page is already open, the old page is activated.
• pro: eliminates the creation of redundant pages / windows in the workbench.
• pro: makes it easier to find a page which is already open.
• pro: establishes an object model in the workbench which is predictable.
• issue: some power users may want to create two windows for an object.  To deal with this we should provide a clone action to break out.
• issue: the implementation of this feature may be tricky.
• if we try to change the behavior of existing API's, some plugins, which rely upon the old behavior, may be broken.
• if we add new API then some inconsistency may occur.
2. implement a global MRU list for the contents of the Perspective > Open menu.  This makes it easier for switch from one perspective to another and back.

Other Solutions:

1. implement a mechanism to copy the state of one perspective to another.
• pro: the user can correct the loss of state
• con: the interface would be incredibly complex.
• con: it is one more thing the user needs to learn.
• con: it is technically, very difficult to implement.

Problem: Page Activation causes Disorientation

Preferred Solutions:

1. implement a temporal strategy for activation and closure. If a page is closed, activate the MRU page so the user doesn't lose context.  Perhaps a back and forward button would be useful.
2. in order to clarify the separation between perspectives, we will encourage the use of multi-window mode for perspective creation rather than multi-page mode.  This may lead to window overload.  However, if the "open perspective" menu item is replaced by a "perspective list box", this change will only be apparent to people who open a new perspective using "Open Perspective" in the Navigator).
• pro: clarifies the separation between one page and another, by using windows.
• pro: reuses the window management offered by the operating system.
• pro: reduces the complexity of the Eclipse page and window management UI.
• pro: window explosion is only a problem for experienced users who choose multi-window mode.
• NOTE: This is similar to "State Loss due to Perspective Separation". If the default mode is to replace the current perspective this is less of an issue. The choice to open a new window or add a page to an existing window should be a user preference.  Add a flash(window) method to the IWorkbenchWindow page.  This could be used by ISV's who want to alert the user to a change in a window, but do not actually want to activate it (e.g a console view).
3. if a page is activated programmatically indicate the page change with a better caption, windows style flashing title bar, flashing image, or some other alternative.
• con: this has to be very subtle if it is too "flashy" it will be frustrating
• issue: consider updating the "active page" image in the shortcut bar to better highlight the active page.
4. define guidelines for the appropriate use of page activation / perspective change.

Other Solutions:

1. remove public api for page activation.
• pro: removes problem case
• con: api change.
• con: in some situations it is appropriate to activate a page.  For instance, if a breakpoint is hit the perspective should change.

Problem: View Activation and Opening

Preferred Solutions:

1. define guidelines for the appropriate use of view activation.
2. add a flash(part) method to the IWorkbenchPage.  This would be used by ISV's who want to alert the user to a change in a view, but do not actually want to activate it.
3. implement a temporal strategy for activation and closure. If a view is closed, activate the MRU view in the same stack so the user doesn't lose context.

Other Solutions:

1. if a view is opened programmatically open it as fast view or floating view until user places it in page.
2. remove the public API for opening and activation.
• pro: removes problem case
• con: api change.
• con: in some situations it is appropriate to activate a view.  For instance, if an error is displayed in the console view it is helpful for the view to appear.

Problem: Accidental Layout Change

Preferred Solutions:

1. fix sensitivity of direct manipulation.
• pro: will hopefully resolve the problem.
• issue: there may be some cases where accidental layout still occurs.

Other Solutions:

1. add a "lock / unlock layout" action to disable direct manipulation.
• pro: reduces incidence of accidental layout change.
• con: within Eclipse, the manipulation of view position and size is an important feature.  Users perform this task often as they add and remove views, or customize the layout.  By turning this into a "mode" we effectively hide the feature and frustrate the user.
2. implement "undo layout".
• issue: currently the undo action targets the active part.  Our "undo" would only be visible if the undo action was temporal.
• issue: sometimes the creation of a floating window is subtle, so you don't notice it.  By the time you do, you may have performed many other actions, making undo impossible.

<db>
IMO undo layout is the way to go since this is what I expect from a good UI. And there is some ongoing work to provide a global undo/redo stack.
</db>

Problem: Confusion about Existing Perspectives

As the UI team, our role should be to define guidelines
for the use of perspectives.

The current set of perspectives in Eclipse is task centric.  Each perspective has been defined to accomplish a certain task, so it has certain views or action sets.  This was mandatory in VAJ, where each page in a browser was task centric, linking was setup for the task, and you had to switch between pages to accomplish a different task. However, it doesn't work as well in Eclipse because activation linking is more common, and the user will often add / remove views to accomplish a certain task.  This blurs the original perspective intent, and the differences between each perspective.

<db>
In my opinion perspectives are created:

• for different project types
• for different plugins

Except debugging (and VCM) none of the perspective I am aware of are really task centric. They are more of the style "Coding for Language A" or "Supporting plugin P" since there isn't a good story how a plugin can add functionality to an already existing plugin (action contribution, a new view that is considered by an already existing plugin, ...) But I don't have a good solution for this problem either.
</db>

Most users have a role, and a role may span many tasks.  The existing UI in Eclipse forces you to switch perspectives, but perspective switching may be a power user feature.  It might be good to take a role based approach to perspective definition.  Each perspective could embody the views you need to perform a certain role, and not rely upon perspective switching to fulfill the role.  The initial role would be derived from the options in the New Project wizard.  Java may contain java, debug, and team views.

That being said, here are some other options:

1. clearly indicate to the user that some perspectives are generally useful and some are used less frequently.
• Issue: Who decide which perspectives are useful.  It is a reflection of user, not developer.
• Issue: If a perspective is used less frequently why include it?
2. we should re-examine the concept of short lived and long lived tasks.  Perhaps all short lived tasks should be done with views, not perspectives.
3. we could limit the visibility of editors and views to certain perspective.   By doing this, we increase the conceptual separation between perspectives.  For instance, it may make sense to not open an editor in the active perspective if the editor area is hidden.  Or perhaps you can't open the resource navigator in the team perspective.

Problem: Developer Confusion

Preferred Solutions:

1. publish guidelines in cooperation with usability professionals
1. if operation is short lived use view.
2. if operation is long lived use separate window.
3. if view / editor has multiple viewers use separate window.
4. if view / editor is in a significantly different domain then use separate window.

Other Solutions:

1. we demonstrate our ego, and critique everybody
1. con: this is a big waste of time

Problem: Inconsistent Perspective Open Implementation

Preferred Solutions:

1. add an openPage method to IWorkbench which will open a page in the correct mode.
• pro: developers don't need to examine perspective preference.
• con: it may be confusing that there is an openPage convenience method at the IWorkbench level.  If one method, why not add other methods like getPages, activatePage, getActivePage, closePage, etc.?  Reason: They are inconsistent with the current architecture.

Other Solutions:

1. it would be great if we could collapse the window and page class into one to hide presentation.
• con: this would be a breaking API change.
• pro: hide presentation of pages, increasing consistency when opening pages.
• pro: reduce complexity within internal API.  There would be no more need to iterate over windows, pages, and parts.
• pro: reduce complexity in UI.

---