[platform-ui-dev] Activities and Contexts - Important Update

[Chris McLaren <Chris_McLaren@xxxxxxxxxx>]

1. Recent feedback from our usability
lead suggested some changes to the roles and activities framework. Primarily,
that the concept of 'roles' be removed from the activity framework and
in its place activities should be grouped by category. This, in a way,
is a subtle change - 'roles' effectively were means of categorizing activities.
Calling this grouping mechanism 'category' removes some of the semantic
weight that comes with the term 'role'. 

These changes mean that:
a) the org.eclipse.ui.roles extension
point is removed.
b) IWorkbench.getRoleManager() and associated
code is removed.
c) the org.eclipse.ui.activities extension
point is extended to allow definition of categories as well as the association
between categories and activities.
d) IWorkbench.getActivityManager() is
extended to provide java api to categories.


2. We've recently come to the understanding
that the activity work is really two distinct parts, as evidenced by two
sets of use cases that don't overlap:

a) Part one - Limit available functionality

This part of the activities work allows
the user to select a subset of available functionality. Any functionality
not selected is simply not available in the product. 
Some applications call these individual
pieces of functionality 'modules' or 'components', we call them 'activities'.

This part is analogous to how an install
application works. The differences between this and an install application
are:
i) it can be changed on the fly. (with
an install application, a user typically needs to exit the application,
reconfigure, and restart)
iii) there are various trigger points
in the application which could cause it to change. (some applications have
this ability as well - microsoft word, for instance, will automate its
setup application to install conversion filters if you try and open a file
without the correct conversion filter installed)

Activities can belong to one or more
Category. Activities can require one or more activities to be enabled before
they can be enabled. Activities are bound to functionality via 'pattern
bindings' a mechanism to associate an activity with identifiable objects
in the product. (think 'id' attribute in plugin.xml elements) Any activity
(or a category as a whole) can be enabled or disabled by the user (respecting,
of course, the fact some activities require other activities)

It is this part that is of importance
to the scalability concerns of preference pages, help content, etc. These
use cases care about limiting available functionality. As well, it is this
part that most complements the work happening in Equinox.

b) Part two - Distinguish what the user
is actually doing

This part strives toward an adaptive
user interface which changes depending on what the user is doing. With
this part, an application could highlight the most needed functionality
to the user on menus and toolbars, choose the correct set of key bindings
for particular uses, show and hide views automatically, etc. The application
determines what the user is actually doing and various systems react appropriately.

We call what a user is or is not doing
a 'context'. Contexts can require one or more contexts to be active before
they can be active. Any context can be activated or deactivated by the
application (respecting, of course, the fact some contexts require other
contexts)

It is this part that is of importance
to the scalability concerns of the debug team. This use case cares about
showing the most appropriate functionality and hiding functionality that
it 'out of context'. That functionality could be views, or commands/actions,
etc.

c) Differences between part one and
part two

Part one is defined by the user. The
enabled state of activities is persistent - independant of what the user
is actually doing. It defines what the user could do.
Part two is defined by the application.
The active state of contexts is transient - dependant on what the user
is actually doing. It defines what the user is actually doing.

Currently, we are giving the term 'activities'
to both the 'activities' of part one and the 'contexts' of part two. It
has been proving difficult to align these two precisely. 

For instance, there might be an activity
called 'Java Development' which the user can explictly turn on or off (or
is turned on or off on behalf of the user via a trigger point). There might
be a context called 'Debugging' which is turned on or off by the application,
depending on whether or not you are currently debugging a target application.
'Java Development' is not necessarily a context that the application turns
on or off. 'Debugging' is not an activity that the user would choose to
turn on or off.

There is a relation between activities
and contexts, sometimes one to one. That relation is simply the same relation
that activities has to any other system - the ability to filter it based
on pattern bindings. i.e. Certain contexts might not even be available
to be activated or deactivated by the application if they are filtered
out by activities.

d) What I would like to do from here

Following M5, I propose to add a distinct
'context manager' with a contexts extension point. Clients of part one
would change very little, most likely not at all. Clients of part two,
like the debug team for instance, would require to rename a few things
but would otherwise be unaffected.


Questions?
Chris.