Comments
in blue. The +1 and -1 you see are just a _expression_ not a vote. +1 == I like
it and -1 == I don't like it.
Request For
Comment: Loss of Context
Topic: Loss of Context
Last Modified: Nov. 19, 2001
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.
[EJP] If you
implement "3" you don't need "2". I don't like the idea of
adding new API that we will have to maintain without getting much back. Why do
we have to treat Navigator as a special view? If we expose the navigator
actions we will end up having to expose all UI actions. Even if we expose the
action classes, all other navigator-like views would have to add the actions to
their views anyway.
Can't we treat
Navigator like a view without any important action and all the important
actions would be contributed through the same API we give to the ISVs to extend
navigator. For example: The Team menu is added by the VCM to any IResource
object and since it is (will be) a object contribution the action will appear
in other views as well. The same should happen to actions like "Open
project". It should not be in the navigator, it should be a contribution
to the Navigator.
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:
[EJP]
And it will always be weak until we give the plugin the change to run code on
startup. Will we will not be able to say "No" forever?
Since
I am sure we will end up letting plugins to be activated on startup it would be
nice to think about it now. It may be better to think about it then coming up
with all sort of solutions for enablement that will not really fix the problem.
I like to have eclipse starting up as fast as possible but is it enough
argument for it?
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.
[EJP]
We would have to have some way to custumize it and let the user decide which
decorators he wants to see. I don't see other way to handle multiple
decorations.
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.
[EJP]
How does the user "Closes" 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".
I
am not sure about the combo box we have now. I like the UI as simple as
possible. What about the shortcut bar? I mean, depending on the user
preferences he would see "Windows with Pages" or "Windows with
Perspectives" so the shortcut bar would show pages in the first case and
perspectives in the second. The Preference Page option would be some thing
like: "Share context between perspectives".
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.
+1.
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.
[EJP]
Again a new special case in the navigator. :-(. Either we tell the user the
both concepts (pages and perspectives) or we give him only one without showing
a bit of the second.
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.
[EJP]
In case of VAJ we have "views" completely linked and sometimes I feel
lost when the hierarchy view (for example) is not in sync with my active
editor.
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.
o many project actions appear in Navigator but not in
Packages view.
o many of the standard resource oriented actions are missing
from ISV views.
o 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).
o 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).
o 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?
o 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).
o 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.
o 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.
o sample: "add annotation, add unique, add key, delete,
undo, redo"
o sample: "add element to content model, add group to
content model, undo, redo, cut/copy/paste, delete".
o 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:
o 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:
o 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).
o 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
o 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
o 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.
o 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.
o 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.
o 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.
o 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:
o 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.
o 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.
o 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
o 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)
o pro: establishes better workflow between previous and
current perspectives.
o 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.
o pro: we give ISV's a predictable way to reuse the
functionality in their own views.
o 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.
o issue: what happens when ISV's want to intercept/override
these actions. (e.g. rename in navigator vs rename in packages view)
o issue: need to track requirements from other teams (e.g.
VCM - there is a desire to support pessimistic work model)
o issue: need to make sure that ISV defined action groups can
also be propagated. (e.g. VCM team actions)
o 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.
o pro: resource actions appear everywhere that a IResource is
visible.
o pro: we can say IResource is the common medium for
integration between plugins in the UI.
o issue: if an action is targeted to IResource and something
else, the same action may appear twice in a context menu.
o 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.
[EJP]
Again: I think that making Navigator a special view is not a good idea. We
should encourage ISVs to add object contributions which would end up in the
navigator for free as well as in other views.
o pro: establishes a good coupling between the object and the
actions which are available.
o 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.
[EJP]
This is the first thing I disabled when I started using Eclipse. I always get
lost when that happens.
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
o issue: what happens when user creates their own perspective
(eg. Java, Debug)
o issue: this is related to manipulating natures and builders
(see project nature doc)
o issue: is this only a problem with the "simple"
project type.
Other Solutions:
1. encourage ISV's to
add a "Show in Navigator" action.
[EJP]
Please, don't. This means: don't add the actions needed in this view. See the
"Synchronize" view. Instead of having the option "Replace with
Stream version" in the view they have the "Show in Navigator"
option which is a pain.
o pro: when all else fails, there is an action to get back to
the resource centric world.
o issue: ISV's may implement this in an ad-hoc fashion. Developer guidelines are needed to
ensure consistency.
o 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.
[EJP]
IMO. The standard resource actions should be object contribution actions.
o pro: an existing mechanism can be used.
o issue: it is currently impossible to define accelerators
for popup menu actions. Additional
work is required.
o 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".
o 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".
o 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.
o pro: makes it easier to create objects
o pro: makes it easier to regain context for a particular
object.
o 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.
o pro: we reduce the inconsistency by reducing the number of
navigator-like views.
o con: we increase the complexity of the navigator by
increasing its flexibility.
o con: we increase the workload for those ISV's who already
have a navigator-like view.
o con: we increase our own workload by creating a
navigational hot spot and we are not domain experts.
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.
o add some new element, such as <group id =
"x">
o OR specify that you can use an existing action as the reference
location for another action.
o 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". .
o pro: encourages consistency within the user interface,
making the product easier to use.
o 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.
o pro: solves product case
o con: does not address case of general extensibility
Problem:
Decorator Loss (Version #)
Note: currently all decorators
are implemented outside the platform, so it is impossible to share these
decorators in code. We must use an
extension point. The experience
with popup menu extension demonstrates that decorator sharing will be difficult
because of the protocol mismatch between an abstract decorator and the actual
presentation model in each view.
Preferred Solutions:
1. implement an object
oriented decorator service. To do
this, we will define a decorator extension point. Each extension declares a name and target type. A view may contain many types, so the
view should register those types with the decorator service. In response, the service will return a
list of decorators which may appear in the view and, if the user selects one,
the decorator will be applied to the presentation. At most one decorator could
be active in a view. Decorators
may change asynchronously, so some interface should be defined to support the
callback.
o pro: the version decorator can be shared in an abstract way
o pro: additional decorators can be added
[EJP]
The user should have the change to select as many as here wants and the order
of the decorators as well.
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.
[EJP]
Every thing would end up being a table tree. Couldn't the label provider return
a decorated label. So the user would have a check list with all decorators and
a UP and DOWN button to change the order? The label could be one of the items
so the user could say what comes before the label and what comes after.
o pro: lots of user customization is possible
o pro: supports generic extension of presentation with
sandbox model
o con: lots of work
2. if the underlying
widget would support "owner draw" the decorator mechanism can be
improved significantly. As it is now the UI is constrained to provide (at most)
one icon and (at most) one string per item in the widget.
Problem:
Action Enablement
Note: currently the enablement
of an action before it loads is controlled in XML. When an action is invoked the delegate is created, and it
can control enablement from that point on. The other delegates in the plugin are created if a selection
is made in the workbench.
Preferred Solutions:
1. if one delegate in a
plugin is instantiated, instantiate the rest.
o pro: lazy loading strategy is maintained
o pro: increases the accuracy of action ennoblement after the
first action is invoked
o 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).
o pro: increases the accuracy of action ennoblement before
the first action is invoked.
o issue: it may be impossible to describe every scenario.
o 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.
o pro: increases the accuracy of action enablement before the
first action is invoked.
o pro: does not load additional plugins
o pro: supports boolean _expression_ evaluation
o con: forces developers to learn _javascript_.
2. implement the action
enablement code in a baby plugin
o pro: action enablement is performed accurately in java
o 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.
o pro: complete accuracy of action enablement whenever
visible
o 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
[EJP]
I am open to this idea. We could show the user the time each plugin is taking
to startup and he could disable its activation on startup and/or disable it completely
next time the workbench runs.
o pro: actions will be enabled correctly
o con: very poor startup time
o con: the preferred subset may change dynamically, depending
on user task. There is no way to
predict this.
5. start all plugins at
startup
[EJP]
-1.
o pro: actions will be enabled correctly
o con: very poor startup time
Problem:
State Loss due to Linking
Preferred Solutions:
1. encourage developers
to use "Show in XX" rather than linking, where possible
[EJP]
I would prefer a "Sync All" option. Otherwise we would end up with
too many Show in XX option.
o 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.
[EJP]
+1.
o pro: default behavior is non-intrusive.
o pro: power users can turn it back on.
Other Solutions:
1. implement a global
switch.
o pro: a single place to turn it on or off.
o con: is not context sensitive.
Problem:
State Loss due to Perspective Separation
Preferred Solutions:
1. in order to avoid
the creation of too many perspectives, we can change the default mode for
"open perspective" to "replace". In this mode, the "open perspective" menu item in
the Perspective menu will be removed, and a drop down list box containing a perspective
list will be added to the toolbar.
If you select a perspective from this list, the existing views in the
perspective / page will be re-arranged to suit the new perspective.
[EJP]
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"
o 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.
o pro: the active perspective is more visible.
o pro: it reduce the number of pages in the workbench, so the
novice user is not overwhelmed by pages.
o 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.
[EJP]
We should think better about this option in the navigator. It should follow the
rules as well as any other action.
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.
[EJP]
+1. If clone is implemented.
o pro: eliminates the creation of redundant pages / windows
in the workbench.
o pro: makes it easier to find a page which is already open.
o pro: establishes an object model in the workbench which is
predictable.
o 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.
o 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.
o pro: the user can correct the loss of state
o con: the interface would be incredibly complex.
o con: it is one more thing the user needs to learn.
o con: it is technically, very difficult to implement.
Problem:
Page Activation causes Disorientation
Preferred Solutions:
1. implement a temporal
strategy for activation and closure. If a page is closed, activate the MRU page
so the user doesn't lose context.
Perhaps a back and forward button would be useful.
2. in order to clarify
the separation between perspectives, we will encourage the use of multi-window
mode for perspective creation rather than multi-page mode. This may lead to window overload. However, if the "open
perspective" menu item is replaced by a "perspective list box",
this change will only be apparent to people who open a new perspective using
"Open Perspective" in the Navigator).
o pro: clarifies the separation between one page and another,
by using windows.
o pro: reuses the window management offered by the operating
system.
o pro: reduces the complexity of the Eclipse page and window
management UI.
o pro: window explosion is only a problem for experienced
users who choose multi-window mode.
o 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.
[EJP]
See the way notes implements fast views. I am not sure if this
"flash" thing will look good in all platforms and machines.
o con: this has to be very subtle if it is too
"flashy" it will be frustrating
o 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.
[EJP]
What about a guideline.
o pro: removes problem case
o con: api change.
o 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.
[EJP]
I have used it and I like the fast view option.
2. remove the public
API for opening and activation.
o pro: removes problem case
o con: api change.
o con: in some situations it is appropriate to activate a
view. For instance, if an error is
displayed in the console view it is helpful for the view to appear.
Problem:
Accidental Layout Change
Preferred Solutions:
1. fix sensitivity of
direct manipulation.
[EJP]
I am not sure if this is still a problem. I got tired of it and I have fixed
few places and I this is not happening with me anymore.
o pro: will hopefully resolve the problem.
o issue: there may be some cases where accidental layout
still occurs.
Other Solutions:
1. add a "lock /
unlock layout" action to disable direct manipulation.
[EJP]
-1. Direct manipulation is a nice feature.
o pro: reduces incidence of accidental layout change.
o 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".
[EJP]
No much work to little gain.
o issue: currently the undo action targets the active
part. Our "undo" would
only be visible if the undo action was temporal.
o 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.
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.
[EJP] That is
why I don't like perspective switch. I have configured my perspectives as I
like them.
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.
o Issue: Who decide which perspectives are useful. It is a reflection of user, not
developer.
o 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.
[EJP]
Can you give us some examples here.
3. we could limit the
visibility of editors and views to certain perspective. By doing this, we increase the
conceptual separation between perspectives. For instance, it may make sense to not open an editor in the
active perspective if the editor area is hidden. Or perhaps you can't open the resource navigator in the team
perspective.
Problem:
Developer Confusion
Preferred Solutions:
1. publish guidelines
in cooperation with usability professionals
1. if operation is
short lived use view.
2. if operation is long
lived use separate window.
3. if view / editor has
multiple viewers use separate window.
4. if view / editor is
in a significantly different domain then use separate window.
Other Solutions:
1. we demonstrate our
ego, and critique everybody
1. con: this is a big
waste of time
Problem:
Inconsistent Perspective Open Implementation
Preferred Solutions:
1. add an openPage
method to IWorkbench which will open a page in the correct mode.
o pro: developers don't need to examine perspective
preference.
o 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.
[EJP]
Please don't let them close my pages :-).
Other
Solutions:
1. it would be great if
we could collapse the window and page class into one to hide presentation.
o con: this would be a breaking API change.
o pro: hide presentation of pages, increasing consistency
when opening pages.
o pro: reduce complexity within internal API. There would be no more need to iterate
over windows, pages, and parts.
o pro: reduce complexity in UI.