Okay, I've been thinking about show_bug.cgi for a long time, as long as I've been using Bugzilla. I personally use Bugzilla extensively, both here and on many other sites. I've customized many Bugzillas for many clients, and seen the workflow of many different types of users and businesses. Recently I've personally found show_bug.cgi fairly frustrating, both the bugzilla.mozilla.org version and the upstream version. It's just not a *fast* enough UI for editing bugs quickly. If I want to spend a lot of time on a particular bug, then I'll spend that time, that's fine. The attachment is a mock-up of a new show_bug that hides most of the UI elements from the normal user, and only presents them when you ask it to. The table at the top contains the fields that would be useful to every Bugzilla installation everywhere, or at least the majority of them. It can reside in its own template, simeple-bug-table.html.tmpl, so that installations can easily customize it to add other fields that they want to see there. This is just the beginning of several show_bug.cgi updates that we could do. Yes, it clutters up the editing interface by adding fieldsets for Status and Group. We can decide what to do about that in a separate bug, something like "Clean up the Editing Interface." Also, it doesn't currently save the state that you last had all of the shown/hidden items. That is, when you reload a page, if you had the "edit fields" shown, they should stay shown. They should also stay shown on the next bug that you load. But that's also something we can do in another bug. One thing that I *wish* I could do is float the comment box off to the right, so that the description shows up even nearer to the top of the page. But it's too wide, and the comments overlap into the box (because of how browsers render the <pre> tag, the Description text appears on top of the comment box).

I really like a lot of this. If header.html.tmpl included an automatically collapsed menu, then users who want to navigate from the top can by clicking on a Menu link that will expand to the same useful-links area at the bottom. That would be awesome! :-) The same could be done with the comments - allow users to collapse all just like they can with diffs. This helps them focus on what they're reading - one comment at a time. Users without JS won't be able to use it, but they can't with diffs either so they're not missing anything. Something else that could help make updating go faster - anchors to sections of the bug like comments-most-recent, add-comments, attachments, ...

Comment on attachment 257767 [details] New show_bug mockup, v1 the time tracking table isn't flat which makes it stick out like a sore thumb.

(In reply to comment #2) > (From update of attachment 257767 [details]) > the time tracking table isn't flat which makes it stick out like a sore thumb. What?? This bug isn't about modifying any part of the UI, it's just about hiding parts. If you're looking for the general bug about improving show_bug, that's bug 345674.

So... There was already a rather long-winded effort to clean up Bugzilla's UI ~8 months ago. See http://wiki.mozilla.org/Bugzilla:Bug_Layout_Revision. The result wasn't utopian perfection, but it was a good step forward and hilighted the concerns and needs of a lot of different people and use cases. A couple things here which I think will be considered fatal: * Users who are not logged in are already shown a reduced UI (non-editable). For logged in users, who are likely to be editing bugs, you're now requiring an extra click to do anything. * The visual appearance (after the extra click) looks more cluttered and noisy than before, which would be a step backwards. And rearranging things (again) is opening a big can of worms I'm not sure people want to revisit yet. Your new "bug summary table" at the top is an interesting idea, although one of the big concerns in the previous redesign was about reducing the amount of space used in the header. Since that info is going to be repeated in the editable area anyway, it's a bit redundant. Instead of moving the much-hated blob of radio-buttons for editing state into the header, I think a better approach is to get rid of them entirely, by making those fields directly editable. I did a rough-cut of the idea in one of my mockups: http://people.mozilla.com/~dolske/bugzilla/mockup2.html [This requires some deeper changes to bugzilla, as I understand it, though] The comment box was moved to the bottom on the theory that if you're replying to a conversation in the bug, that's the natural place to have it (eg, so you're not scrolling up and down in the bug to see what people recently said as you're replying). I think this ended up being a wash, though, as lots of times people want to add a comment without scrolling all the down. A floating box in an interesting idea, although as you not having it on the side makes the page really wide.

(In reply to comment #4) > So... There was already a rather long-winded effort to clean up Bugzilla's UI > ~8 months ago. See http://wiki.mozilla.org/Bugzilla:Bug_Layout_Revision. Yes, I know. That would belong in bug 345674. We've discussed it a lot in meetings. > * Users who are not logged in are already shown a reduced UI (non-editable). > For logged in users, who are likely to be editing bugs, you're now requiring > an extra click to do anything. Non-logged in users are still shown a cluttered UI that has all sorts of things they don't care about. And for everybody, I'm actually only requiring that extra click once, on one bug. I don't know if you noticed, but we actually save the state of what you've displayed, in cookies. That might not be working in this mock-up, but it should be working in the current patch in the dependency. > * The visual appearance (after the extra click) looks more cluttered and noisy > than before, which would be a step backwards. And rearranging things (again) is > opening a big can of worms I'm not sure people want to revisit yet. Yes, after this bug, that UI could be redesigned. > Instead of moving the much-hated blob of radio-buttons for editing state into > the header, I think a better approach is to get rid of them entirely, by making > those fields directly editable. I did a rough-cut of the idea in one of my > mockups: http://people.mozilla.com/~dolske/bugzilla/mockup2.html [This requires > some deeper changes to bugzilla, as I understand it, though] Yes, I'd be perfectly happy to discuss that in a separate bug. > The comment box was moved to the bottom on the theory that if you're replying > to a conversation in the bug, that's the natural place to have it (eg, so > you're not scrolling up and down in the bug to see what people recently said as > you're replying). I think this ended up being a wash, though, as lots of times > people want to add a comment without scrolling all the down. A floating box in > an interesting idea, although as you not having it on the side makes the page > really wide. I did attempt floating the box. It's just too wide.

Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set "blocking3.2" tp "?", and either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2.

Thanks to feedback at UX Eye, I've come to see that what we probably really need to do is to have basically two layouts, with TUI support--one is the "basic layout" that contains as little data as reasonably possible, and the second is the current show_bug layout.

Here's a work-in-progress patch that works almost fully, in the "Simple" view. I haven't fixed up the "Advanced" view yet. Also, the Simple view still needs to have an Add Comment box. This patch is a bundle, because it includes several images.

Here's a screenshot of what the attached patch does.

The layout for the comment headers are quite odd. The grey text makes it especially hard to read as a sentence, and the large font seems less optimal than some other way of doing the layout (bold? underline? background color?). I also think the comment number is the least important piece of data, and shouldn't be primary piece of data. I'd also argue that timezone isn't super useful in a "minimal" mode. Maybe something like the following works better: Max Kanat - November 19, 2010 8:24 PM Comment 9

mconnor: Those are all really excellent points, and I agree with you about all of them. I originally had the comment header data in bold, but it made too many bold objects on the page. I can think of something to do about it. I do think that the timezone is important, though, since a time of day is generally meaningless without it, unless we can grab the browser's timezone and automatically adjust things on the client side.

For timezone, the question is whether you're optimizing for random-person-off-the-internet or people who use the system more frequently. In the latter case, it's either obvious (small install, everyone in the same place) or it's learned once or not at all. Maybe a light background on the block? Just want to make sure it's clearly split up.

Well, the simple form is optimizing for casual users. By "the block", do you mean the part at the top with the bug data?

"Casual user" is undefined for me. Do you mean someone like a manager who doesn't often look at Bugzilla? The "This is the only time I'll ever look at Bugzilla" user probably isn't the right primary target here. By the block, I mean the comment header.

(In reply to comment #14) > "Casual user" is undefined for me. Do you mean someone like a manager who > doesn't often look at Bugzilla? The "This is the only time I'll ever look at > Bugzilla" user probably isn't the right primary target here. I'm mean the general bug reporter or bug reader from outside, who isn't a developer. > By the block, I mean the comment header. Ah, okay.

We are going to branch for Bugzilla 4.4 next week and this bug is either too invasive to be accepted for 4.4 at this point or shows no recent activity. The target milestone is reset and will be set again *only* when a patch is attached and approved. I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else.