show_bug.cgi display layout (was: Minutes of the last Bugzilla meeting)

Kevin Benton kevin.benton at
Mon Jan 15 17:08:38 UTC 2007

Bill Barry wrote:
> Frédéric Buclin wrote:
>>> is great for reporters and people looking for bugs, I think it is 
>>> worse for the people actually fixing the bugs. In a bug you now 
>>> scroll all the way to the bottom to read the last couple comments, 
>>> then scroll back to the top to change some aspect of the bug, and 
>>> then back to the bottom to add a comment or reassign it.
>> That's one of the reasons some of us dislike the UI on b.m.o. For 
>> triagers and QA people who don't need to comment, but only to change 
>> some fields, it's a pain to scroll up and down all the time.
>> Another question of debate is the place where the keywords, status 
>> whiteboard and URL fields are. Probably they shouldn't be so high in 
>> the page, as most(?) of us probably don't use or need them. The 
>> assignee and target milestone seem more important. But this is really 
>> a question of taste, and as long as there is no consensus, we will 
>> probably keep the current UI which is by far not perfect, but much 
>> better than the one we currently have in 2.22.
> In our bugzilla (stellarfinancial) most of the users use keywords, 
> status whiteboard, and assignee. The url field is not important, 
> neither is target milestone, hardware or OS. We will be implementing a 
> custom type field ( 
> or waiting for it to be implemented in cvs and this field will be 
> important to us.
> I have experimented with creating two separate bug pages (edit-bug and 
> view-bug) to try to resolve this issue, but I don't feel like I have 
> gotten positive feedback on it 
> (, ignore colors; I 
> am colorblind, they wont stay, they are just there to help identify 
> sections on the page). The eventual idea would be to have a user pref 
> about which to initially display on a bug and then allow a user to 
> switch between the two.
>> One part of the UI which will be ported upstream for 3.0 is the 
>> attachment table (the patch is currently under review) as there is a 
>> good consensus about it.
> What bug is this? Have we looked at considering the darwin bugzilla's 
> extra features on their attachment tables (highlight row when 
> mouseover for example)?
>> LpSolit
If I remember correctly, there was a very nice AJAX solution that 
allowed users to move parts of the bug display around changing the basic 
layout to suit their needs.  I don't know if it makes sense to consider 
something similar here, though I don't think it's fair to ask that it 
would land in 3.0.  My suggestion is that we allow certain blocks to 1) 
be collapsible, and 2) be shiftable - meaning that the sequence can be 
changed.  For example, some want the comment entry block at the bottom.  
Some want it below the fields listing.  Some don't want to see certain 
parts of the bug display (flags for example).  By allowing blocks to be 
collapsible and shiftable, users can move what they need to see first to 
the top of a bug.  I agree with the other commenter that mentioned that 
they thought there ought to be a commit button near the top of the bug 
(I think it was LpSolit).

In any case, I think we ought to also implement Javascript that checks 
to see if any field on the form has been changed before allowing users 
to hit their back button or click on one of the page's links.  That way, 
users can't leave a page without being given the opportunity to submit 
the changes first.  I don't know if this has already been done in 3.0 
yet, though I think it's becoming more and more critical as our user 
interface becomes more user-friendly.  Many applications now auto-submit 
so users don't have to click on a submit button, making it more likely 
that users will forget to click a submit button so their changes aren't 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AMDLogo.png
Type: image/png
Size: 1784 bytes
Desc: not available
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kevin.benton.vcf
Type: text/x-vcard
Size: 892 bytes
Desc: not available
URL: <>

More information about the developers mailing list