Open Bug 607829 Opened 14 years ago Updated 4 years ago

Make HTML bugmail easier to read and scan

Categories

(Bugzilla :: Email Notifications, enhancement)

enhancement
Not set
normal

Tracking

()

People

(Reporter: faaborg, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(2 files, 3 obsolete files)

Attached image Mockup of HTML bugmail, i1 (obsolete) —
The overall purpose of this bug is improve the usability of HTML bugmail.  A few different aspects come into play:

-Readability: making sure to use a fixed width font for comments that may contain code, making sure things flow in a left to right order and visually group correctly.

-Scanability: making it possible to process the general message in a single glance without having to do any linear reading

-Data over meta data: listing bug summaries before numbers, people's actual names before their email addresses, etc.

-Hyperlinking: making sure that everything that should be a hyperlink to more information is (and making the link the data itself, and never a raw URL)

Overall the design consists of a series of colorful blocks that flow left to right to describe the actions that someone has taken on the bug.
Severity: normal → enhancement
Version: unspecified → 4.1
(In reply to comment #0)
> -Data over meta data: listing bug summaries before numbers

This change will separate effect bugmail sorted by subject, separating emails for the same bug if the summary is edited.

[Bug 607829] Make HTML bugmail easier to read and scan
[Bug 607829] Improve HTML bugmail readability 
[Bug 975321] Kill stackwalk_server

becomes

Improve HTML bugmail readability (607829)
Kill stackwalk_server (975321)
Make HTML bugmail easier to read and scan (607829)

It also kills any semblance of date order for mail sorted by subject.
Attached image WIP screenshot (obsolete) —
I played around with this a bit tonight. Here's how it looks so far. I was thinking of putting the comment link to the right in a real light gray. I used the css technique from http://www.dinnermint.org/blog/css/creating-triangles-in-css/ to make the arrow
>This change will separate effect bugmail sorted by subject, separating emails
>for the same bug if the summary is edited.

yeah, we should keep the actual subject in the same format, I meant to indicate that I was just referring to the content of the email itself.  In addition to sorting we don't want to break message clients that are threading with the existing messages.
>Created attachment 486547 [details]
>WIP screenshot

awesome, I didn't even have time to cc you to this bug yet :)
The current mockup is just based on my personal usage of bugzilla over the years and what seemed to be the cleanest way to present the information. I'm going to send out a rypple message to the firefox team to see what feedback they have about bugmail that might influence the design as well.
i <3 all of these designs and the discussion! Thanks for giving this the attention it deserves. Hopefully we'll get this design onto the head as soon as everyone is happy with it.

I like the idea of using color to help enhance the readability.
Attached image WIP screenshot, v2
Just got back from the bars and decided to work on this a bit, attaching latest WIP. This is basically a raw dump of the activity table into the new format. I'll work on making it more readable tomorrow if I have time.
Attachment #486547 - Attachment is obsolete: true
A couple of notes from playing with it so far...

1. For the flags and such, is it important to show what the old values were? Your mockups only show what the value was just set to but current emails display both
2. With tons of changes the arrow doesn't appear to be pointing at the person's name anymore
3. There was no spot for the date and comment number. I have floated it to the right in a lighter color (the comment # is still a hyperlink though)
4. There was no spot for why you were getting the message. I put it at the end in the same light color
5. The bug summary & id sort of gets lost when there is more than one change. Shall we make it bigger or keep it the same size as the other text?
6. Should we add some gradients to make it less flat?
7. Should the purple / predicate bubbles all be the same size? I have a min-width but they look weird when one is super long. It also makes reading harder as the columns aren't lined up.
(In reply to comment #8)
> 1. For the flags and such, is it important to show what the old values were?
> Your mockups only show what the value was just set to but current emails
> display both

Personally, both the old and new values are important, for *all* fields. I don't waste my time going into each bug from the web browser. I watch the default QA contact of the Bugzilla product and scan changes from Thunderbird, and if something seems wrong to me, I visit the bug from Firefox. If you remove the old values, I will have no complete picture of what's going on in bugs. For instance:

 blocking2.0- -> blocking2.0?

is not the same as:

 --- -> blocking2.0?

in my mind, and the first one would make me more quickly retriage the bug than the 2nd one (that's just an example).
>1. For the flags and such, is it important to show what the old values were?
>Your mockups only show what the value was just set to but current emails
>display both

For fields like keywords or dependencies, we could try adding "removed x" as an action (perhaps styled differently than the adding actions)

For fields like flags that change from one specific value to another, we could add a forth column: [person][set attribute][from value][to value] (but then only use this if it changed from an existing value)

>2. With tons of changes the arrow doesn't appear to be pointing at the person's
>name anymore

yeah, can't really think of a way to fix that and still seems ok to me (usually there aren't that many actions).

>3. There was no spot for the date and comment number. I have floated it to the
>right in a lighter color (the comment # is still a hyperlink though)

Date is usually exposed by the email client, which is why I left it out.  Works ok over on the side like you have it though.  Is the comment # important for any reason?

>4. There was no spot for why you were getting the message. I put it at the end
>in the same light color

yeah, I was giving this some thought on my drive home.  I was thinking that if you are receiving the mail for an obvious reason (cc'd, reported the bug, assigned to the bug) we could probably say nothing, and if you received the mail because you are following someone, we would want to lead with that information right at the very start of the message.

>5. The bug summary & id sort of gets lost when there is more than one change.
>Shall we make it bigger or keep it the same size as the other text?

We could try making it larger, since it is redundant with the subject like of the email I'm not sure how many people are going to rely on the in content summary. (they might have already read the summary before clicking, etc.)

>6. Should we add some gradients to make it less flat?

perhaps, but I'm going to draw the line at css transitions :) (ironically I'm actually playing with css transitions right now for another bugzilla related project)

>7. Should the purple / predicate bubbles all be the same size? I have a
>min-width but they look weird when one is super long. It also makes reading
>harder as the columns aren't lined up.

there might be value in them being different sizes, since we'll over time start to know what the value is likely to be based on the size (which is information we receive slightly before actually reading the text).
Comment on attachment 486570 [details]
WIP screenshot, v2

For fields like priority, severity, bug status, resolution, etc..., I don't think we want two separate lines, because it's harder to scan at a glance, and they really are a single action. Why not:

foo@bar.com (changed priority) P2 => P1
            (changed flags)    anotherflag? => anotherflag+
            etc...
(In reply to comment #10)
> Is the comment # important for any reason?

It is for two reasons:

- You can convert it into a link pointing to this comment directly in the bug (no need to first go to the bug, then scroll till you find the comment). This is useful when you want a) to reply to the comment, and b) continue reading from the web browser rather than your email client.
- The number of comments is also an indication of the activity of the bug, and let me quickly reference to it on IRC instead of having to visit the bug to know which comment ID we are talking about. ("Hey, did you see comment 23 faaborg just wrote in bug NNN? Do you agree with him?")


> yeah, I was giving this some thought on my drive home.  I was thinking that if
> you are receiving the mail for an obvious reason (cc'd, reported the bug,
> assigned to the bug) we could probably say nothing

Wow, no, no way! I'm much more reactive when I see "You are the assignee of the bug", than when I read "You are on the CC list of the bug". I don't remember all bugs assigned to me by heart. The goal of the bugmail is to be as accurate as possible to avoid useless visits to the bug from your web browser.
(In reply to comment #11)
> Comment on attachment 486570 [details]
> WIP screenshot, v2

Perhaps some of the foreground/background color combinations may benefit from a bit more contrast? When fared against the W3C accessibility guidelines for color contrast, some of the color combinations were a bit low in contrast. 
(http://snook.ca/technical/colour_contrast/colour.html )

It turns out that the dark-green/light-green combination was okay, though the gray/light-gray, purple/light-purple, brownish-yellow/light-yellow, and red/pink combinations fell a bit below what they recommend for contrast. 

In all, I definitely appreciate your efforts here and I'm glad this bug is getting some well-deserved attention :).
(In reply to comment #10)
> I was thinking that if you are receiving the mail for an obvious reason
> (cc'd, reported the bug, assigned to the bug) we could probably say nothing

I, and I suspect many others, use email filters to sort bugmail based on the reason text provided in the current bugmail format.
>I'm much more reactive when I see "You are the assignee of the
>bug", than when I read "You are on the CC list of the bug"

yeah, thinking about it more it seems like we should surface that you are assigned the bug first.  We certainly don't want people forgetting what bugs are assigned to them, and this is rather important information.

>I, and I suspect many others, use email filters to sort bugmail based on the
>reason text provided in the current bugmail format.

random idea, what if we placed text at the bottom of the message that was the same color as the background so that it could be easily filtered on (wouldn't need to be in a human readable format), but also wouldn't increase the visual complexity of the message and look like legal fine print.
(In reply to comment #15)
> >I, and I suspect many others, use email filters to sort bugmail based on the
> >reason text provided in the current bugmail format.
> 
> random idea, what if we placed text at the bottom of the message that was the
> same color as the background so that it could be easily filtered on (wouldn't
> need to be in a human readable format), but also wouldn't increase the visual
> complexity of the message and look like legal fine print.

How about making it transparent by default and then opaque on hover using :hover?
(In reply to comment #16)
> (In reply to comment #15)
> 
> How about making it transparent by default and then opaque on hover using
> :hover?

I just tried this, it's annoying having the text pop in and out while moving the mouse around. I'm going to try with css transitions to see if they make it feel better.
>How about making it transparent by default and then opaque on hover using
>:hover?

only downside would be that these would randomly display when you moused through them heading to a target on the other side.  Perhaps a slight delay using a css transition?
The delay and opacity fade feels good. Of course, if we go this way anyone using browsers/email clients that don't support css transitions get the jarring behavior...
>if we go this way anyone
>using browsers/email clients that don't support css transitions get the jarring
>behavior...

Onward to the future!
faaborg: Your mockups look excellent, fantastic, wonderful, and lots of other positive adjectives. There are a few issues:

* Using natural language may not work well for custom fields, and it also requires quite a bit of specific coding for every single field that may not exactly work if people repurpose or rename fields. The "rename or repurpose" is not so bad, though, because theoretically all of this will be in a template where people can modify it. However, for simplicity's sake, it may be better to come up with a scheme that always works for each *type* of field, where you can just drop the word in. At least, that can be the default that we use for custom fields.

* The most popular email client, is, I believe, Outlook. Outlook does not have any form of reasonable CSS support--it uses Word as its HTML renderer. You can do colors and font modifications, but anything else is likely to fail. The state of standards support in other email clients (besides Thunderbird) is questionable. For example, some of them may be using gtkhtml2.
As far as the signature, why don't we just render it like Thunderbird and make it gray but still readable? Usually I'm not distracted by the existing signature, visually.

I think CSS transitions may be overkill, and are probably only going to work in Thunderbird and webmail.
About the comment numbers, I agree that the comment number itself may not be very important, but we may be able to kill two birds with one stone if we make it into a link to the comment with the author's name in there somehow (although it would be nice to find some way to do that without modifying the visual design).

The date on the comment is unnecessary--we removed it on trunk because the email's date is the comment's date.
>* Using natural language may not work well for custom fields, and it also
>requires quite a bit of specific coding for every single field that may not
>exactly work if people repurpose or rename fields.

we could just fall back to "set [custom field name]" in the event that we have no idea what the field is.  Visually the blocks will help a bit if the sentence structure totally ends up breaking.

>* The most popular email client, is, I believe, Outlook. Outlook does not have
>any form of reasonable CSS support--it uses Word as its HTML renderer.

While I'm hesitant to invoke the "let's make it a pref" line of logic, would it make sense for us to have two different types of HTML email.  One that renders even with Word, and one that is up to speed with the very latest in Web standards?
(In reply to comment #24)
> we could just fall back to "set [custom field name]" in the event that we have
> no idea what the field is.

  Okay, that sounds fine.

> While I'm hesitant to invoke the "let's make it a pref" line of logic, would it
> make sense for us to have two different types of HTML email.  One that renders
> even with Word, and one that is up to speed with the very latest in Web
> standards?

  No, I think the best solution there would be just to have reasonable fallbacks in the HTML and CSS for the bad renderers.

  Note particularly, though, that you more or less cannot reliably make any email client other than Thunderbird use Standards Mode. I'm not sure it will even work in webmail clients, but there are a lot of unknowns about how HTML will render in those situations, in any case.
Just found this: http://www.campaignmonitor.com/css/. We can use it to navigate what we can/can't do and what the trade-offs are.
If you don't mind my butting in to your discussion, I'll second Max in comment 25.  Long experience with html email shows that the rendering in Outlook 2007 and 2010 is very, very troublesome if your markup is html and css.  *But* the bad behavior is most notable behind the techniques *graphic* designers would want -- clever background images (images and textures like gradients) and large areas with different color treatments where precise control of padding and margin matter in nested containers is *really* nasty.  Using padding to show underlying color is also no fun.  Controlling spacing of adjacent rectangles is possible but temperamental.  Positioning is out.  I doubt you could depend on width.  MSDN documents support for style hints on various html elements, but I'm afraid it matters more what *context* an element's in.

All that said, Alex's sketch shows elements that seem to me tractable -- and as Max says, you could render them using graceful degradation any web person knows and loves.  The predicate box might be a fixed-width container with a purple background and border with radius.  Word will ignore the radius.  But then gmail will strip background imagery too.  It may be that a table cell will tolerate a background image, so that might be how you get rounded corners.

I think if you can keep the flow *vertical*, you'll have reasonable success no matter the email client.
(In reply to comment #27)
> The predicate box might be a fixed-width container with a purple
> background and border with radius.  Word will ignore the radius.  But then
> gmail will strip background imagery too.  It may be that a table cell will
> tolerate a background image, so that might be how you get rounded corners.

A couple of things:

* fixed-width won't really work with custom fields...
* It's currently implemented as divs with solid backgrounds with css border-radius...that should degrade gracefully.
* It currently has floated elements, which won't. As much as it pains me with my web developer hat on, the best would probably use tables for layout
* The CSS technique to make the arrows likely won't work for older clients. I refuse to use an image for it and would like to see how the current CSS looks on these craptastic renderers (there's a workaround for the ie6 engine).

> 
> I think if you can keep the flow *vertical*, you'll have reasonable success no
> matter the email client.

* I noticed this as well when viewing the current WIP emails on an iPhone...there was not enough horizontal space so items overlapped. Perhaps the table layout will fix this as well, perhaps not. I'm also looking into doing different CSS for mobile devices via media queries. Of course, it wouldn't help the older client but it would make the experience on modern phones more pleasant.

Vertical goes against Alex's left-to-right scanning though
Sure, table cells have the advantage that they won't overlap and may induce a horizontal scroller.  Maybe that would be ok here.

re vertical: sorry I wasn't clear.  I did not mean to suggest rotating any of predicate or object to the vertical (below rather than to the right).

But now that I think about it, if the subject is constant in an email, maybe in the narrow context (using a media query) you disable display of the left subject column and *enable* display of a subject over the predicate "column," as you might in a tabular presentation.  So then you've got two rather than three columns.  And maybe there's another way to signify add/remove/change besides spelling out the word in the predicate "column."  I think Alex hints at this in comment 10.

Myself, I long ago shifted from a <style> section to putting the rules in style="" on every html element.  It may be google and yahoo etc will make mincemeat of anything like a media query.
Attached image Mockup of HTML bugmail, i2 (obsolete) —
This second iteration adds a few requests:

-Showing fields that have changed from one specific value to another specific value
-Very clearly indicating which bugs are assigned to you, or require your review
-Example of the message generated when someone files a brand new bug
Attachment #486513 - Attachment is obsolete: true
David: I couldn't find Byron's bugzilla email address.  Could you cc him as well?
Quick tweak: added an example of watching another user
(In reply to comment #32)
> Created attachment 515285 [details]
> Mockup of HTML bugmail, i3

  As usual, this is beautiful, brilliant, and amazing. :-)

  There are a few questions and comments that spring to mind immediately:

  * The white on gray for the assigned_to emails is a little hard to read, and with the importance of assigned_to emails, I think they should be as easy to read as possible.

  * When a user requests review from you, the email should still explicitly state that review is targeted to you--otherwise we are expecting users to have knowledge about Bugzilla ("review emails directed to me are in gray") that they may not have, and also otherwise there's no way to distinguish "review from the wind on a bug I'm assigned to" from "review directed to me on a bug I'm assigned to".
Attachment #515282 - Attachment is obsolete: true
(In reply to comment #33)
>   * The white on gray for the assigned_to emails is a little hard to read, and
> with the importance of assigned_to emails, I think they should be as easy to
> read as possible.

  But to be clear, I think that making them clearly visually different was a brilliant idea.
>  * The white on gray for the assigned_to emails is a little hard to read, and
>with the importance of assigned_to emails, I think they should be as easy to
>read as possible.

Yeah, I was considering using white on black, but that seemed a bit harsh.  When the user hits one of these after reading a few hundred pieces of bugmail, we don't want them to be injured :p  We can tweak the level of grey to improve the contrast though.  The font anti-aliasing is a bit messed up in the mockup as well, so that is also effecting readability, which won't be a problem in the actual implementation.
(In reply to comment #35)

  Ahh, okay. Sounds good. :-)
Blocks: 665419
Alex, would it be possible to get a hold of the raw HTML you used to generate your mockups? I would like to try my hand at creating some usable templates for Bugzilla that can make the current HTML emails look better than they do. I will have better chance of getting them upstream this way and worst case, we can use them as a custom template for BMO.

Thanks
dkl
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: