Description of problem: With upgrade to Bugzilla 3, show_bug.cgi page layout changes significantly, pushing lot of less important fields to the top of the page, resulting in useful information being shifted lower. This change bring the page layout closer to what's currently used by upstream, though it can also be viewed as noticeable usability regression. Question we should ask is if bugzilla users come to bugzilla to read bug description / comments, or to get meta-information (various whiteboards, qa contacts, (internal) flags, IT references, time requirement estimates, group membership, ...). If the latter is the case, new layout is ok. If the former is the case, having to scroll down *every* bug just to view initial description seems quite bad from the usability point of view and all those "not so interesting" fields should be pushed back to the bottom of the page.
I do understand that this may be "too big" to be RH extension, not sure if upstream is planning / willing to have such change. Hence low-priority RFE.
Yes unfortunately since we are trying to track closer to upstream, this is where they have the "custom" fields display now. Before in 2.18 Red Hat moved them further down as they were not accessed as much. We could in the future move the "custom" fields below the comments if you think that would be better. It is basically just moving blocks around in a single template so not too difficult. It will just not be like upstream anymore.
I agree with Tomas. It's handy to have comment #0 before the fold to save having to page down. (I was thinking of fixing this with a greasemonkey script to move all the fields around actually)
For the sake of adding a voice to the crowd, I agree. This is a lot of real estate to be wasting on blank boxes.
User interface design has never been a particular strength of upstream bugzilla IMHO:-) I'd be strongly in favour of moving the fields back into a more logical order. (When I saw this change on partner-bugzilla before I went away, I assumed it was just because you hadn't had time to finish re-customising the templates!) The 3-line message box about cookies is also using up too much vital screen space.
Uff, that new bug layout is definitely terrible and useless. I vote for the old one.
With the new layout all the meta-info (flags et.al.) is conveniently together on top of the page; latest comment is then available simply after pressing the "end" key. Fine by me. Usability regressions that I see are that "flags" don't seem to be as clear as they used to be, and more importantly that the "additional comment" field is above comments, so I won't see the last comment that I'm likely replying to.
(In reply to comment #5) > The 3-line message box about cookies is also using up too much vital screen > space. Well hopefully that message can go away in few days ;)
*** Bug 457788 has been marked as a duplicate of this bug. ***
what about these UI's? something to consider: http://bugzilla.gnome.org/show_bug.cgi?id=353241 http://bugs.kde.org/show_bug.cgi?id=41514
I'm using the stock Firefox 3.0.1 in Fedora 9. The new look is fine overall. I don't mind getting used to how some things have moved around from the old one. But some things that are a bothersome, inferior UI experience to the old bugzilla: The text boxes on the right side in the main top portion (Fixed in Version: down to Release Notes:) are too wide. My browser window is pretty wide. But even so, these text boxes extend off the right side of the window, crossing over the border outline on the page. Used to be that, when logged in, I'd always see someone's email address next to their name. This matters in all the places names appear (Reporter, Assigned, CC, comments). I want to automatically see those email addresses. Boot to the head if you tell me to hover over them to see the mailto: links. The top navigation line (grey with "Home" et al) is way too wide. To have it all be one line, by browser window has to be unreasonably wide. No other site I use has a navigation line that looks so bad at a more normal window size. With a comfortable window width, the "Log out roland" button pushes onto a second line. There is too much dead space up there already. Maybe the fonts/spacing just need to be smaller. The "Restrict Group Visibility" section is the least useful thing on the page and does not belong at the top. It used to be way at the bottom, which was fine. Now it always takes two page-downs to get to the actual content of the bug. That whole section should be someplace unobtrusive, not between the most-used sections of the page. The New bug form page just looks terrible. The spacing is totally screwy, many fields are off the right side of the page, over the border.
+1 for moving the meta-info to the bottom. Description field is almost always the very first place I look at. Now every time I come to a bug there is need to scroll to skip those not-frequently-used fields. Also the add-new-comment box should be IMO just under the latest comment. This fits best to the most common way how commenting is done: [read the description]->[read the comments]->read the latest comment->add my comment (while looking from time to time just above to what's written in the latest comment to reply accordingly).
(In reply to comment #12) > Also the add-new-comment box should be IMO just under the latest comment. This > fits best to the most common way how commenting is done: > > [read the description]->[read the comments]->read the latest comment->add my > comment (while looking from time to time just above to what's written in the > latest comment to reply accordingly). I'd say "Additional Comments" input field position should depend on setting of "When viewing a bug, show comments in this order" preference. Fixed position, either below or above, will be the wrong position wrt to one of the values of this preference. As "Oldest to Newest" is site default, below seems to be reasonable default.
*** Bug 458271 has been marked as a duplicate of this bug. ***
*** Bug 458339 has been marked as a duplicate of this bug. ***
(In reply to comment #13) > I'd say "Additional Comments" input field position should depend on setting of > "When viewing a bug, show comments in this order" preference. Yes please. (!) Another issue: The headers table may perhaps benefit from some visual delimiters.
(In reply to comment #16) > > I'd say "Additional Comments" input field position should depend on > > setting of "When viewing a bug, show comments in this order" preference. > > Yes please. (!) If this is too difficult to implement, move the input field _below_ the comments.
Any chance of moving this pesky Additional Comments box? It's really quite anoying to workflow, IMHO.
Created attachment 314044 [details] Simple patch to move additional comment textarea below current comments (v1) Patch that moves the additional comment field below the current comments. Please review. Dave
Comment on attachment 314044 [details] Simple patch to move additional comment textarea below current comments (v1) Looks good to me Dave. Thanks, Noura
I'm not sure how to easily test the fix from comment #19. I will note that as another pie-in-the-sky request that it would be great to have the flags at the end of the page as well. :) (My workflow processing fedora cvs requests has me add a comment that the cvs is done and set the fedora-cvs flag to +, and currently this takes moving back and forth to the top and bottom of the page.)
I'm pretty sure the simplest solution is to hide the edit form and display a simple table, and make the edit form showable by clicking a link that remembers your preference in a cookie. Somewhat like this: https://bugzilla.mozilla.org/attachment.cgi?id=257767 (Ignore the edit form, that's a very old UI.)
Thanks for moving the comment box down.
*** Bug 477112 has been marked as a duplicate of this bug. ***
Increasing priority and severity since there seems to be a lot of consensus that changes are needed. (I was tempted to set priority to High but in the end refrained from doing so.)
Red Hat Bugzilla is now using version 34 of the Bugzilla codebase and therefore this feature request will need to be implemented against the new release. Updating bug version to 3.2.
"Additional Comments" position issue is fixed (and was in 3.2 too, reading the comments), including its binding to comment order setting. Original issue - lots of unneeded fields shown on top of the page - still exists with no apparent change from 3.2.
Red Hat has now upgraded to Bugzilla 3.6 and this bug will now be reassigned to that version. It would be helpful to the Bugzilla Development Team if this bug is verified to still be an issue with the latest version. If it is no longer an issue, then feel free to close, otherwise please comment that it is still a problem and we will try to address the issue as soon as we can. Thanks Bugzilla Development Team
As part of the recent Bugzilla 2.4 upgrade the Bugzilla team are cleaning up bugs opened against old versions of Bugzilla. This bug has been flagged as an old bug and will be CLOSED WONTFIX in 7 days time. If you believe this bug is an issue in the latest Bugzilla version please comment on this bug within 7 days. Doing so will ensure this bug is not closed automatically. Thanks, the Bugzilla team.
(In reply to comment #27) > Original issue - lots of unneeded fields shown on top of the page - still > exists with no apparent change from 3.2. s/3.2/4.2/ Though I guess this is becoming fairly irrelevant now that we've all forgotten the days when you did not have to scroll down 1+ screen to see comment #0.
*** Bug 624504 has been marked as a duplicate of this bug. ***
(In reply to comment #30) > (In reply to comment #27) > > Original issue - lots of unneeded fields shown on top of the page - still > > exists with no apparent change from 3.2. > > s/3.2/4.2/ This won't change for the reason noted in comment 2. > Though I guess this is becoming fairly irrelevant now that we've all > forgotten the days when you did not have to scroll down 1+ screen to see > comment #0. In the top right corner, we have a link to 'Last comment' (this is a Red Hat customisation). Do you propose we add a 'Description' link as well. Would that fix the problem? -- simon
I'm not really sure how much can such Description link help. It may aid a bit, but does not really resolve the main issue. For me, it's probably not that much better than scrolling down to be worth the effort to maintain and forward-port one another patch that will not be upstream. Other folks CCed here may have a different preference though, especially those who use Newest to Oldest comment order.
I've received no further comment (other than from Tomas) in the past three months. Marking as CLOSED/WONTFIX. Upstream focus for 4.6/5.0 is going to be on UI side of things, so hopefully we'll see some improvements then.