View source for Bugzilla:Bug Layout Revision

mconnor's proposal (which includes changes to the header) is [http://steelgryphon.com/firefox2/bmo/Bugzilla_bug4.html here].

preview of the work in progress is [https://landfill.bugzilla.org/prodpatches/show_bug.cgi?id=415 here]; note that logging in changes the appearance quite a bit.

{| style="background: lightgray; border: 1px solid blue"
| '''NOTE:''' Changes that don't have working patches by early evening PST Saturday December 23rd will not be included in the upgrade on Tuesday the 26th.
|}<br>

== Comments ==
(please include your rationale!)

=== Jesse ===

I like the wording changes and "edit" links.  Those save space and make the page less cluttered.

I don't like the overall layout change.  The three-column layout currently used at the top of bugs saves space, allowing me to see the CC list and the first few attachments without scrolling.  Is there a good reason to switch to an entirely two-column layout?

=== beltzner ===
* Agree with Jesse, 3 columns allows for more information density on a page and will actually make it easier to visually scan each chunk/grouping
* When no search results are available, just hide that row since it adds no valuable information
* Compress the header as in mconnor's mockup, the repetition of the bug name and number is distracting and confusing
* The actions section takes up too much space and is too visually prominent. There doesn't need to be a "format for printing" button, we should just use a sensible print.css file. Clone bug and "XML" are seemingly low value, too. Instead I'd propose something like:
  Bug 415 - blah blah blah blah (edit)
  [view activity] [jump to latest comment]   (<-- small text)

=== Wolf ===
Agree with Jesse and Beltzner about the two vs three column layout stuff (and hiding the actions when searching.). Except for the header compression. I find the header appears better when not compressed. (and as far as I can see, there's no space actually being saved by those changes.) I think mirroring the actions line at the top and bottom is useful.

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.)

=== Ancestor ===
The dependency list tries to put as many entries in one line as it can. This becomes a problem when there are plenty of entries, because it pushes the right-hand column too far to the right. [https://landfill.bugzilla.org/prodpatches/show_bug.cgi?id=4728 see here for example].

=== LpSolit ===
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.

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).

Links about votes are really not important and should be moved in the "Action" list (with XML, etc...).

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.

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.

Ancestor, about the dependency lists: it indeed tries to use as much place as possible, but will wrap to avoid the user to scroll horizontally, so this is fine and exactly what we want. If your screen is narrower, it will wrap more often.

Nit: please remove the now useless colspan=3 in the right table as the dependency lists have been moved to the left.

=== Vlad ===

This is minor, but the attachments table is pretty ugly.  At the very least I'd like to see the double-weird-90's-style-3d-borders just become simple 1-pixel line borders.  I also think that this page overall does too much "Field name: Value", and places all field names on the same importance as all others, when in reality they're not.  This is very noticeable in the header, but also in the attachments table.  Here's my take on some ideas for the attachments table: [http://people.mozilla.com/~vladimir/misc/bugz.html here].  The first table just has borders and backgrounds changed, deemphasizing obsolete attachments.  The second is what I'd really like to see, because it makes the important information (basically, patch name, type, review flags) much more visible.

=== Dolske ===

* 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.