Dynamic bug listings are too sparse

Status changed to 'Confirmed' because the bug affects multiple users.

I'd like to echo that. Part of this is probably also that the product(s) that are affected by the bug are shown for each bug. This information isn't really interesting when viewing the bug listing for a specific project.

@jelmer, It's not only the product, it's the target, which includes the series. So if the bug is linked to a particular series, you'll see that.

@Aaron, I can see how that's useful in some situations but it still makes it fairly disruptive to have the product name there every time. Usually I don't care which particular series is targeted.

changed the title so it can be found by entering the name used in the banner that is displayed on all pages currently.

Yep, I do prefer denser displays (it's interesting that Google Mail and Reader recently both did similar switches to less density, but gave you the option of putting it back).

For me, using a wide screen monitor, it's wasting the width - so I have a big gap between the end of most bug titles and the heat, but then have more data on the row below; if this was (optionally?) on the same row and I could shuffle the column widths around that would solve the problem.

Thanks for the comments about how the new design affects your use of Launchpad's bug tracker.

The first thing I'll say is that I'll ask Huw, who designed the new bug listings layout, to look at ways we might reduce the vertical space needed for each entry in the list.

There are a couple of things I'd like to mention, though. The old bug listings design was great for people with wide screen resolutions. If you have a common laptop resolution and you don't maximise the window, it's quite possible for ordinary bug listings to split onto two lines; particularly if you have a lengthy bug title and a "Fix Committed" status.

According to Google Analytics, at least 51.6% of visit to Launchpad over the past year were from people operating at a screen width of 1366 px or below.

We were going to make the problem worse for smaller screen users by making it possible to add more columns, such as bug age, tags, assignee, etc. So, we'd end up seeing horizontal scrolling and/or more spitting onto two lines at those lower resolutions.

So, we wanted to avoid making a page that would just get wider and wider, as that wouldn't provide a good experience for many people.

tl;dr: smaller screen sizes are more common amongst Launchpad users than you might expect. We'll look at what we can do to improve the experience for people with wider screens who value seeing as many bugs at one time as possible.

Hi Matthew,
  I certainly wouldn't want to make it hard to use on a laptop; (although hey 51.6% is hardly overwhelming odds!)
It's not uncommon for people to triage at meetups and the like, so I suspect that's not too unusual.

My suggestion would be to make it look like a spreadsheet view; where you can alter the width of/hide any column, and start
with some settings that are good for small displays.

Dave

@Jelmer, you can turn it off if you don't want to see it, and the preference is saved in a cookie.

Working with long lists of bugs on different packages, I find the multi-line layout very difficult to read and really eye-tiring.
Instead of reading the line straight from left to right, the eye is constantly jumping from one line to the other to consolidate information.

For example, in a list of defects affecting different packages, the new layout make it very difficult to find reports affecting the same package, and quickly check if one is already confirmed and worked on because the information is not directly below each other and the user must read one line every 2 lines.

Furthermore, there's no more colour for the status, it now requires to read the label (in light grey!) to know this information, while the colour code provided a direct read of the information.

@jibel Our original design had the info lined up into effective columns, so you wouldn't have the eye jumping problem. That's been a touch trickier to implement but we're working on fixing that now.

I think the problem at the root of this bug is that if you want to see both Importance and Status then you have no option but for each bug report to take up two lines in the listing. Linked to that, when you relatively few bits of information switched on you actually just see a load of wasted space.

We have a conflict between helping users of narrower screens (according to Google Analytics the majority of LP visitors) to see the various data options, with allowing users of wider screens to make the most of their vertical screen space.

Huw's working on a tweak to the design that would allow for having the following all on one line:

 * status
 * importance
 * bug number
 * bug title.

If you selected that information, plus icons such as whether the bug has a linked bzr branch, you'd have the same use of space as with the currently live design. If you wanted any of the new info, that's when it'd pop a second line underneath.

Here is a screenshot of some changes I've made in line with Matthew's comment above.

I like it Huw! But I wonder how are the other fields I can add going to be displayed? Like assignee, milestone, bug tags? is it going to break into two lines and how would it look?

I like it too. Wrapping could be reasonable.

Fixed in stable r14429 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/14429>.

has this actually landed? I still get two lines per bug, not just a single one - as is the case in Huw's screenshot in comment #13

It's only single line for the most important/primary data. Additional info flows to the second line still. Huw is doing another branch to use CSS3 media queries to provide a single line experience for people with larger monitors. Not sure if he's using this bug to track that or another though.

As Deryck mentions I have modified the behavior so that if there is room for additional information on the first line it will appear there. Once there are too many fields to fit on the first line the additional information will all appear on the second line. Obviously the larger your browser window the more information can be displayed. I've attached a screenshot to this affect.

Hi,
  That's much better than it was - thank you!

I think it could still get denser without harming anything though, here are two thoughts (although just thoughts):

  1) You could remove the horizontal separation line if you alternated having a slightly shaded background
for every second bug (I'm thinking of Gnucash's listings, without getting too close to old school fanfold paper!)

  2) It's still not using a wide display that well; see attached picture. The long bug names are wrapping and the heat flames are out of line, yet it's nowhere near the end of the horizontal lines.

Dave