Closed Bug 36013 Opened 24 years ago Closed 16 years ago

Use color to indicate severity in bug lists

Categories

(Bugzilla :: User Interface, enhancement, P4)

enhancement

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: mpt, Unassigned)

References

(Depends on 1 open bug)

Details

Attachments

(4 files)

At the moment, engineers often attach `[RFE] ' to the Summary lines of bugs which 
are already marked as `enhancement'. The argument is that this makes them easier 
to see. Therefore, the current means of highlighting enhancements in bug lists is 
not working as well as it needs to, and an additional (automatic) method should 
be used.

I propose that color be used in bug lists to indicate the severity of a bug. This 
would make it a lot easier to scan a list for RFEs -- or, for that matter, for 
blocker or critical bugs.

I suggest the following colors:
* blocker     = #cc0066
* critical    = #cc0000
* major       = #660000
* normal      = #000000
* minor       = #003366
* trivial     = #336666
* enhancement = #006600

These choices would need to be checked with color-blind users to ensure they were 
all readable.

It would be best if this was implemented using a style sheet
(<div class="blocker">, etc), rather than as a hard-coded FONT tag, to allow for 
easier changing of the formatting in other Bugzilla installations.

Note that this bug clashes with bug 28884, which suggests using different colors 
for confidential/non-confidential bugs.
Colour is an important vector in visual differentiation.  The fact that there's
two proposals wanting to use it (and I think you might find lots of other uses)
suggests we might want to consider a more general proposal.

I'm not sure exactly what form this might take, but a simple one in a query
would be:

Highlight = Field Relation Value

where when this expression is true, the line is red instead of black.

You might want to be a bit more complex though, to have multiple highlights.

I suggest this feature shouldn't come up until you press a button though, as
there's no need to confuse users with yet another feature on the query screen.
These color schemes we come up with here could be useful for bug 20392.

An alternate solution to the RFE-finding problem is to allow bugzilla users to 
move the severity field right before the summary field.
Or you could put it in the user preferences rather than the query screen.

And you could be simple about what choices you want to provide the user -
basically let them choose a field to distinguish on, and automatically determine
the colours from a predefined list.
this has to be a user preference too, because of our friends, the colorblind. 
(and i've worked with a lot of colorblind people)
See also bug 66007.
Depends on: 69654
Target Milestone: --- → Future
No longer depends on: 69654
Blocks: 69654
mpt says on n.p.m.seamonkey:

> I filed this over a year ago [...]. IMHO, it's probably the most easily 
> implementable usability improvement for Bugzilla currently.

Clearing milestone to trigger re-evaluation.
No longer blocks: 69654
Target Milestone: Future → ---
Blocks: 69654
Oops, didn't mean to change the dependency. Thanks Jake for restoring it.
It sounds easy, but there are two complicating issues:

1.  I doubt people just want to do this for severity, or even that severity
would account for over 50% of what people colour code on.

2.  Even if we do do this just for severity, severities are not hardcoded into
Bugzilla, so these colours can't be either.  Therefore we need to provide a way
for the administrator to edit them.
OK sorry, mpt suggested using external CSS, so I guess 2 doesn't apply.
Is highlighting best when applied to some columns (as in the example
attachments), or should it be applied across the whole row?

So, regarding 2), would the css class names be the same names as, say, the
severity fields? This would restrict what could be used as severities though,
wouldn't it?

And regarding 1), you could have different css classes for priority, and for
severity, and maybe another for, say, certain keywords, and let CSS just merge
them all, and see what style results. (e.g. the css for priority could set
background patterns, and the css for severity could set foreground text colour?)

Or, if only, say, the priority and severity columns were coloured, then they
could have their own css classes.

But, of course, it is nice to be able to determine some overall colour (or
style) for a bug, as a whole, and then other things relating to the bug can be
coloured appropriately, e.g. the title when viewing a page.
you could always make the class name contain both the field name and the contents 
being flagged.
In terms of colour, I like the second attachment the best.  If the colour was 
across the whole line it might be hard to read.
I'll attach 2 patches in a bit, for comment and discussion.

The first attachment is the start of a bugzilla stylesheet: 'bugzilla.css'.
Include this into bugzilla using either the patch on bug#69654, or better still,
refer to the comment in that bug and add it to the headerhtml param.

The 2nd attachment is a patch to buglist.cgi and globals.pl. (The globals.pl
patch is just to use css for the resolved strike-through and the unconfirmed
italic text.) The patch to buglist.cgi is more relevant to this bug, in that it
highlights bug lists as per the 2nd example attachement.

There are lots of things still to do, such as a param to turn this off (globally
+ per user), and highlighting of the title of a bug in show_bug.cgi, but this is
a start.

Note that I, as a partially colorblind person, have difficulty differentiating
critical and normal in this color scheme, when they are adjacent to each other. 
Oops. I left some extra changes in that last patch that shouldn't be there. 

It is just some extra stuff in sanitycheck.cgi - no-one will probably want that,
so please ignore it.
Target Milestone: --- → Bugzilla 2.16
Keywords: patch, review
-> Bugzilla product, User Interface component, reassigning.
Assignee: tara → myk
Component: Bugzilla → User Interface
Product: Webtools → Bugzilla
Version: other → unspecified
Myk, how would a CSS dir interact with the Template ideas we were discussing per
bug 86168? If TT supports CSS (which is does, I'm sure) how is the class
specification done?

I think perhaps 86168 could be made into a tracker for all these if we decide to
do templates in 2.16

I tried obsoleting my 2 CSS related attachments on this bug -- but I don't have
the permissions. They are not complete (by a long way), and any css
patches/work/discussion should probably go on in bug#69654, anyway.

(patch+review kws can be removed next time someone updates this bug)

Once the CSS work is complete, then it will allow 'color to indicate severity in
buglists', as required by this bug, (and a lot more!), so should this bug depend
on bug#69654, and not block it?
Attachment #44380 - Attachment is obsolete: true
Attachment #44381 - Attachment is obsolete: true
Keywords: patch, review
Attachment #44380 - Attachment is obsolete: false
Attachment #44380 - Flags: review-
Attachment #44381 - Attachment is obsolete: false
Attachment #44381 - Flags: review-
"Obsolete" doesn't really apply to the latest patch on a bug.  Until there is a
newer patch, the latest patch should be marked "needs-work" if it isn't ready.

It may take some time to shake out the issues that come up with the patch
tracker (i.e. whether or not a user without "editbugs" privileges should be able
to edit an attachment they attached).  Problems like this should be filed as
bugs against the Bugzilla product, "Creating/Changing Bugs" component.
(I just created bug#97731 about the being able to edit your own attachments thing)
> Is highlighting best when applied to some columns (as in the example
> attachments), or should it be applied across the whole row?

To the text in the whole row. Firstly, you don't know which columns the user has
visible; and secondly, color-coding whole rows would also provide a useful
visual guide so that you didn't confuse cells in adjacent rows.

Implementing this requires three steps. (1) Edit the buglist.cgi code so that
instead of emitting <TR VALIGN=TOP ALIGN=LEFT CLASS=-- >, it emits <tr
valign="top" class="severity_trivial priority_none platform_All status_new
resolution_none">. (2) Implement a default style sheet which applies different
colors to *.severity_enhancement, *.severity_trivial, *.severity_minor, etc. At
that point this bug can be marked fixed. (3) Implement three alternate style
sheets which do color-coding based on priority, on platform, and on
status/resolution.

A pref to turn this off in Bugzilla itself is not necessary, since (a) people
for whom color in general is annoying (such as color-blind people) will have
custom colors turned off in their browser prefs anyway, and (b) those few who
like everything *except* Bugzilla to be colorful can set up their own user style
sheet which will override the one provided by Bugzilla.
The patch on bug#69654 implements parts of 1) -- it add severity and priority,
but not resolution, status or platform. It does add keyword-based classes, and
also classes if you are the assigned_to, or the qa_contact on a bug, so you can
highlight that if desired.

That patch also assigned classes to the columns, so people can highlight columns
 if they want.

There is also a bugzilla.css attached to that bug:

http://bugzilla.mozilla.org/attachment.cgi?id=48877&action=view

which does 2).

I'm not sure how 3) would work (GUI-wise or implementation wise) -- I sort of
thought that styles specified for severity, priority, keywords etc. would just
all get mixed in together, and if 2 background colors were specified, then the
css rules would determine which took precedence.

I think you might need some sort of pref for turning this on because different
browsers have different support for CSS, and so it might be necessary for people
wanting to use the CSS support to turn on a user-pref if they know that their
browser supports it.

While Mozilla handled the nice severity colors implemented in bug#69654, (taken
from one of the attachments on this bug,) IE5 got it pretty wrong.
This is almost a dupe of bug 104247, which is already fixed, except this bug
seems to do a more complete job of assigning classes to all of the severities
instead of just blocker, critical, and enhancement, like 104247 did...
I hope you're not planning to enable this by default, or will at least provide a
simple, reliable way to turn it off.  It was hard enough triaging endless lists
of bugs online, styles just made it worse, and this trend toward making bug
lists look like ransom notes could wind up slowing me to a crawl.  If you must
do this, please do some usability testing, and consider making it opt-in.
We are currently trying to wrap up Bugzilla 2.16.  We are now close enough to
release time that anything that wasn't already ranked at P1 isn't going to make
the cut.  Thus this is being retargetted at 2.18.  If you strongly disagree with
this retargetting, please comment, however, be aware that we only have about 2
weeks left to review and test anything at this point, and we intend to devote
this time to the remaining bugs that were designated as release blockers.
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18
Reconsider what needs to be done here for 2.16.
Target Milestone: Bugzilla 2.18 → Bugzilla 2.16
Blocks: 66007
bug 103778 is gonna obsolete everything done on this so far (which doesn't
really matter since the last patch on here has needs-work on it anyway).

No reviewable patch, not a release blocker, 2.16 is now in freeze mode.

-> 2.18
Depends on: 103778
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18
*** Bug 66007 has been marked as a duplicate of this bug. ***
No longer blocks: 66007
Depends on: 130276
The User Interface component now belongs to Gerv.  Reassigning all UNCONFIRMED
and NEW (but not ASSIGNED) bugs currently owned by Myk (the previous component
owner) to Gerv.
Assignee: myk → gerv
Reassigning back to Myk.  That stuff about Gerv taking over the User Interface
component turned out to be short-lived.  Please pardon our confusion, and I'm
very sorry about the spam.
Assignee: gerv → myk
Useful, but not critical, and it doesn't look like anyone is working on it, so
pushing it off to 2.20.
Priority: P3 → P4
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
No longer blocks: 69654
Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004.  Anything flagged
enhancement that hasn't already landed is being pushed out.  If this bug is
otherwise ready to land, we'll handle it on a case-by-case basis, please set the
blocking2.20 flag to '?' if you think it qualifies.
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
(In reply to comment #26)
> This is almost a dupe of bug 104247, which is already fixed, except this bug
> seems to do a more complete job of assigning classes to all of the severities
> instead of just blocker, critical, and enhancement, like 104247 did...

(In reply to comment #27)
> I hope you're not planning to enable this by default, or will at least
> provide a simple, reliable way to turn it off.

Seems to me that this would be a good candidate for a User Preference; site 
default might be the current colouration (Crit/Block/Enh only) but there could 
also be a different style sheet for this proposal (colours for everything) and 
one that has no colouration at all. The Admin can set the default (locking it 
down if he wants to); if it's unlocked, then individual users can decide on 
their own which style (out of the list of choices) suits them.

As such, adding a dependency to bug 98123.
Depends on: 98123
Not wanting to wait until proper "strategy" for color-marking the severity is
taken, I have done this quick edit. Has many limitations, uses hardcoded colors
and severities, but works for my standard Bugzilla 2.16 installation, it means
it marks critical bugs in orange and blockers in red. In list only.

I have inserted into /data/template/en/default/list/table.html.tmpl following
lines after following (line somewhere around 365), where table row definition starts

if (($stash->get(['bug', 0, 'groupset', 0]) && ! $stash->get('usebuggroups'))) {
    $output .=  'bz_secure';
    }


<----- inserted code -------->
    if ($stash->get(['bug', 0, 'severity', 0]) eq 'critical') {
    $output .=  "\" style=\"background-color: rgb(255, 204, 0);";		
		}
    if ($stash->get(['bug', 0, 'severity', 0]) eq 'blocker') {
    $output .=  "\" style=\"background-color: rgb(255, 102, 0);";		
		}

QA Contact: mattyt-bugzilla → default-qa
Target Milestone: Bugzilla 2.22 → ---
Assignee: myk → ui
Each entry in buglists have the bug severity as a class name (e.g. severity "normal" becomes class="bz_normal"), so everyone is free to edit e.g. their chrome/userContent.css CSS file and add their prefered style in it (if using Firefox. No idea about IE). As some users may prefer to color rows based on the bug status or priority, we are not going to implement a complicated system to manage all possible cases. Closing this bug as WFM.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
anyone have a sample userContent.css to send or attach to the bug?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: