launchpad-dev team mailing list archive

[Matthew Paul Thomas <mpt@xxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Albisetti wrote on 20/10/09 20:57:
>...
> I've been thinking about the bug page. I've had a few attempts at
> creating wireframes of what it could look like, but no matter how much I
> try, I always get taken down a path that requires radical changes.

Nothing wrong with that. :-) As long as any new design is obviously
better, and you introduce it all at once to minimize disruption.

It's not clear that any of the problems you list require radical changes
to solve, though -- they could all be fixed incrementally. Maybe this
would be more obvious with a wireframe or two.

>...
> - Show the relationship between bugtasks better. Where did the bug
> originate? Where was it fixed? What is it blocked on?  In general, if
> a bug has a bugtask on a package and on upstream, it's pretty safe to
> say that it depends on upstream fixing it first.

It doesn't really matter where the bug originated -- what matters is
what software it actually affects. As for upstream fixing it first, the
Papercuts project is a pretty big counterexample to that.

There is a bit of history here, though, which could inspire some
simplification. The "Won't Fix" status was originally intended to be
"Won't Fix Here", where a bug does affect a project/package but really
does need to be fixed elsewhere. (For example, a bug in a library that
could theoretically be worked around by an application using the
library, but in practice the library should just be fixed.) But people
never used it that way; even Launchpad developers now use "Won't Fix"
merely as a euphemism for the harsher-sounding "Rejected". Therefore,
there is no point in "Won't Fix" and "Rejected" coexisting; they should
be merged.

>...
> - "Also affects..." is a mess. You can create another bugtask with 3
> different options (Also affects project, Also affects distribution and
> Target to release). Target to release doesn't do what most people
> expect, because it targets it to a series. A release comes from a
> milestone.
> We need to improve the flow there, maybe collapse the "Also affects..."
> into one picker that selects packages or products.

Absolutely. <http://launchpad.net/bugs/1334>

> - Descriptions should be more prominent. They describe the bug, they
> should be more visible.

It would help if the description used the same font size as normal
Launchpad text. And I think getting rid of the "Bug Description" heading
would help here, too, because it's crowding the space under the Affects
table.

> - Related branches is too vague. If there's a branch linked to a bug,
> what you're really saying is "this probably fixes it". We probably
> want to show if there are any merge proposals attached to that branch,
> when it was last updated, and maybe even let you subscribe to it from
> the bug.

In addition to what Aaron said, I'm often now seeing the trunk branch
for a project linked to a bug report. I don't know why it's happening,
but I'm not sure it's useful to someone reading the bug report.

> - The subscribers portlet is too long. We have a mockup from a
> previous sprint on a way to fix that, collapsing all the sections,
> giving you the description on why they are subscribed in a tooltip and
> cutting it off after a number of subscribers.

It's too long for what? People do, and should, behave differently when
commenting on a bug report that has 200 subscribers than on one that has
three subscribers. And listing every subscriber is probably the most
effective way of communicating that -- more visually obvious than, for
example, just giving a count. (You don't actually need to know the exact
number, you just need a sense of the audience size.)

Another case to consider is: I'm talking about a bug with someone, and
they ask me to check that they're subscribed to the bug report. With the
current design, I can do this with the browser's Find command.

If the subscriber list is displacing other information (e.g. the list of
linked blueprints), I suggest moving that information into the main
content area.

>                                               Maybe you don't need to
> show my name on there if there's already an unsubscribe button?

That might be a bit non-obvious.

> - Adding attachments workflow needs to be finished off. Ajaxified, show
> them in a better way than squished in small a box on the bottom right,
> attached patches should be shown in the same place as linked branches,
> and images, in a perfect world, should show a thumbnail.

Yes! And filetype icons for the others.

> - You should be able to specify that a new tag is an official one, if
> you have permissions on the project.

With some careful design, I think the whole "official tags" bureaucracy
could be abolished.

> - Tell me how much the bug affects users. Show me the number, show be
> a flame, but show me something.

This could be merged with the subscriber list somehow.

> - Maybe h1's should be a bit smaller in general, so we don't have so
> many titles that wrap?

Relatedly, it's awkward to have the Edit button for a bug summary to be
in a different place depending on the length of that summary and on the
width of the browser window. I wonder if the visual style for a bug
description's Edit button could be beautified and generalized to other
often-wide text.

> - Being on a roll here, how about highlighting the reporters' comments?
> His comments will most likely be very important.

Yep. <http://launchpad.net/bugs/58670>

>
> Phew, having gotten all of that out of my head, here's what I think we
> should do for the immediate future:
>
> 1) Collapse activity information and comments like we do for emails.
> It's way too noisy today.

Yes. <https://dev.launchpad.net/BugHistory>

> 2) Tweak the bugtask table so the status and importance don't use so
> much width of it unnecessarily, add &nbsp; between all edit buttons
> and it's object

Maybe this can be solved with consistent CSS for all things that have
edit buttons.

> 3) Add more whitespace between the links below the table and the
> description and whitespace between tags and related branches
>...

As above, I think just nuking the "Bug Description" heading -- and
leaving the placement of everything otherwise the same -- would work.

Cheers
- --
Matthew Paul Thomas
http://mpt.net.nz/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkrgYE0ACgkQ6PUxNfU6ecq/kQCg1Bhf2f1SAWAYx1koM8VCbXJA
17IAoKKfLdSaJLihAo8XG/FjYoAPnZIl
=LkUA
-----END PGP SIGNATURE-----