Bugzilla:Bug Layout Revision

Comments

(please include your rationale!)

gerv

Comments on the current version of the redesign (2007-01-02):

• Priority and Severity are a long way apart; in an ideal world, the two are used together to judge the importance of a bug. Therefore, they should be placed together. I suggest moving Severity down next to Priority.
  • As I understand it, the rationale for separating them is that priority is managed by the assignee (together with TM), while severity is not. It was therefore put in the "assignee" block. GavinSharp

• IMO, the alias in the new header should be enclosed in square rather than round brackets, and perhaps italicized to make it obvious it's not part of the summary text.

• The alias is before the summary in the header but after it in the editing boxes. We should make the two consistent.

• The edit link in the header box should not be bold.

• When we print names with spaces, e.g. "Dave Miller (work related)", we should use non-breaking spaces. This affects "Reported".

• Target Milestone can be shortened to Target. Milestone is both Mozilla-specific and obsolete.
  • Milestones are hardly Mozilla specific. That's a standard business term. Target Milestone exactly conveys what this blank should contain. Hacksaw

• Right-alignment of the field names would give a better two-column effect and direct the eye to the important information, because I think people look to the right of vertical lines (e.g. ruled margins).

• I don't know about anyone else, but on my 1024x768 screen, I have a lot of whitespace in the middle, and yet the right side (Reporter, Modified etc.) is cramped and wrapping.

• The tooltip on bug numbers truncates the summary too early. As this is a Gecko limitation, can we work with it by using abbreviations for states (e.g. RES DUPL rather than RESOLVED DUPLICATE)?

Comments on dolske's mockup2:

• The changes to eliminate the "knob" are non-skin changes; they should be removed in order to make it more obvious what changes he is suggesting that are actually doable in a skin revision.

• I like the drop-down styling, but it shouldn't apply to the flags - it makes it look as if the flag name can be changed.

• The Reported and Modified dates should either both have seconds, or neither.

• The field title color is too light. I see the desire to deemphasize, but this has gone too far. Even a small departure from black can have a noticeable effect.

• Target Milestone -> Target

• Merging Priority and Severity into "Importance" is wrong; if these fields are used correctly, they mean two different things, and need to be labeled as such. It's not obvious from "P1... P5" that it's a priority field.

Gerv 07:23, 2 January 2007 (PST)

gwagenknecht

• Over all, I like the redesign of the show bugs page.
• Having the bug status as the first field is great. But I would like it to be even more prominent (for example, try to leave the cell bellow it empty). (It might be subjective but it's one of my major complaints against JIRA. It's not easy enough to ready the bug status. Don't know why but maybe because the UI is too busy for me.)
• I like the ideas exposed by dolske in mockup2. Especially the right alignment of the field names make it easier to read and the colorization of the input fields makes them easier to recognize.
• Don't know if it would be interesting to have dates formatted as "x hours/days/weeks/months ago" for the modification date. (Could be a user setting though)

--Gwagenknecht 07:22, 2 January 2007 (PST)

gekacheka

1. Conflicting Criteria for design: use style independent of grouping?

• Group related fields by assessment task:
  • Assess status: Status, Keywords, Whiteboard, Depends on, Attachment Flags, Flags
  • Assess importance: Severity, Keywords. Priority. Blocking. Flags.
  • Assess urgency: Severity, Target, Flags, Blocking.
  • Assess interest: Votes, CC
  • Assess module: Product, Component, Summary, Description/Comment
  • Assess reproducibility: Description/Comment, Attachments, URL, Product, Version, OS, Hardware [hw rare?]

• Identify who may normally edit fields (e.g., avoid lay commenters editing priority, target)
  • Interested party: CC, Votes, comments.
  • Reporter/Triager/Confirmer: any except Priority, Target., Assignee, QA, Flags
  • Module owners, Assignee: any including Priority, Target, Assignee, QA, Flags

Ideas:

• separate assignee/QA fields into group or column associated with QA.
• identify group of reserved fields with border or shaded background. (like in paper forms)

2. Attachments table: consistent location of type

The type of the attachment should be in a consistent location so it is easy to scan for attachments of a particular type.

For example, sometimes I want to quickly find all the image attachments among all the other attachments (say for UI review). Currently attachment type is placed after the title, so its location varies wildly from row to row depending on the length of the title.

Example of problem:

Zip of files exhibiting issue (29.44KB

application/octet-stream)
2007-01-01 11:23 UTC Artie Boss
Toolkit patch (21.43KB patch)
2007-01-01 12:34 UTC Cody Smith
Add native Mac theme code, update windows code (67.57KB
patch)
2007-01-01 13:45 UTC Cody Smith
Possible approach on windows (2.38KB image/gif)
2007-01-01 23:45 UTC Artie Boss
Updated patch (21.44KB patch)
2007-01-01 23:56 UTC Cody Smith

Suggestion:
Place it on the second line. Right justify variable length contributor's name before fixed-length date

Zip of files exhibiting issue

(29.44KB application/octet-stream) Artie Boss 2007-01-01 11:24 UTC

Toolkit patch

(21.43KB patch) Archie Tek (vacationing until Sept) 2007-01-01 12:34 UTC

Add native Mac theme code, update windows code

(67.57KB patch) Cody Smith 2007-01-01 13:45 UTC

Possible approach on windows

(2.38KB image/gif) Artie Boss 2007-01-01 23:45 UTC

Updated patch

(21.44KB patch) Cody Smith 2007-01-01 23:56 UTC

3. "Product" link to product descriptions

Suggest "Product" link to page with product descriptions, such as https://bugzilla.mozilla.org/enter_bug.cgi?full=1 to explain obscure product names such as 'core', 'NPSR', etc.

Gekacheka 09:50, 13 January 2007 (PST)

Mockups

mconnor

This mockup was originally done prior to the redesign. Linked here for easy reference.

Dolske (mockup2)

I've created another mockup, based off the redesign, to try out some more/revised ideas...

• Visual noise from form controls is again reduced (as the previous mockup tried), but instead of using a zillion "(edit)" links the fields are directly editable. Thanks to Jesse for suggesting styling the controls.
• The field labels were becoming too visually prominent. Changed weight and color to not draw attention away from the bug data. I also undid mconnor's left-alignment, as that was also seemed to call attention to them (ie, it almost looked like a 4-columns instead of just 2).
• Stole the header from mozilla.com, just to try out something different. The footer also changed, but there's functionality missing.
• Removed the clump of radio-button actions that were underneath the comment box. Instead, these modifications should be done direction upon the fields themselves. Need to do some more work to make sure those operations are still easy to do, but hey it's just a mockup. :-)
• Table widths are dynamic now, try changing the width of the window.
• Not shown: fields that are modified should change their background color to a light-red to indicate the modification.

--Jmdesp 07:15, 29 January 2007 (PST)
I like your mock-up, but is there a way to make it degrace more gracefully under IE6 ? The form controls changes don't seem to work under it. Also I think it's better not to remove the edit link after it's pressed

Summary of discussion prior to 26-Dec-2006 upgrade

(Note: this page was getting huge, and trying to rearrange and reclassify all the comments would have been a huge time sink. Instead, I've tried to fairly summarize things in a way useful for future discussions.) See the last verbose version for the complete comment list.)

The redesign was largely based on a proposal mockup from mconnor. Changes were prototyped here.

Issues not resolved by redesign

1. When no search results are available, just hide that row since it adds no valuable information
2. "Format for Printing" should be removed, replaced by appropriate media-specific CSS
   1. However, note that content of the current printing-formated page differs.
3. Combine some fields to a single line. For example, Hardware + OS -> Platform
4. Make "URL" an attachment (this is a new BZ feature)
5. In the change section at bottom, remove the word "bug" and associated prepositions from "accept bug", "resolve bug ...", etc - it's implied
6. Search and search navigation in multiple places seems odd. Try combing to a single line.
7. Assignee needs an "(edit)" link
8. Only show time estimate to logged in users.
9. Some of the field names are links, others are not.
10. Attachments should link to the comment describing them.
11. The big radio list at the bottom of the page (right above the "Commit" button) really needs to be simplified, or even eliminated. Most of these actions could be some from the controls at the top of the page, with better design.
12. The "Depends On" and "Blocks" fields should be clipped if they're really long (with a mechanism to show them all if desired). "Depends on: 99 bugs (2 open, 97 resolved)" seems more useful than a giant block of numbers.
13. Bugzilla should lend a hand when you're filling out a field with a name (assigned to, qa contact, flags). "Default" is probably needed as a minimum, although a longer list of people appropriate for the task would be nice.
14. The yellow header bar linking to mozilla.org seems completely useless. Maybe make it a footer, or just delete it entirely?

Problems/Objections with the redesign

1. Various comments about how the fields should be properly arranged. Everyone had their own rationale, so summarizing the ideas here isn't useful. :-)
2. 3-column layout better than 2-column (saves space, higher information density, easier to scan each chunk/grouping)
   1. However, may look worse if your browser isn't wide.
   2. Have a single "People involved with bug" block
3. Old header looked better (redesign doesn't save space, consistency with other Bugzilla pages)
4. "Preferences" changed to "Settings"
5. The "magically expanding comment box" is annoying.
6. Each comment should have more left-padding to move it under the header
7. Action block (at bottom of page) now disconnected from the fields it operates on (at top of page)
8. Some colored regions have curved borders, others do not.
9. Too much whitespace between field and label.
10. Is "View All" link on attachments really useful?
11. Double clicking on my mail address at the bottom of the page and pasting it into a text field prepends it with "# "

Other mockups

Jesse

I've made a proposal that uses a "3 columns at the top, 2 columns in the middle" layout (similar to current BMO layout) but based on the page with improved grouping and "(edit)" links. It saves a significant amount of vertical space, gives more room to the URL and whiteboard fields, and IMO looks pretty good. See this page for a list of changes I made.

Reply from Silver:

• Less information is available "above the fold" here (it's lost the last modified time and votes).
• In addition to other comments against it, it actually gives me less space for the keyword/whiteboard/URL fields!

Dolske (mockup1)

I had a few more ideas on streamlining things, and did a rough mockup to see how well they work. It needs fine-tuning, ignore any fixable rough edges.

• The outlines and icons of form controls add a *lot* of visual complexity to the page. The mockup replaces almost all the HTML controls with just plain text (but you can reactivate the controls by clicking "edit"). This really improves readability, but the obvious cost is having to click "edit" to update fields is annoying. This needs improved.
• The top part of the bug is using CSS3(ish) columns, so you will see 2 or 3 columns depending on how wide the browser is. Or, uhh, 1 column for narrow windows. And browsers that don't support -moz-column-width. There's not much control over where a column starts, so tweaking a design to work with different column counts is tricky (the mockup just happens to look fairly reasonable). Perhaps there are JS/DOM tricks that could help? I consider this a failed experiment as-is.
• The CC list is hidden again (ala mconnor's mockup).
• Combined some fields