New feature – Customise your bug listings

Custom Bug Listings

Over the past few months the Launchpad Orange Squad has been working to make it easier to get the information that matters to you from bug listings.

A lot of you have said in the past that you’d like to be able to filter bugs in a way that works best for you. Hopefully this new feature, with its customisable functionality should help with this goal, filling your screen with more of what you want to see.

Custom bug listings green bug


You can now sort bugs by criteria such as name, importance, status and age. You can switch on the criteria that you use most and turn off criteria that you don’t use. So if you always like to see bug age, but aren’t interested in heat, you can switch on age and switch off heat, and so on.

bug column screen shot


We’ve also redesigned how bug listings are displayed – fitting more information into each bug listing, and adding sort options such as bug age, assignee, reporter, and tags.

You can put your results into ascending or descending order without having to reload the page, and you’ll be able to save your preferred layout, so your settings will be saved for the next time you need to look over your bugs.

User research

This was my first main project since joining the Launchpad team back in November as the new Usability & Communications Specialist. User research has played an important part in how we’ve defined the feature and the decisions the team has made to improve the display, wording and functionality.

A number of you took part in one to one interviews, at group sessions at UDS-P and by taking part in an online survey. Thanks to everyone involved – what you told us has really helped to make this feature a more user-friendly experience. Some of our user research results (link) are already available online, with more being added soon. We’ll be carrying out some further tests in the weeks ahead, so please get in touch if you’d like to get involved.


Every new feature has teething problems, and custom bug listings is no different. We still have a number of bugs that need tweaking, so please bear with us, and file any bugs if you spot anything that’s still out there.

Tags: ,

6 Responses to “New feature – Customise your bug listings”

  1. Daniel Hahler Says:

    The layout of the Status and Importance columns is far too distracting: it should be narrower and use icons instead probably.

  2. Uday Reddy Says:

    +1 for that comment.

    Here is what I wrote on the Question/Answer section of the project, before I discovered this blog entry:

    I thought the old format of the bug-tracker was just perfect: simple, clean and elegant. I don’t find the new format to be in any way an improvement. Quite the contrary.

    Uday Reddy

  3. Uday Reddy Says:

    By the way, the old format is still available, e.g., on the milestone pages like this:

    Clearly, these listings allow one to “sort bugs by criteria such as name, importance, status” just by clicking, the supposed innovations that have been claimed for the current format. There was no “age” column to click on in the old format, but the literate users always knew that the drop-down menu could be used for sorting by a number of other criteria.

  4. Dan Harrop-Griffiths Says:


    Thanks for your comments.

    We still have some work to do for this feature, most notably making sure that the most important information is displayed on the 1st line (see Bug #905414).

    This should make data flowing onto the 2nd line a less frequent occurrence, resulting in users being able to see more bugs without vertical scrolling. We gathered data from users to find out what the most important information types were from an online survey, which had some pretty strong results.

    The new design has had some great comments in user testing, during the beta and since going live.

    We looked hard for a compromise between the needs of people who need many bugs listed on screen at once and the need to make the listing easily scannable. We decided that adding more and more columns, with each new item of info, would lead to unpleasant horizontal scrolling or uselessly narrow columns.

    So, we went for an approach nearer to that of AskUbuntu. This made it easier to add or remove items, especially for the majority of Launchpad visits coming from screen widths of 1368 px or below.

  5. Olivier Dony Says:

    As a color-blind, I must say I have a hard time adapting to the new UI style and colors. I think having the Importance on the middle-right of the screen was easier to spot for me (in western cultures we scan screens from top-left to bottom-right). The plain text labels were also easier to read and distinguish from each other: color-on-white text is much easier to read for color-blind than “reverse-video” labels, and the difference in label length made it even more obvious (now they all have the same size).
    Having the Importance in the middle and further from the Status made it also more accessible, and more visibly “important”. Basically now the Importance and Status columns look like a single Adwords area to me (not really but you get the point), and my eyes skip them completely.

    I understand that designing for color-blind is not a priority, but there may be more of us around than you think (~10% of males) and many are geeks involved in open source projects 😉 I would be surprised if there weren’t any color-blind people in LP dev squads and/or LP beta-testers… might be worth double-checking designs with them from time to time…

    Being able to customize the bug lists is however great, and I think most non color-blind newcomers to LP will find the new design intuitive to use (unlike luddites like me), so well done!

  6. Uday Reddy Says:

    Sorry, Dan. I am really being a lot more negative than I might appear. My work got seriously impaired when the new UI came on, and it hasn’t yet recovered.

    In my typical interaction with the bug tracker, I search for something that should be there on the tracker, get a lot of results, and then sort them by different orders based on my memory of when the bug report might have been filed or acted upon, quickly scan through the list and find the one I want.

    The new UI obstructs almost everything in this workflow. The sort-by drop-down menu has been removed. Now I have to “customize” the display first in order to sort by a particular key. Then put up with the extra clutter that it generates, taking 10 times as long to locate the bug report. After it is all done, I have to “recustomize” the display to turn off the clutter again. This is hardly the way to go. I wish the new features were added without destroying the old features.

    Even now, it should be a simple matter to reinstate the old UI for a separate search function. The people that like the new “customizations” can continue to use them. The old serious workers can get on with our job.

Leave a Reply