show_bug.cgi display layout (was: Minutes of the last Bugzilla meeting)
Kevin Benton
kevin.benton at amd.com
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 (https://bugzilla.mozilla.org/show_bug.cgi?id=9412)
> 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
> (https://bugzilla.mozilla.org/show_bug.cgi?id=345674, 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
lost.
Kevin
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20070115/370fd0db/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AMDLogo.png
Type: image/png
Size: 1784 bytes
Desc: not available
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20070115/370fd0db/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kevin.benton.vcf
Type: text/x-vcard
Size: 892 bytes
Desc: not available
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20070115/370fd0db/attachment.vcf>
More information about the developers
mailing list