Comments on RFC Loss of Context - Draft 1

["Nick Edgar/OTT/OTI" <Nick_Edgar@xxxxxxx>]

Apparently Notes dropped my attachment.  Here are my comments again:








"David Springgay/OTT/OTI" <David_Springgay@xxxxxxx>
Sent by: platform-ui-dev-admin@xxxxxxxxxxx
11/20/01 03:59 PM
Please respond to platform-ui-dev


        To:     platform-ui-dev@xxxxxxxxxxx
        cc:
        Subject:        [platform-ui-dev] RFC - Loss of Context Proposal
(end date = 11/27)


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

(See attached file: Proposal.html)



(See attached file: LossOfContext.html)

Comments on RFC Loss of Context - Draft 1

By Nick Edgar
November 22, 2001

Here are my comments on the RFC: Loss of Context - Draft 1.
I am in strong agreement with the overall direction of the proposal.

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

Will action delegates be instantiated and initialized if the plugin is started via some other means other than action selection, e.g. open perspective, or show view?

Regarding the open perspective combobox:
I like the idea of a globally consistent MRU list. This will help avoid the "can't get there from here" type of problems we are currently seeing.
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.
Also, the combobox needs to have a label, e.g. "Perspective:", or at least a tooltip explaining what it's for.
In general, we need to be aware of accessibility issues for any new UI.
For more detail, see http://www-3.ibm.com/able/guidelines.html.

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.

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

The new project wizard framework should support this kind of scenario.

Regarding the proposed decorator service:
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.

Regarding linking between Navigator and editors:
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.

In the sections on page activation and view activation, you mention using flashing. 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.

--end--