Friendlier buglist layout

NEW
Unassigned

Status

()

Bugzilla
User Interface
--
enhancement
13 years ago
9 years ago

People

(Reporter: Roland, Unassigned)

Tracking

Details

Attachments

(1 obsolete attachment)

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

Current buglist is not very friendly bast for a first-time unsuspecting user.

I agree that table is a nice interface, but not necesarily the best for providing visual representation of a list of search results. It is great interface for comparing items in a listing by attributes or some other form of analyses on the list of bugs.

Table is also great if vertical space is an issue, but it horribly wastes horizontal space. The horizontal space constraints have lead to hackish solutions like partial (cropped) description column and use of abbreviated values in status resolution, OS and other columns.

Much cleaner look and frienlier feel for first time (esp. for non-technical) users could be achieved by using "RichList" type of layout of the buglist.

Reproducible: Always

Steps to Reproduce:
1. Navigate to the favorite bugzilla installation near You (eg http://bugzilla.mozilla.org/)
2. Specify a bugzilla query terms
3. Press "Search" button

Actual Results:  
I get a table of bug descriptions.
(now that 2.20 has changed the default font for the buglist, it looks a bit better, but still it could be improved)

Expected Results:  
I envision a bug listing that would look a bit more streamlined. Something along these lines:

+------------------------------------------------------------------------------+
| [large][b][a]Bug# 1:[/a] First bug description (the whole thing)[/b][/large] |                  
| [small]Reported: <date>, Status: NEW, ..., etc.[/small]                      |
+------------------------------------------------------------------------------+
| [large][b][a]Bug# r:[/a] Seconf bug description [/b][/large]                 |                  
| [small]Reported: <date>, Status: NEW, ... etc.[/small]                       |   
+------------------------------------------------------------------------------+ 

The basic idea is to split visible information into two lines:
In the prominent position (and formatting) on the first row there is a main identifying information about the bug - namely the bug number and summary (preferrably all of it)

The second row would contain additional information on the bug - basically any of the fields that could currently be configured to be displayed on the table layout should be also available for the new layout. Inclusion in the list should basially be configurable by the same means I can currently choose columns for the buglist.

As an additional bonus - it would be nice to be able to include some common actions to the bug list (eg. Accept, reassign to default owner, add an attachment, etc.)

These bug "cards" could also be encoded in html using some form of microformats (http://www.microformats.org), thus allowing both - flexible styling with CSS and automatic parsing of the results by 3rd party tools.

Comment 1

13 years ago
we already provide an xml output format for buglists...
What an interesting idea.  I especially like the ability to include common actions.  Of course, you can do that with the "change multiple" option to bug lists, but embedded buttons for the most common actions might be significantly easier to use.

This seems like some combination of the current bug list, the "change multiple" option, and the long format.  I like it.  We should explore it.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 3

13 years ago
In reply to timeless (comment #1)
> we already provide an xml output format for buglists...

That's nice, but this does not solve the usability issue, that was the main drive for this enhancement request. XML is great for toolbuilders that need and easy interface to read bug reports and interact with bugzilla.

A suggestion for using microformats (I assume You objected to that) is mostly targeted at visual designers who would get their hands on a wide array of bug attributes to use for styling the list. The machine-readability would just be an additional bonus to be exploited by either (or both) - client-side javascripts and browser addons.

Myk:
You are right - the new list would b something in between of the current list, change multiple option and long format - incorporating all that is good into one  easy to use listing.
Numbr of actions that can be directly performed on the bug in this list should be kept minimal, not to crowd the list but at the same time relevant enough to feel natural.
> Numbr of actions that can be directly performed on the bug in this list should
> be kept minimal, not to crowd the list but at the same time relevant enough to
> feel natural.

Makes sense to me, but to figure out what actions should be on the list (and more generally how the list should be structured, what info should and shouldn't be on it by default, etc.) it would be good to have a basic set of common use cases, i.e. which users would use this format, and for what common tasks.
(Reporter)

Comment 5

13 years ago
(In reply to comment #4)
The first list that pops into my mind are the actions that affect lifecycle of the bug - Confirm the bug (mark a NEW?), ACCEPT a bug, ASSIGN to default, WONTFIX, FIXED, INVALID, WORKSFORME, REOPEN, VERIFY, etc.
These are the actions that don't require any additional input.
Depending of course on the current status/resolution of the bug.
If some of these actions require a comment to go with - either exclude them or provide a way to write a comment before submitting.

Others that spring to my mind are "Add/Remove CC" to add or remove the user to/from CC list of the bug and "Add/Remove Vote" for adding or removing a vote to/from the bug.

The list should be configurable by the user. The defaults could be just those modifying status and resolution for starters.
(Reporter)

Comment 6

12 years ago
Any pogress on this?

Updated

12 years ago
Assignee: myk → ui

Comment 7

9 years ago
Created attachment 362518 [details] [diff] [review]
Patch for using permissions to change statuses
Attachment #362518 - Flags: review?

Comment 8

9 years ago
Comment on attachment 362518 [details] [diff] [review]
Patch for using permissions to change statuses

Attached to the wrong bug. Actually fixes 478681.
Attachment #362518 - Attachment is obsolete: true
Attachment #362518 - Flags: review?
You need to log in before you can comment on or make changes to this bug.