Make Bugzilla Pretty: A Contest

[Frédéric Buclin]

Le 27. 09. 10 21:25, Bill Barry a écrit :
>> I propose to have the fields marked as "Advanced" to not appear *unless*
>> they contain set data, then appear as a read-only value until the the
>> "Show Advanced Fields" link is clicked.

IMO, we don't need a "Show Advanced Fields" link to make fields
editable. AFAIK, you can use the onclick event to turn a read-only field
into an editable one when you click on it.


> Internally here we have discussed having a new preference tab which
> looks a bit like an edit bug page, but all the fields are mocked up
> images of themselves. On this page you would hover over a field and 5
> options would appear:

The problem is that you are moving the complexity elsewhere, and you are
still asking your users to know what to do with them.

I would tend to say (based on no scientific study) that the reporter and
users lambda (typically the ones in the CC list) only care about one
thing: when will the bug be fixed? So besides the status+resolution and
the target milestone fields, and maybe the priority+severity ones, they
are not really interested in the other fields (especially the
OS/platform, keywords, URL, status whiteboard, dependency and component
ones, + maybe the CC list as such lambda users don't know the other guys
in the CC list). They could eventually be interested in already set
flags, but in no case in unset flags. All the fields I mentioned as not
interesting by the lambda users should be hidden by default, not even as
read-only. The "Show Advanced Fields" link that dkl was talking about
earlier could the be used to show all hidden fields (maybe as read-only,
and using the onclick trick mentioned above).

I'm not really worried about advanced users, because 1) they do care
about all fields, or almost all of them, and 2) they know which fields
can be ignored, and no longer pay attention to them.

LpSolit