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

[Chris McLaren <Chris_McLaren@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.

This was already on platform-ui-dev.


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

Filtering doesn't necessarily mean 'not showing'.
In fact, I would expect 
that Show View dialog would filter by simply 'lowlighting'
(i'm trying to 
imagine here a 'faded out' label that is distinguishable
from 'disabled'..)
those views not currently in context - views that
are effectively empty and 
useless until the user starts doing something different.
This gives a clear 
indication to which views aren't useful right now
without causing the user 
to say 'where's my view? i just saw it a second ago
and now i can't open it!'

I think it would be a great benefit to the UI to have
this functionality but
it suggests declarative API for binding view to contexts
such that workbench
systems (such as the Show View dialog) can have this
information to process.


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

Putting tools in front of a user is one half of adaptive
UI - taking them
away is the other half. Think 'surgeon's assistant'
- 'nurse: scapel, 
sponge, etc..'

I want views to both open and close automatically
where possible. My 
feeling is that if the UI made a mess, it should clean
it up.

I don't think anyone is currently hiding views programmatically
in the UI, 
but Wayne does have a clear use case that I agree
with. 

I'm further suggesting that we might distinguish those
views that 
could potentially hide automatically based on leaving
a context vs. those 
that should require more of a state change (like an
explicit user action).

Personally, I think as soon as a view is empty and
useless outside of a 
particular context, it should get lost. 'Empty and
useless' here means no 
enabled commands, residual information, or state (other
than user 
preferences).


Chris