launchpad-dev team mailing list archive

[Matthew Revell <matthew.revell@xxxxxxxxxxxxx>]

Howdy,

We've had a recurring complaint about the new bug listings layout: it
forces every bug to take up two lines in the listing.

We're fixing this: Huw has tweaked the layout so that you can see the
default data all on one line.

However, if you add any of the new data items (bug age, assignee,
etc), it's shown on a new second line.

That is an improvement: we're no longer introducing a UX regression
for people with wide screens, because they can see the same data they
always have all on one line.

The problem is this: the same stakeholders who wanted the additional
data are those people who have been most vocal in complaining about
the two line bug listings.

The issue, as they see it, is this: with the currently live (non-beta)
bug listings, their wide screens let them see on one line even those
bugs with long descriptions. So, they vertically fit more bugs into
one screen, because there's less/no wrapping. With the new layout,
lots of horizontal space is wasted because we force new data onto a
second line, so they see lots of white space to the right-hand of
their screen and fewer bugs vertically.

The problem we want to avoid is this: we believe that more than half
our users have screens of 1368 px wide, or smaller. We want those
people to enjoy and make full use of the additional data that we're
offering, while avoiding forcing them to scroll horizontally to see
it. We believe that there is a better way of presenting bug listings
than simply bunging a load more columns on the right.

My question is this: within the scope of the beta, do we have time to
add an option to the "Visible info" widget that allows people to
choose between a single-line view and multi-line?

The default view would be multi-line. We wouldn't be returning to
headed columns.

Why didn't we talk about this sooner? The issue of spilling onto a
second line did not come up strongly as a problem in the conversations
we had with users about the mock-ups. That's part of what betas are
for.

Strictly speaking, so long as we tweak the design so that existing
info is available on one line, we're not introducing a UX regression.
However, the stakeholders who requested the feature will experience a
regression as against the Greasemonkey scripts they have now.

If we can't change this within the scope of the beta, fine; that's
life. Either way, I'd like to know how much work is involved.

Thanks.

-- 
Matthew Revell
Launchpad Product Manager
Canonical

https://launchpad.net/~matthew.revell