Bugtracker Interface Concept

From picket

Backgrounds

The most popular bug trackers (Bugzilla, Trac, Mantis) do not provide a comfortable interface.

Their interfaces are evidently utilitarian and do not adapted for usage by unskilled users or for usage in dynamic «intuitive» style in the situation of «feverish haste» or really short time-frames.

The review of disadvantages of the existing bug trackers is not the aim of this document. However, some interesting, comfortable and useful interface solutions is taken into consideration in this document.

Requirements for good bug tracker interface

The interface must be clear for unskilled user.
The interfaces of users with different responsibilities (managers, executives, reporters) must be adapted for their specific tasks.
The interface must not restrict the usage of the bug tracker for one specific bug life cycle or usage pattern.
The interface should not depend on specific bug tracker architecture.

Notations

Let's introduce the principal definitions.

Workspace

is the set of the bug tracker interface elements, adapted to specific tasks, running by specific user.

Bug status

is the stack of specific values or range of values of the several bug properties.

Sample

is the set of bugs in specific state.

User action

is the switch one bug or several bugs from one state to another by user.

Action scenarios

Let's define the scenarios, not depended on interaction with specific bug tracker , i.e. the universal scenarios of the user actions.

Bug creation

There are three cases to create a bug:

unskilled user creates the single bug that contains small information quantity;
skilled user creates a clear report of single bug, by rules, including a bunch of the required information;
responsive user reports a list of bugs in the line of her duty, including most of the required information.

Sample view

User of the bug tracker usually checks her own rarely changed set of the samples.

Bug view

User needs to see full text of the bug in next cases:

for the purpose of initial familiarizing;
for the purpose of recall some details about bug in memory;
in the process of the decision-making just before action implementation.

And also users turn into full bug description for the purpose of access to attendant information:

for view or update some comments to bug;
for view or alteration specific bug connections with other bugs;
for downloading or uploading attached files;
for view actions history related to bug.

It should be noted, that in last cases list user have to open the page with full bug information. Thus, user is forced to do it by the bug tracker interface.

Action implementation

As a rule user acts over bugs in the process of the revision of some bug sample. In such revision user decides how to change a status for each bug.

At that time, the set of states that bug could transform to from specific sample is changing rarely and is restricted to several (from two to four usually) number of them.

Scenarios diagrams

Let's show some use cases diagrams.

Diagram 1: «Standard variations scenarios of work example»

Wireframes

Wireframe 1

Above-listed principles are expressed on the Wireframe 1: actions realize via bug dragging from one state to another, the workspace is defined by central field, which represents input bugs stream, upper and bottom fields represent states in which bugs can be switched.

This approach gives possibility to manage user permissions in the way of restricting or allowing switching bugs form one state to another. Thus, one can manage the specific user actions which she is responsible to, instead of restricting or allowing the atomic operations like category changing, status changing, etc.

Thanks to sweeping generalization of the «state» concept this approach allows to implement not only simple bug parameters changing but it allows to implement more complicated patterns.

So, there is the block «To milestone 5 (childs of bug#23)» at the left bottom of Wireframe 1 which implements logic of connection a few bugs as childs to one that represents some milestone. Dragging out a bug or a few bugs into this block will result in making connection of these bugs to bug#23. Additionally status of these bugs will be set to “confirmed” as this block requires it.

Picket

We intend to using this wireframe as the base for the interface of the Picket Bugtracker.