RFC: Loss of Context (Response to Feedback)

["Greg Adams/OTT/OTI" <Greg_Adams@xxxxxxx>]

Apologies for my late reply.
 I have added my comments to David's recent update - David the inclusion of
feedback was useful - thx.

I am concerned that it is going to be very difficult to get closure on some
of these issues unless we partition this up and close them out one at a
time. It feels like we also can't get into enough details in some areas
without doing this.
|------------------------+------------------------+------------------------|
|                        |   "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]    |
|                        |                        |   Response to Feedback |
|                        |   11/29/01 07:29 PM    |   on Loss of Context   |
|                        |   Please respond to    |                        |
|                        |   platform-ui-dev      |                        |
|                        |                        |                        |
|------------------------+------------------------+------------------------|











Hi,

Thanks for the feedback on our loss of context proposal.  Rather than
respond to each individually, and create a blizzard of email, combined the
feedback into a single document and responded to the result.  Hopefully we
will converge on the correct solution soon.

Title: Request For Comment

RFC: Loss of Context (Response to Feedback)

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

Greg> My comments are in <Greg>..<Greg> .
Greg> Apologies for my late reply (but at least. I have read everyone elses replies) -- I thought I would put my notes into David's recent update.
Greg> Please precede all of my comments by IMHO. Some may seem terse or strongly worded - this is not intended.

Introduction (added Nov 29, 2001 )

This is a response to the feedback submitted for the first draft. 
Excerpts from the feedback are marker with Feedback:
and colored blue.   The response is included after. 
None of the original text has been changed.

Feedback: "As a general comment I think we need to have a simple, strong, story as to how the workbench should be used. While configurability is fine, for a given task we really need to be able to state that "this is how you perform it" in the workbench. There will always be users who come from a variety of backgrounds and of course they would like everything to be familiar. But I think part of what they are really saying is "we want to do our work" and if the IDE is familiar then it is easy. But the trap here is that we try to become something that we are not (ex. source view in VAJ) and just end up confusing users. So while there may be cases where we want to adopt a VAJ style this or a VI style that, Eclipse is Eclipse. It needs to be intelligent, intuitive, and functional more than it needs to be "like" anything else. "

Response: Agreed.

<Greg>
Agreed.

• Eclipse is not going to be every navigation paradigm to everyone. We need to evolve/improve our approach & describe it.
• A goal is not to be able to have an ISV port their stuff and say "I want it to look exactly like it used to"
• Having said the above, I would still argue that within the navigation/interaction models we use that configuration still plays an important role. It is hard enough to appeal to basic and advanced users, let alone accomodate some of the interesting arrangements resulting from tool integration without some capabilities for customization/configuration. However, any configuration has to be easy <g> and obvious - which is not the case right now.
  

Meta Note On APIs

• The degree to which API is made available for showing & contributing things has to very (understatement) carefully considered because experience has shown that it will be immediately be misused with ISV's trying to subtlely (or not so subtlely) change the paradigm. [this is a proven fact] . Instead of creating pockets of seemingly random deviations (from users point of view) ISV's that have concerns about certain aspects of the navigation paradigm or ideas for improvment should be participating in design proposals like these & helping evolve future ui guidelines.

</Greg>

 

Feedback:  "A general statement to start with: Dave's proposal is rather long. Although, all listed issues somehow belong together, I'd prefer when presented proposals would have a sharper focus.  Long proposals have the inherent disadvantage of a  discussion scattered over a big set of issues. This automatically reduces the weight of individual arguments. In addition, for persons not that familiar with the overall topic it is hard to pin down the most relevant statements."

Response: Agreed.  In hindsight, it should have been split up.  In addition, to your points, voting may be difficult when you favor one section but not another.  However, this is a new process for all of us, so we'll have to learn as we go.

<Greg>

Strongly agree. The length and breadth of this proposal means (can I use these as the excuse for my late reply<g>):

• Readers need to find a larger block of time because its all or none. Smaller partitioning would allow us to comment on areas.
• Difficult to drill into the interesting details to the needed depth.
• It is not possible to include all necessary background/sample information for each issue to the depth needed to facilitate a good argument.
• As Simon [SA] observed there are a number of issues that actually get raised by the proposal but then not addressed - probably lost in the bulk
• As people reply it makes it harder to follow the issues/replies again because there is so much.

Some additional feedback (as you say we're still learning) on what I found awkward for reading:

• The executive summary presents problems & solutions, yet the set of problems are different then those in the problem section, which are in turn also different then the set of problems in the solutions area - so it makes it seem like there are 3 different sets of data one has to grapple with. The ordering is also different orde uses different words to describe it: decorator loss, state loss linking, state loss perspectives, perspective activation vs. decorator loss, action enablement, state loss linking, state loss perspective separation, page activation
• When looking at the solutions section I had to keep scrolling back up to the problem section to remember what the identified issues were - would be handy to have the problem & associated solutions together
  

I am concerned that it is going to be very difficult to get closure on some of these issues unless we partition this up and close them out one at a time. For example two main areas seem to be navigation and action availability.
</Greg>

 

Feedback: "I would like to suggest the following extensive changes to the navigational paradygm in Eclipse .."

Response: Although these are all interesting ideas, our API commitment to the Eclipse community means that extensive changes are impossible to make.

 

<Greg>
Agreed sort of.

The response is too general/misleading. Yes it is extremely true that we cannot go breaking APIs, we need to be committed to the APIs. However if we receive interesting ideas with big wins (that we believe in) then we need to try and find a way (time permitting) to accomplish it in a nonbreaking way.

Meta Note on participation:
It is really good to receive suggestions and ideas. We also encourage folks to get involved in code. The chance that your request will happen goes up if you are willing to work on it & the community thinks its the right approach<g>.
</Greg>

 

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.

 

<Greg>
RE: 1 - mru

• An MRU of perspective open does seem to actually address the problem stated as action loss which is: "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.". If (that's a big if) the MRU makes it easier to switch it actually doesn't mean users can anymore easily figure where actions are avilable or where they have to be to do something.
  
  
• I don't think the MRU is enough to solve perspective switching - I realize some other mentioned proposals will help - but I think we are missing some key observations as to why navigation is hard:
  
• the shortcut bar on the left shows only 16x16 icons - it is very hard to distinguish them. I often quickly find windows in a windowing system by quickly clicking on a task bar (e.g. the Windows task bar) and I rely on seeing the icon & at least part of the description.
• (related to the above) a window system task bar lets me keep regular windows at the front, and then for those I need sometimes (e.g. mailer) I just quickly find it on the task bar. In our world everything feels equal.
• the shortcut bar is linearly arranged by the system and now spacially arranged - for example I often have will have an OS file navigator in the top right and my main working windows in the middle of my display
• having each page potentially have many perspective in it effectively turns each window into a NxN grid in addition to the N windows on the users OS desktop
• lest you think I would argue for MDI within a window I wouldn't because MDI actually doesn't solve the above and introduces a whole other set of problems
  
  
• Looking at the latest build the combo in the toolbar has some issues:
  • It often only shows part of the perspective name - not sure how much of an issue that is - may not be a big deal
  • I don't know how easy this is to spot when there are editors which heavily use the toolbar (e.g drawing tools, html editing tools) - do we know if this combo gets "lost" amongst all the others [I'm just asking the question]
  • however it is quicker (pro) to access then a menu operation - but it does not address the issues raised above (con)
  • if I am switching between perspectives regularly (e.g. java, debug, and web) the combo is likely to be too akward to use because of the hand/eye coordination needed to pick the right line out of the drop down - not condusuive to speed coding
  • if the ordering changes unpredicatably (temporal ordering can appear unpredictable to a user - belive it or not) it makes it hard for the user to find things - this may or may not also be additional burden for accessibility
    
    
• is there a cap on the number of entries in the mru
  
  
• is workflow between previous/next the most important thing - if yes combo doesn't help that - your forward/backward might - if memory serves me there are keys in 1.0 for previous/next but they aren't temporal
  

 

RE: 2

• Agreed - There are a number of navigators in extistance and they don't share any common navigation superclass & this breeds inconsistency. (but see also points below)
  
  
• Do you draw a distinguish between navigators that provide a logical view (modelling views, or j2ee type views) vs. more physical views. - I would also be interested to here what VCM folks say on this.
  
  
• When you say "expose the navigator for subclassing" - what kind of views do you expect to be subclasses. Specifically is the definition that subclasses are navigating the resources - in which case the repositories view would not be classified a navigator. It's important for ISV's to understand the intended use. Plus, if the repo view was not a subclass, then solutions to delete (for example) don't help it.
  
  
• (related to above point) It might be useful to list existing views that should be subclasses it?
  
  
• "Define a menu manager for IResources, IProjects, and IFiles which can be used to easily populate a particular menu"
  • Does this mean you will provide a facility to populate a target menu with operations registered by the workbench *and* isv's against resources or those adapting (providing IResource through IAdaptable).
  • (related to above) - Is this automatic or relying on the good will of an isv to call it?
  • How is this different than a menu manager that simply populates a popup with object centric contributions?
  • (related to the above) it seems the more object centric approach (e.g. contributions for X or someone that adapts to X get contributed to the pop up for objects of type X or those adapting to it ) seems more useful
  • (related to above) Are you bounding your solution to just resources?
  • Need a more detailed example showing how this actually manfiests itself to developers & the users.

RE: 3

• "issue: if an action is targeted to IResource and something else, the same action may appear twice in a context menu."
  This seems to be argueing I register on a IResource and also on something else. But unless that something else adapts to IResource why is there duplication? Unless you are talking about the heterogeneous selection case .
  
  
• Are you argueing: Everyone should register to IResource & different behavior in nav vs. package view for rename is bad. If yes to either of these then JDT would register a rename on IFile for .java files and so would the workbench (to get base behavior) -- duplication occurs despite registering on the same type.
  
  
• Is there any argument to be made (I am just asking this dumb question) that says the problem with rename (i.e. rename trying to refactor in java) is not actually at the UI layer. That in fact the refactoring should not be on the operation but in fact be on the result of a build. I have not really thought this through but figured I would ask the question. I can see some problems with this but still felt it was worth throwing out.
  
  
• If everyone is contributing to work against the base resources then don't we run the risk of
  • menu explosion in the navigator
  • menu explosion in other views (e.g. a java class may start having numerous web or modelling operations, that may not be applicable
  • is there any
    
    
• Is there any user/ui notion of providing a base set of operations on objects (would need to define base) in the popup and also allowing the user to get (in popup) a more complete set of pop up operations. Then effectively augment the default menu with MRU ones from the set of all - or have it under user control.
  In a nutshell, it seems we have gone from . VAJ users both liked and hated the fact that the menus had tonnes of options thereby letting you do most things from most places - the mechanisms it uses were all object contributions & editor/view centric contributions.
  
  

RE: 5

• "continue to encourage ISV's to change perspective when a project is created."
  I think you want to ensure that project creation wizards have an option for this. Advanced users may not like this auto switch, but without it newbies may not discover the useful perspectives. The wizard should clearly indicate what perspective the user will switch to.
• Are you encouraging switching to the new perspective with workspace as input, or to a new perspective with the project as input?

Additionally

The solutions presented do not address some of the "action loss" problems identified:

• " 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)."
  
  Agreed - It is very problematic/error-prone that delete is different than all of the other actions - this is just begging to not be implemented - for example the repositories view does not let you click a repo connection and delete key it - probably got missed.
  It's not clear having a navigator superclass helps fully address this - it might help subclasses but its not a general enough solution
  
  
• "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)."
  • Is the intent that the rename in the navigator would actually by the rename contributed by the java tooling.
    

</Greg>

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.
1. 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.
2. 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.

<Greg>
RE: other #1

• Assume you believe the bookmark view is valuable. Then if I have a java class in it, wouldn't show in hierarchy be useful?
  In otherwords just encouraging show in navigator is likely insufficient.
  I presume this can be done with standard object-centric popup contributes - but I only point this out to show othercases for "show in":

RE: Other #2

• RE: Accelerators there are several important things to observe - I believe however that action contribution & accelerators are big enough for a separate article
  • The workbench should not be cheating in its contributions - it currently is cheating
  • It must be possible to have accelerators without necessarily putting them on a pulldown. For example if I want to include VI, emacs, epsilon etc all of those have a boatload of accelerators and they are rarely shown on pulldown menu operations
  • In order to support user configurability of accelerators in such a dynamic world (any plugins can show up) it is important that accelerators be declared - even those not showing up in menus.
  • All actions must be equal. It should be possible for me to build a cheat sheet by taking some actions I commonly use fro a toolbar, a menu bar and placing the, onto my cheat sheet or welcome page -- this is not currently true. In part because there is no null constructor reqiurement & in part due to the workbench cheating

</Greg>

Feedback: "Will the perspective MRU be a breaking
api change? Isn't this menu populated by the perspective?  What about 
changes the user makes in the customize dialog?."

Response: Plugins which contribute a perspective item to the menu will not be broken.  Instead, their preferences will be silently ignored.  The user may still be able to control the menu, perhaps using a preferences page which defines the perspectives globally.

<Greg>

• I am not sure we could call this a true non breaking change because because ISV's have currently loaded their perspective menu with their best guess "related perspectives" the user is likely to need - now those are gone
  
  
• What does the initial starting case look like? Does this mean the user has no idea what perspectives he will likely need and has to go pick them from "other" perspective? If so then this actually makes the problem #9 ("Confusion about existing perspectives - it is never clear what to use") more problematic for the beginner because they don't even get the initial hint of what they are likely to want to use.
  
  
• The MRU seems more favoured to a replace perspective model because it does not distinguish between perspectives I have open & ones I am working with. Thus it implicitly assumes there is no difference other than layout (i.e. replacement). - This is subtle but I think important.

</Greg>

 

Feedback: "You propose continuing to encourage ISVs to open a new perspective when a project is created. Switching perspectives
programmatically is definitely a loss of context. I suggest that the wizard prompt the user, giving them the option to either stay in the
same perspective, or switch to the new recommended perspective.  We could have programmatic support in the new project wizards, so we could handle this generically, e.g. add API for setting the preferred perspective, and possibly a description for why it's preferred.  If the wizard doesn't set this, there will be no prompt and it will remain in the current perspective. This lets Eclipse UI control the policy for how perspectives are switched, rather than hardcoding it in each new project wizard. "

Response: Actually, the proposal says "switch to a new perspective", which means "replace".  The same views and editors would exist in the new perspective.  The idea of a prompt is worth considering, and a number of people have mentioned it.

<Greg>

• Prompting via dialog at the end of the wizard is rude.
• I see your comment above re: using replace - but I would still ask what is better:
• switching to the new perspective with workspace as input, or to a new perspective with the project as input?
• opening a new window to avoid the "what the heck happened to my navigator" or doing replace inside current window
• It is a bit of a lie to say "the same views and editors would exist in the new perspective".
  • The same views would only exist if the target perspective has those views - otherwise each switch becomes a massive ugly union
  • The same editors would only exist if the target perspective wasn't hiding editors
• "continue to encourage ISV's to change perspective when a project is created."
  I think you want to ensure that project creation wizards have an option for this. Advanced users may not like this auto switch, but without it newbies may not discover the useful perspectives. The wizard should clearly indicate what perspective the user will switch to.
• Switching perspectives on new project should not be left to the whims of the ISV. I believe (???) at the moment we rely on the wizard to call the switch code, and if so this is a further chance for inconsistency.

</Greg>

 

Feedback: "Related to this, it would help to allow a perspective to specify its preferred view. I believe this would be helpful when opening perspectives in general, not just for the new project case.  In the new project case, you also want to specify the initial selection, which is presumably the new project(s). I picture the following scenario:

• user goes to create a new Java project
• when he hits Finish, the wizard recommends switching to the Java perspective (if not already active)
• if the user accepts, then the window switches to the Java perspective, with the packages view active, and the new project selected

Response: It's not clear how the preferred view would be defined if the user customizes a perspective.  However, it is worth considering.  The recommendation idea has been repeated by a number of people.  And the last idea is currently implemented for many wizards using the ISetSelection interface.

<Greg> Some possible heuristics that may (or may not) help :

• allow a perspective to define preferred view
• for user created perspectives we know the perspective it was saved from - this could potentially give us the preferred view
• if the preferred view is not present look for one whose input is the page/perspective
• if multiples then go to top left most one - likely user would work left/right top/down (except in bidi locales - but eclipse does not right/left anyways)

</Greg>

 

Feedback: "A global MRU list for the contents of the Perspective > Open menu means that the order of the list is not stable.  If this is implemented as a menu I think that it is important that the ordering be stable since reorganizing menu items is confusing. If this is implemented as a pop-up list then I think you could have a stable order but preselect the previous one. This would still make it easy to switch back and forth. "

Response: Good point.  It may also be possible to adopt a global list which is configurable from the preferences.

 

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)

Other Solutions:

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

 

Feedback: "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."

Response: The layout you suggest may be better.  We will consult with the UI Guidelines team to define a direction on this.

<Greg>

• Carrying above observation further: Are we making suggestions/options driven by either the navigator, or packages (or other JDT view) and may not be representative of some of the cases ISV's are encountering.
• viewerSetup (above) - if this relates to filter/sort etc then this should be on the view pulldown not the context menu
• Agreed on one cut/copy... group.

</Greg

 

 

Feedback: "You recommend defining standard groups of items for context menus. I think this is a good idea, particularly if it helps the context menus conform to platform recommendations regarding which actions appear in context menus, and their order. Here is my summary of the recommendations in the "Windows User Experience" book:

• include only commands that apply to the selected object (or objects) and its context, rather than commands grouped by function
• keep length and depth (submenus) to a minimum
• limit to common, frequent actions
• container of selection usually provides the context menu, but includes object- specific actions
• avoid using context menu as the only way to access a particular action
• but, need not limit it only to actions included in drop-down menus (e.g. context menu may allow you to change a commonly used property, such as font size, which is otherwise available only on a secondary dialog)
• recommended order of items:
• object's primary commands first (e.g. Open, Play, Print)
• tranfer commands next (e.g. Cut, Copy, Paste)
• other commands supported by object (whether provided by object itself or its context)
• "What's This?" when supported
• "Properties" last
• use separators to separate groups of commands "

Response: Acknowledged.

<Greg>

Agreed. Another observation is:

• object centric options vs. parent (input) object centric option - this would apply to editors as well as views. I believe someone's feedback asked for the ability to do menu operations on an editors input.

</Greg>

 

Feedback: "Why are the navigator actions special?  Why can't we share them using the standard action extension point? "

Response: We tried this.  The actions within the navigator are tightly coupled to a view with drag and drop support, accelerators, and tree editing.  Given our time limitations, we have decided to expose them for reuse in code, rather than push out on an api which may lead to failure.

 

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.
   
   

<Greg> Other #2 - This effectively means visual decorators cannot be safely used (using them can yield a smudge) - see my nature example below.

Are we fighting the battle on the wrong front?

</Greg>

 

Feedback: "Say the vcm plugin defines an decorator
extension for IFiles. If it does not specify one for "java objects" then
will it show
up on the list in the package view? Or is the
package view supposed to ask the decorator service for decorators for "java
objects"
and IFiles? "

Response: In our current prototype the decorator will show up in the packages view if the objects in the packages view adapt to IFile.  This functionality will be consistent with the changes to popup menu extension.

<Greg>

• It is problematic that the only strategy for visual decoration is to do overlays. This effectively means you can't do visual decorations. To support this argument I point out that for project natures we only show one nature that a project has. This means if a web project had a java nature and a web nature core would argue the UI should show all natures which it can't do without causing a smudge. (aside: I don't actually subscribe to this approach with natures but my example is based on current mechanism/intent from core) - it's easy to come up with other examples.
  
  
• This implies there are no cases to have one decorator be used for java file in one view and another used in a different view? Is this really true/good - just asking?
  
  
• We want to have red'x in the navigator to show a file with problems - will these be done using visual decorators thus ensuring wherever the object is shown it can reuse the visual decorator?

</Greg>

Feedback: "Who provides the UI for choosing the active decorator? Presumably this is done by the service, not individual views. Likewise for
saving/restoring the active decorator across workbench sessions. Also, will decorator state be preserved across view lifetime? For
example, if the Navigator is showing version info, and I close and reopen it, does it still show version info? Does the state apply to
new views opened in other windows? That is, does the state apply to a specific view, or to the type of view? I see either solution as
workable, but this should be spelled out. "

Response: A UI for decorator selection will be defined by the platform.  We will also persist the settings.  W.r.t. configuration, decoration is currently defined on a global basis in our prototype.  If you turn it on in one window it affects all views and windows.  However, this may change with useability feedback.

<Greg>

• Do you mean the platform will automagically platform place a choose decorator option on the view's pulldown or the object's popup?
• Can I enable multiple decorators?
• Is there support for "quick access" to enabling decorators. For example the VCM team is likely to argue they want the navigator to be able to quickly hide/show version information.
• If the decorators are object centric does this mean I would have to manually select a project & a folder & files, in order to enable/disable the decoration for version numbers?
• If I enable a decorator inside the navigator won't it be confusing if it enable it in other views. The reason I would argue this is that there is an expectation that filters/sorts etc done in a view apply to the view. Globally oriented settings are done through the preferences dialog.

</Greg>

 

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.
2. 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.
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.

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.
3. 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.
4. 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.
5. start all plugins at startup
• pro: actions will be enabled correctly
• con: very poor startup time

<Greg>

• I have heard requests for being able to control both enablement and also visibility (i.e. should it show up) of the option - is there plans for the latter. In VAJ (for example) there are a number of options that conditionally show up.
  
  
• Misc Idea: Above it talks about "system properties, plaform properties" as enablement.
  What about a plugin-ins preferences for enablement or visibility. Plug-ins that are subclasses of the UI class typically use a preference store. Preference stores keep preferences in a very simply format. Complicated preferences still have to be flattened to strings. It should be possible to access a plugin-in's preference store without starting the plugin. For example one could have the following for enablement or a menu visibility -- I made these up - they are not real<g>:
  • org.eclipse.ui.PreferenceStore.advancedUser = true << if we ever thought having menu options hidden for novice users
  • org.eclipse.jdt.PreferenceStore.compilerLevel = '1.4'' << maybe used to show/hide an option for assertions
    

  Aside: I took a look through all of our current preference pages & their preferences and didn't see many that would be useful for this mechanism but I want to throw out this thought for ISV (especially JDT) input. I prsonally think the whole issue of action enablement needs to be a separate proposal to ensure we get good discussion of this point & the previous feedback suppliers comment about baby plugins
  

</Greg>

 

Feedback: "All action delegates contributed
by a plugin should be instantiated when the plugin gets loaded, not when
the first action is triggered."

Response: Agreed.

 

Feedback: "Additionally 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."

Response: Ideally, the activation of a plugin should be transparent to the user.  This means that the actions visible before a plugin is activated should be the same as those visible afterwards.

<Greg>

Agreed - strongly with response.

Meta Point: We need to be careful about code contributions because to allow for user configurability & accelerator configurability it will be important to have access to the set of actions without requiring the user to activate each of them.

</Greg

 

Feedback: "I think the problem can be solved by implementing the baby plugins .."

Response: Within the workbench we believe that action enablement should be quick to calculate.  If it is too expensive to calculate the enablement of an action, the action should be optimistically enabled.  If the action is invoked, it should calculate the real enablement, and show a dialog to the user if it is not available.  This heuristic can be used for action enablement in general.  It is too expensive to load a plugin, especially when there may be hundreds of plugins in Eclipse.  Therefore, we will not load a plugin to enable an action. Instead, the action should be enabled accurately if possible, or otherwise enabled optimistically.

<Greg>

Baby plug-ins are something I was pondering aswell as I read this but it feels doomed to failure but I would be interested in some design specifics from the person who supplied the feedback (meta: this is why separate proposals would be useful so we could drill into each).

• Introducing a new core concept is not feasible
• What exactly bounds the kind of work a baby plugin can do & how do we propose to bound it
• Timeout on start does not help - all it takes is for each baby to take close to its limit & we have a problem
• If you open the door they will rush in - I have already seen cases where some ISV's in their own views are doing too much work - such as talking to a server resulting in lengthy delays the first time a menu is built (and sometimes subsequent times).
• If we intend to encourage lots of ISV's to contribute to the navigator them this will force the starting of all of those baby plugins .
• How are baby plugins different than plugins (can they have fragments, versionins, plugin dependencies)
• It would effectively double the number of ISV ui plugins (a baby one and a real one) - both would have nl fragments etc aswell.

A meta point with regards to time out. I am actually in favour of a cap on plugin start - perhaps after witnessing too many time munchers<g>. Specifically:

• bounding plugin startup
• preventing plugin starting during menu building

Meta point

• An observation to make is if we do start plugins that the cost of startup time would only hit the menu once. However it means we have actually started plugins that a user may never actually use, all for the sake of providing more accurate enablement -- I don't favour this.

</Greg>

 

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.

<Greg>

• Meta Point:
  In the original problem descripiption it says: "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."
  
  It is not clear that the navigator actually represents my immediate working set. It is true it has projects I am working with (or need) but it is not necessarily my actual working set.

</Greg>

Feedback: "Where would this "Show in XX" be? Would it not be better to have a tool item in the nav view whose action would be to select & reveal the resource in the tree based on the active editor? Same could be done in other views like package."

Response: This is an interesting idea.  We will consider it within the UI Guidelines team.

 

Feedback: "I agree the default should be off. It would also help to separate the preference into two: one for navigator to editor linking, and one
for editor to navigator linking. The second one is usually the cause of loss of context currently. The first isn't so bad.
I also suggest that the preference(s) be made more generic, e.g. "enable linking for Navigator-like views" so that other views (e.g.
the Packages view) can use these settings without having to define their own. This would make the environment more consistent. The
pref(s) would have to be added as API. "

Response: We will publish guidelines, but the implementation of each individual view is up to you.  You should apply them as you feel is appropriate.

<Greg>

• "encourage developers to turn linking off by default" - does this apply only to navigators? Or does it imply views like the property sheet and task view will not respond to selection?
• Are we encouraging them to include a user switchable preference
• Should there just be a generic link navigator to editors & vice versa option that allnavigator views should use - and do they get this free by subclassing your new proposed navigator class?
• Agreed also with the suggestion for action to show in / sync up - below

</Greg>

 

Feedback: "One of the problems here is that, although one can open an editor on an object, you really have to select that object in a view in order to be able to perform "object level" operations on it. Being able to access the operations in the editor area (perhaps a pop-up on the editor tab) might simplify things.  The workbench should make a "Show in Navigator" action available from any editor open on an IResource. "

Response: Great idea.

<Greg>

• Agreed - This also relates to my earlier comment about input oriented operations for views & editors.

</Greg

 

Feedback: "just having an option to "link this to that' is not good enough. In the navigator and editors case, I find there are times when I want it linked and times I don't."

Response: Agreed.  An action is better than a link.

 

Feedback: "I would prefer a "Sync All" option. Otherwise we would end up with too many Show in XX option."

Response: The scope of a sync all option may be too broad, causing loss of context in views which you have no intention to change.

 

 

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.
2. 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.
3. 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.

<Greg>

• Are there plans to allow users to filter out (hide) perspectives they don't use or is the intent the MRU would make this unnecessary?
• Do we believe the loss/change of editors is the main cause of loss of context / disorientation
• Related complaints for editors are as follows - what is planned in that area - since it may impact back on loss of context
  • It is too difficult to navigate many open editoes
  • Editors open too easily (in response to debugging, searching) that force me to have to manually close them
• This approach seems to imply:
  • there is only one packages view among multiple perspectives - correct?
  • all perspectives in the same window must be on thje same input - what does it mean for perspectives like debug

</Greg>

 

Feedback

Feedback: "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."

Response: In the current prototype, only the most recently used perspectives appear in the drop down list.  And the widgets will be refined over time.

<Greg> See my related comments in Action Loss regarding the MRU for perspectives & the combo box. </Greg>

 

Feedback: "How about something like JDT "open type" action? that should open a new window right? or will that be up to the action to decide?"

Response: It is possible to open more than one editor in a page, so by default, opening a new type should open an editor in the current page.  The creation of a new window should only occur if the user explicitly asks to use multi-window mode.

<Greg> The response above also seems related to my observation in response to "continue to encourage ISV's to change perspective when a project is created."
and is:
   Are you encouraging switching to the new perspective with workspace as input, or to a new perspective with the project as input?

</Greg>

 

Feedback: "If the open perspective menu is being replaced by a combobox in the toolbar, this will be highly inconvenient for keyboard access.  Recommend have a menu for this as well, containing the same items, in the same order, with a radio button (not check box)
indication for the current perspective. The combobox needs to have a label, e.g. "Perspective:", or at least a tooltip explaining what it's for.  "

Response: In the prototype the radio button is already implemented.  The inclusion of "all" of the open perspectives in the menu is a good idea.  All else sounds good.

<Greg> See top action loss section for concerns on combo </Greg>

 

Feedback: "In addition to "Open Perspective", will users be able to open (or clone) a window via the Window menu? If so, it would be nice if it inherited the perspective setting, and possibly other settings, a la VA/Java (e.g. view placement, if changed from the default). This
could act as the "clone" operation referred to in the proposal. Unclear whether you would want to have the same editors opened in
the new perspective. Probably not, since having the same file open in multiple places contributes to loss of context. "

Response: If clone is used to create a second context on the same space, for a different task, it would be appropriate to inherit the perspective settings, view settings, etc, but leave the editors behind.

<Greg>
Then it isn't clone. I think we need to ask "why would a user want to duplicate the current window or perspective". It's not clear we actually no the answer because it feels like we are discussing the feature & there I don't see a convincing argument for losing the editors (or even to keep them). In fact given we are doing the perspective replace it seems to argue losing them actually is a loss of context (that's a premise put forward earlier) and thus if the user says clone and doesn't get a clone it is confusing.
</Greg

 

Feedback: "It seems there is a conflict between the decision to "replace" perspectives by default and the functionality to "open a new perspective (window) on an object".  The idea to replace perspectives is designed to prevent users from losing their editors. This presents the workbench ui model as a shared editor set which appears with one of a configurable set of views.  The idea of opening an object in a page is more the vaj model. In this context the feature of having a single editor which is reused seems the most appropriate otherwise you have not really solved the "loss of editors" problem. "

Response: This is a very good point.  In Eclipse, many of the ideas from VAJ may in fact be incompatable.  The novice user is expected to work in a single window, opening up many editors, and switching between views to accomplish tasks.  The recreation of vaj, with linked views and multiple windows, may actually confuse the user.  It would be better to adopt the UI behavior of Eclipse.

<Greg>

• I agree with the cautionary words re: vaj navigation. I have also seen some ISV's building "fat compound views" to mimic VAJ and they are going down the wrong path.
• I would also go back to the feedback above - it raises a good point. An observation from it is: are we mixing the need/motivation to replace vs. opening a new perspective. Specifically is the real issue that loss of context occurs when editors get dropped and does it matter if we simply "rearrange views" (e.g. if nav view existed in perspective 1 and, pespecitve 2 also has a nav, then it is literally the same nav instance) or the views are literally different views.
  
  An extension to this question is what is the behavior if the view does exist in both perspectives and the user closes it in perspective 2 (i.e. after seeing it in perspective 1 then switching to perspective 2)
  

</Greg>

 

Feedback: "You wish to "encourage the use of multi-window mode for perspective creation rather than multi-page mode."  This will significantly impact startup time, one of the advantages of multipage-mode it that you only need the plug-ins for the visible parts on startup. Perhaps a common multi-window eclipse use case is having a Resource, Java, Debug, and Team perspective open.  "

Response: For the novice user this should not be a common scenario.  Instead, they will have a collection of views open within a single window.  Besides, the implementation should conform to the user preference, not influence the user.

 

Feedback: "How does the user "Close" a perspective. The "replace" implementation we have now keeps the old perspective, ie, garbage that could be disposed if the user never uses the replaced perspective anymore. Now, the UI  shows the "pages" (calling it perspective) and the user manages it. Are we going to add the concept of "perspectives" and give it a name? I like this "replacing" idea which will simplify the UI but I do not like the idea of garbage that will not be collected because we do not give the user a option to close a "perspective".

Response: If the perspectives are exposed in the shortcut bar, rather than a drop down list box, then perhaps the close UI we currently have could be reused.

<Greg>
Closing the perspective using the shortcut pop up, or the perspective pull down is suboptimal. Some users don't even find it initially because they are looking for the more typical close box.
</Greg>

 

Feedback: "It seems like we are adding new concepts without explaining the user what they are. I would like to see a simple preference
option: "Share context between perspectives" and depending on this setting we would map what the user knows as perspective to
"WorkbenchPage" or "Perspective""

Response: Perhaps it would be good to review the terms in the UI.

<Greg> There is more to the feedback than a "ui term" (imho) . There are two very important points from the feedback

• We haven't really defined what the salient points are to losing context (imho). How does one actually get lost. The proposal covers a number of issues but they are not all tied to losing context. What are the main reasons - is it that I lose editors is it that navigation is difficult, is it that everything looks the same?
• We are talking about some implementation aspects (in a sense) - replacing perspectives etc, keeping editors. I think the feedback suggests that we have to understand how a user wants to work with perspectives (what context actually means to a user) and then figure out what mechanisms to map that to & rather than present mechanism choices in a preference we should present something high level - at least that's my interpretation of the feedback

</Greg>

 

Feedback: "The "open perspective" action should open a new perspective UNLESS a perspective of the type is already open. Then that perspective should be activated.  Users like to have multiple perspective open, just not of the same type!"

Response: Our feedback has indicated that most users are confused by the context separation caused by pages.  The goal of this proposal is to actually reduce the number of pages the user has open.  To restate: if you open a page on an object, like an IResource, and there is no page for the IREsource, we will create a new one.  If there is a page already we will activate it.  This is goodness for novice users, as you can regain context.  If you are an advanced user, you can clone the page, or change the options.  This should meet your needs.

 

Feedback: "Instead of having an Open Perspective action in the navigator, with a submenu, I suggest having an Open In New Window action, which uses the current perspective.  The user can then switch the perspective easily from the toolbar if needed."

Response: This may be worth considering as we finalize the widgets.

 

 

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.

 

Feedback: "I
would be very careful adding this "flash" method (my opinion, do not add
it at all). For one thing, it will annoy/distract the user seeing something
flashing. The user will just end up clicking to show the view to stop the
flashing so might as well show the view in the first place. The key here
is for ISVs to be more careful when they show a view (could be part of
the guideline book). Like the console example described in the Problem
section, showing console only when errors occur is fine by users, but not
when it is just info messages. "

Response: This is an interesting point worth more consideration.

 

Feedback: "I think the first "Other Solution", to open a few as fast or floating, should be preferred.  Otherwise we have not addressed the major issue of relayout when a new view is opened. "

Response: Agreed.  In fact, there is an option in the preferences to enable this feature now.  We are pursuing it as a preferred solution.

 

Feedback: "For accessibility, we need to be careful with the use of flashing since it can cause seizures in susceptible people (see http://www-3.ibm.com/able/swblinking.html).  Platforms like Windows 2000 have some support for this (indicating that a window needs to be activated, without actually activating it). Using such services would probably be the best approach, but would require SWT support.  I recommend against using "flash" in any API method names, since the actual presentation of notification may differ. E.g. it may map to an auditory notification for visually impaired users. "

Response: Acknowledged.

 

<Greg>

The current perspective icon does not manifest itself in a windows shell. This means the only cue is trying to spot the change in the vertically oriented shortcut bar (not easy) or spotting the words in the title bar. It also means that looking at the windowing system's task bar there is no distinguishing icon to help quickly spot the appropriate workbench window if you have more than one open.

</Greg>

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.

 

Feedback: "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."

Response: In most applications, the undo stack contains model actions, but does not contain UI actions.  For instance, the movement of toolbars in an app does not create a new item on the undo stack.  Perhaps this represents a general belief that the user is more interested in interaction with the document, not the user interface, so you don't clutter the undo stack with ui gestures.   UI interaction is also unconscious for the user, whereas doc interaction is conscious (the focus of attention).

<Greg>

• Disagree with feedback - as can be seen from many comments on undo/redo proposal, using the undo stack for ui gestures is not preferred.
  
  
• My hunch is locking will not get heavily used because the times when I want to rearrange I have to do a two step dance first.
  
  
• Also what does it mean to have a perspective locked and then ask to show a new view - does the locking getting ignored?
  
  
• I would prefer to go with - ability to save my perspective, reset and the proposed approach. I might be persuaded to agree with a simple "oops" undo my last ui rearrangement but it would not be done on the undo stack. By I also agree with David that sometimes I have done it and not even realized I have done it.

</Greg>

 

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.

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.

Feedback: "Perspectives are task centric." I believe 
this is an overall optimistic statement... For me, perspectives are just setting 
the context in which I - the user - decide about the tasks I want to purse.  
"

Response: You may be right :-)

<Greg>

• Ex. of feedback.
  One of the reasons why loss of context is even occuring is becuase in order to accomplish a task (such as the fast/tight develop/debug cycle when shaking out your classes for the first time) you often end up switching perspectives. (Of course some users probably don't even realize they could combine the two perspectives into one and just keep switching back and forth). I think your brief mention of workflow is probably more in keeping with the macroscopic task issue. However we should not lose sight of the fact that a pespective allows you to collect functionality together that you will jump into and use for a while. It just turns out as usual that sometimes you do that and sometime you don't. Bottom line - your both right imho<g>.
  
  
• I am concerned weare drawing generalizations from the java and base perspectives tooling. Are we really sure people do not know the purpose of each perspective? Is the problem primarily with the resource perspective?

</Greg?

 

 

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

 

<Greg>
Meta Note (not necessarily related to the above guideline suggestions) --
So far experience is showing that UI guidlines tend to be followed if they are the basic kind. But we are seeing some ISV's trying to bend the navigation model so that things look exactly the way they do in their current product. My view is that ui guidelines are good, but where we can we have to enforce them with policy.
</Greg

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.

Feedback: "Maybe we could place the openPage method on IWorkbenchWindow instead (make more sense it seems). We would need to also "disable" the other public methods that allow opening in a new window, adding a page, replace current page, etc - it is a big usuability no-no to provide a setting to the user but having some plug-ins ignore it (not that it is done intentionaly, but most likely not too many know about this preference). We could leave the old api there and just redirect to the openPage method."

Response: IWorkbenchWindow already has a method called openPage.  These methods open a page in the window, where you would expect.  It is much better to put the new openPage method on the IWorkbench class, at a level where there is no implicit location for the new page.  As for the existing methods, it would indeed be good to redirect them as appropriate.

 

<Greg>

Proposal identifies the issue - "Background - Perspectives do not, currently; filter the visible actions in a view, editor, or context menu." but does not appear to address it?

</Greg

 

 

---