Re: [platform-ui-dev] task, problem, and bookmark views

[Randy Hudson <hudsonr@xxxxxxxxxx>]

I may have 2000 markers (mostly auditing
warnings), but that works out to less than 4 per file.  since I have
the Tasks View configured to show "selected resource and children",
then managing 4 markers per Editor is not really an issue.  The new
views are actually less productive than before.  Everytime I open
editor, I need to check two different views instead of one to identify
all of the work items (i.e. ToDos + compiler warnings + missing JavaDoc).

There is also the consideration of workspace
migration.  When I shut down 2.1, all views will be persisted.  Then,
when I reopen under 3.0, the old view will be restored, but the first recompile
will cause a second, similar view to be opened.  Also, all of my customized
perspectives will still be using the old view ID when opened.  This
change is not very migration-friendly.

I'm disappointed to see 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=37974
rejected.  I think adding
"task sets" to the exising Tasks List is better from both a usability
and migration standpoint.  If anyone else cares, please follow-up
by CC-ing/commenting the bugzilla.

"Kevin McGuire" <Kevin_McGuire@xxxxxxxxxx> Sent by: platform-ui-dev-admin@xxxxxxxxxxx 05/21/2003 06:39 PM Please respond to platform-ui-dev

To:        platform-ui-dev@xxxxxxxxxxx         cc:                 Subject:        Re: [platform-ui-dev] task, problem, and bookmark views

From Randy's comment, 
>>I'm sometimes sorting through 2000 problems. 

I was going to say that maybe he should try writing better code :)

But actually this denotes a problem in the way the, err, problems are being
presented. I think we can agree that the current filtering mechanism doesn't
help. Often when there are tons of errors there are actually a few key
ones that generate the rest.  For example, a missed import in java
can make a real mess.  In this case, a better presentation might be
to just list the resources which have problems, then expand to see the
actual errors.  I am guessing this is what Randy had in mind when
he mentioned tabletrees? 

Better still would be more structure to the error markers with plugins
making use of this.  Presently in the case of the missing import,
you first get an error on a missing class, an instance of which say is
assigned to a variable, then you get an error for each use of that variable.
 A good programmer always looks for the first one, knows the others
are just chaff and tries to ignore them.  Better reporting would do
just that: have the first error as the parent/cause and subsequent ones
as children/effects which could be dealt with differently in the UI (e.g
hidden, de-emphasized visually through use of a different icon, etc.).
 Another approach might be the ability to group the errors by type
(e.g. unresolved reference).  Just some random ideas.


Our experiments (on VCM) with 'helpful' generated tasks were disappointing
because for the most part they were ignored or never seen.  We assume
this is because there was so much clutter in the task view that people
didn't find our helpful ones there.  So perhaps a second view would
solve this, but I really don't know because I haven't been given any information
which explains why we chose these particular changes (if I've just missed
that email then apologies). 

I take it that the current changes are just random experiments, and if
so then that's fine, but people need to know the context/motivation for
what they are evaluating (is it an experiment? a prototype? what problems
is it attempting to solve? what's the 'vision'?). 

What I'd like to see is a systematic analysis of the ways in which the
task list fails, with an explanation of why a given set of proposed changes
would fix it. Such an analysis, ideally backed by UCD usability session
data, is *critical* for hitting the mark with a new task list.  Without
it I don't think you can expect buy-in from the community (and without
it there'll just be swirl). 

Kevin 




----- Original Message -----
 From: Randy Hudson
 To: platform-ui-dev@xxxxxxxxxxx
 Sent: Wednesday, May 21, 2003 10:07 AM
 Subject: Re: [platform-ui-dev] task, problem, and bookmark views


 I would prefer to see a single TaskView that is more efficient than the
current version. I'm sometimes sorting through 2000 problems.  Splitting
that in half doesn't really solve the problem.

 Maybe the two new views already do this, but if not, why not first
experiment with tabletrees, filters, modes (like "problems" and
"tasks"),
and other approaches to improving the management issue.

 As a user, I would prefer one view that works well.  This change
goes
against the "Reduce Workbench Clutter" line item.  It is
also going to
confuse users who already know how things work.

 -randy

----- Forwarded by Kevin McGuire/Ottawa/IBM on 05/21/2003 06:02 PM -----

Chris McLaren/Ottawa/IBM@IBMCA Sent by: eclipse-dev-admin@xxxxxxxxxxx 05/20/2003 04:11 PM Please respond to eclipse-dev

To:        eclipse-dev@xxxxxxxxxxx, platform-ui-dev@xxxxxxxxxxx        cc:                Subject:        [eclipse-dev] task, problem, and bookmark views

Recently the TaskList and BookmarkNavigator views were largely rewritten.

The functionality of TaskList is replaced by two new independent views:
'TaskView' and 'ProblemView'. The functionality of BookmarkNavigator is
replaced by the new view 'BookmarkView'.

These three new views are now used instead of their predecessors in the
'Show View' menu for the resource perspective, I encourage writers of 
other perspectives to do the same.

The older views, TaskList and BookmarkNavigator, still remain, and can
be 
found in the 'Show View' dialog in a category named 'Deprecated'.

All new code in org.eclipse.ui.views is currently in internal packages
to 
avoid committing any new API at this time.

Please forward me any questions,

Thanks,
Chris.