background

bugzilla.mozilla.org presents some interesting problems when it comes to UX; while it has a singular view of bug data, most teams use bugzilla in slightly different ways. some of these differences surface in fields used to track work (keywords, flags, whiteboard, summary), how bugs are prioritised (whiteboard, custom fields, priority fields), and even how inter-bug dependancies are tracked.

the net result is trying to design an user interface for viewing bugs optimised for how people use bugzilla is a near impossible task. in light of this, we’ve been working on a framework which allows us to deploy multiple experimental alternative view of bugs.

goals

the goals are to enable alternative bug views in a way which enables rapid development and doesn’t force incomplete or broken implementations upon users.

implemented as a bugzilla extension, alternativeUI provides a harness for alternative bug views, and implements the view selection - currently as a simple user preference. in the future we expect bugzilla to be able to automatically change view depending on the bug or your relationship to it. for example, we could present a slightly (or radically!) different view of a bug to the assignee vs. the reviewer vs. someone not involved in the bug.

generic show_bug alternative

of course a framework for alternative bug views would be useless without an actual alternative. i’ve been working on one which will likely be the basis of future experiments. show/edit modality is at the core of this design — a bug is loaded with most fields as static text and switching to “edit mode” is required to make changes.

ideas we’re throwing around:

hiding fields

if a field doesn’t have a value set there’s no need for that field to be displayed by default. removing those fields from the initial display greatly reduces the noise and complexity generally associated with bugzilla.

we can also use the user’s group membership or involvement in the bug as a cue to which data should be initially visible. an example would be hiding the QE flags from users who are not associated with the bug or members of a the QE team.

performance

when a bug is loaded right now in bugzilla, it has to load all the alternatives for many fields (products, components, versions, milestones, flags, …). in most cases bugzilla’s fine-grained security model results in a measurable cost to generating these alternatives — you can see the difference yourself by logging out of bugzilla or opening a bug in a private tab and comparing the page load times against a logged-in request.

by loading a bug as read-only initially, we can defer loading the alternatives until after the user clicks on ‘edit’.

selected “editable by default”

requiring a mode switch to perform any change to a bug isn’t an ideal situation either - operations that are frequently performed should be easy to do with minimal extraneous steps.

the current implementation allows you to comment, CC, or vote for a bug without switching to edit mode. this can be extended to, for example, allow the bug’s assignee to change a bug’s status/resolution without needing to switch to edit mode.

screenshots