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

[Tod Creasey <Tod_Creasey@xxxxxxxxxx>]

I suggest we move this to platofrm-ui dev as it is something people will 
want to understand generally. Wayne I assume you are on platform-ui dev - 
let me know if not.

>For views, the semantics aren't as clear:
>a) The big question: the Show View dialog currently filters out views 
>based on activity, but should the Show View dialog also further filter 
>context bound views? i.e. Should the user be restricted to only be 
allowed 
>to open views that are currently in context?

I think what we have now is right. The activities API is used to support 
progressive disclosure - that is only showing functionality as it becomes 
useful to the user so as to reduce clutter and make the inital user 
experience better. As a result it is quite static - it is likely that a 
user would settle down to a pretty consistent set of activities after they 
have been working for a while.

Contexts solve a different problem - that is functionality that is only 
useful when some condition within the workbench occurs (i.e. I am looking 
a stack trace in the Debug View). These are much more dynamic. 

I think binding things like the views in the Show View dialog or wizards 
to a context would just be frustrating for the user and difficult to get 
the workflow right for. Binding something like the available commands to 
context is more appropriate.


>b) One might define that a particular view is to be opened and brought to 

>the top when a particular context becomes active, but another view is 
only 
>to open itself on the bottom of a stack such that the user notices only 
>the tab appearing. 

I think this is a good use case for contexts. The user could still get the 
view if they really wanted it using Show View but when the context becomes 
active it might be required hence worth opening. Once again basically the 
same thing as the current switch to the debug perspective when you start 
to run something.


>c) There might be some user defined behavior here as well - preferences 
to 
>open certain views based on certain contexts. 
Sure. Essentially the same idea as b - just configurable.

>d) Also there might be some user-defined behavior on how those views 
might 
>hide themselves once one leaves a context. How do we distinguish those 
>views that might contain residual information (logs, etc.) that you might 

>not simply want to disappear just because the debug target terminated, 
vs. 
>those that can disappear automatically (variables view, maybe?).

I think this might confuse the user if thier layout changes all of the 
time on them without a clear idea why. I think this will largely shake out 
by the behaviour in b. I can't really think of a use case myself for this 
scenario so I am not sure that it worth doing.

Tod