Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[platform-ui-dev] Response to Feedback on Loss of Context 
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.


(See attached file: ResponseToFeedback1.html)

Dave
Title: Request For Comment

RFC: Loss of Context (Response to Feedback)

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

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.

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.

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.
 

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

Feedback

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.

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.

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.

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

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.

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.

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.

Feedback

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.

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.

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

Feedback

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.

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.

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.

Feedback:

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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

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

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

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 :-)

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.

Feedback

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.

Back to the top