27
edits
Changes
m
The goal of including the bug summary in the header of the page is to save some vertical space. Repeating it again in the gray line is a regression. But I can understand you want it here for visibility. Now, links to go to the prev/next/first/last bug are taking too much space and should probably be moved on the same line as other "Action" links, i.e. XML, Format for printing, Last Comment.
Links about votes are really not important and should be moved in the "Action" list (with XML, etc...).
I'd move Assignee and QA Contact to just above the CC list, as they all fall under the same conceptual category as "People involved with this bug." Then I'd put Priority, Severity, and Target Milestone in with Status/Resolution, Keywords, and Whiteboard, as they fall under the category of "What state is this bug in". The remaining group of Product, Component, Version, Hardware, and OS, describes this category of "Where this bug occurs."
Ideally, URL should just be considered a type of attachment and not a whole separate field (though this would require converting all the existing URL fields for existing bugs into new attachments, and perhaps patching Bugzilla).
When you have a large amount of dependencies/blocking bugs, you can end up with one column being significantly longer that the other, as in [https://bugzilla-test.mozilla.org/show_bug.cgi?id=300030 the reflow refactoring bug]. (Maybe this won't be an issue since b.m.o has lots of flags too). Perhaps you could allow the dependency/block lists to span both columns? This can be done by moving them to a second TR (with colspan=3) within the outer TABLE.
(sorting before / after bmo upgrade)
=== LpSolit ===
Now I strongly disagree to have the keywords, URL and status whiteboard fields at the very top. This looks wrong to me. More important is the block with the assignee + target milestone + severity, and should be moved higher in the page. The status and resolution should be combined with this block.
Links about votes are really not important and should be moved in the "Action" list (with XML, etc...).
=== Dolske ===
* Status and Resolution have already been combined in the new version (now "Status: RESOLVED INVALID"). It might be worthwhile to combine a few other fields (ie, put them in the same row). For example, Hardware + OS -> Platform (System?). And perhaps Priority + Severity -> ???.
=== Napolj2 ===
I'd move Assignee and QA Contact to just above the CC list, as they all fall under the same conceptual category as "People involved with this bug." Then I'd put Priority, Severity, and Target Milestone in with Status/Resolution, Keywords, and Whiteboard, as they fall under the category of "What state is this bug in". The remaining group of Product, Component, Version, Hardware, and OS, describes this category of "Where this bug occurs."
Ideally, URL should just be considered a type of attachment and not a whole separate field (though this would require converting all the existing URL fields for existing bugs into new attachments, and perhaps patching Bugzilla).
When you have a large amount of dependencies/blocking bugs, you can end up with one column being significantly longer that the other, as in [https://bugzilla-test.mozilla.org/show_bug.cgi?id=300030 the reflow refactoring bug]. (Maybe this won't be an issue since b.m.o has lots of flags too). Perhaps you could allow the dependency/block lists to span both columns? This can be done by moving them to a second TR (with colspan=3) within the outer TABLE.
''I know that but I feel it would be better to wrap the dependency list earlier so that the columns aren't so far apart from each other with a huge white space between them. - Ancestor''
The goal of including the bug summary in the header of the page is to save some vertical space. Repeating it again in the gray line is a regression. But I can understand you want it here for visibility. Now, links to go to the prev/next/first/last bug are taking too much space and should probably be moved on the same line as other "Action" links, i.e. XML, Format for printing, Last Comment.
Removing the "Bug 415" (page title) portion might work on showbug, but on other pages, I don't think it does, since it provides useful information, which is only shown there. Plus the readdition of that value would likely end up being too wide with all the links on the same line. (See the activity log, etc). Also, why is preferences being changed to settings? Preferences seems to be more correct.
I'm not sure print view is served well by being just print.css fixed (as the page says, its a full text bug list, not really just a css change. Agree about XML, not sure what the purpose for it is, not that it bothers me being there, either. Clone Bug might be of value, though, since it didn't work in bmo before. (Just having two links to me, suggests either over pruning, or that that line should be elsewhere.)
=== LpSolit ===
Having the dependency lists on the left and having the CC list always visible is definitely the right approach (especially when you have a very long list of flags).
Note on bug 415 that I reassigned the bug to timeless, who has no real name on b.m.o, and now the assignee field is left blank. If the user has no realname, then his email address should be displayed.
* Putting page specific info (the bug title) into the top header seems like a unusual design, so the location would seem unexpected. Most sites have a relatively static header that one learns to ignore.
=== Napolj2 ===
I'd widen the attachments table to match whatever width the comments are line-wrapped at (or the width of the comment headers), for visual consistency.
