launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxxxxxx>]

On Tue, Oct 20, 2009 at 8:57 PM, Martin Albisetti
<martin.albisetti@xxxxxxxxxxxxx> wrote:
> Hello Launchpaderos and Launchpaderas,
>
> 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. Considering this
> is the most used page in Launchpad, radical changes need to be made sensibly
> and ensure that they are verifiable better.
>

+1

> So, I will start working on different layouts while I discuss it with
> different people and through the list, and we can slowly produce something
> that works well for everybody.
>
> Problems I'm trying to solve:
>

Let me stop you here. Why are you trying to solve these problems? Do
we have results from user testing? Do we have a cluster of bug reports
that are all about UI on the bug page? That is, what are the inputs?

Also, although there's a lot of good in thinking about the problems,
I'd also like to have some idea of the constraints that a new bug page
must satisfy. That way, others can go off and experiment. Set-based
design ftw!

> - 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. If it was first reported in the
> package, we have origin.
>

Aaron made a good point about this.

> Some of this may require data model changes, some of them don't. Lets
> explore what we want to do first.
>

I very strongly agree with this approach.

> - "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.
>
> - Descriptions should be more prominent. They describe the bug, they should
> be more visible.
>
> - 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.
>

This is a problem in the model, not in the UI.

> - 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. Maybe you don't need to show my name on there if
> there's already an unsubscribe button?
>
> - 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.
>
> - You should be able to specify that a new tag is an official one, if you
> have permissions on the project.
>
> - Tell me how much the bug affects users. Show me the number, show be a
> flame, but show me something.
>
> - Maybe h1's should be a bit smaller in general, so we don't have so many
> titles that wrap?
>
> - Being on a roll here, how about highlighting the reporters' comments?  His
> comments will most likely be very important.
>

I think you only want to do this subtly. If anything, I think you want
to highlight comments from developers. Possible ways of calculating
"developer" includes:
  - driver of a project
  - lots of karma in that project
  - commit rights to trunk
  - "standing"

Hmm. We could do a lot better at being social, couldn't we?

>
> 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.
>
> 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
>
> 3) Add more whitespace between the links below the table and the description
> and whitespace between tags and related branches
>
>
>
> Apologies for the long email, and the people who got to the end, you are now
> my friends.
>

¡Mi amigo!

Seriously, thanks for getting this rolling.

jml