launchpad-dev team mailing list archive

[Tom Berger <tom.berger@xxxxxxxxxxxxx>]

2009/9/8 Jonathan Lange <jml@xxxxxxxxxxxxx>:
> On Sat, Sep 5, 2009 at 2:22 AM, Tom Berger<tom.berger@xxxxxxxxxxxxx> wrote:
>> The bug page will be redesigned for 3.0 to make it easier to work
>> with. Unlike other pages, the redesign is pretty light - the template
>> changes to the new two column style, but most elements stay where you
>> know them. Things to note:
>>
>> * Bug-related information (secrecy, me too) is moved into the
>> right-hand side, just below the affects table. This should make this
>> information stand out better.
>
> Secrecy was already on the right-hand side, but above the affects
> table. What's the thinking behind moving it below the affects table?

I think that it is easy to miss where it currently is. I also don't
like how different bits of information all have a different format.
The new right hand side is the place where users should now expect to
find additional information about the object they're viewing, and so I
think that putting the secrecy portlet at the top of the column is the
best location.

> Is it at all possible to allow it to be side-by-side with the affects
> table?

The problem is that the affects table is hard to condense. If it was
narrower, you'd see line breaks within the cells more often. Also, the
way it breaks the page communicates that it is 'special' - it's a view
into a collection of objects, rather than properties of the object the
page renders. We can experiment with limiting it, but I doubt this
will work well.

> That's said, it's important to have a universal location for the
> secrecy information, since it's common to so many objects.

That's an idea I like very much. We don't currently have such a place,
so I guess now is a good time for coming up with something.

> Will we be using the same font for description and comment again?

Yes, I'd like that.

>> * CVE references float to the right of the branch links. They are
>> quite rare and where they are now they steal too much vertical space.
>
> Presumably they are displayed only if they exist?

Indeed. Just like they do now.

> Yes. In addition to the ones above, even.
>
>  * "Report another bug" is missing from this page. I think it's
> important for two separate use cases. One is "This is not the bug I
> was looking for", which often[1] happens when a Launchpad bug is found
> via a link or a google search. The other is when you are a developer
> working on some code and you find that you are being compelled to file
> bug after bug to avoid yak shaving.

That's a stupid omission on my part. Of course we should keep that
link. I don't like its current location at the bottom of the page. I
suggest we add it to the right-hand column.

>  * With the page looking so clean, "Activity Log" stands out. What's it for?

Eventually, we'd like to get rid of the separate page for the activity
log. Instead, well make all activity items display inline (currently
only some of them do) and provide a way to toggle their display. This
is unlikely to make it to 3.0, and for now I opted to not changing the
way the activity log works at all.

>  * The "Related branches" section also feels a bit out of place. It's
> not clear what I'm supposed to do with them or why they are being
> shown. Would it be possible to link to merge proposals if they exist,
> or provide controls for creating a merge proposal? Maybe something to
> talk about w/ thumper.

Any suggestions for a better place? Related branches are where they
are because we want them to be prominent. In a way, they are almost as
important as items in the affects table. I don't know if merge
proposals are a better object to link to (but I haven't given that
much thought yet). Creating objects from within the page is always a
great thing to have, as long as we can do it inline, using AJAX.

>  * There are a lot of pen icons.

Oh yes. This is a Launchpad-wide problem, but I don't think it is as
severe on any other page. I have some thoughts on what to do about
that which I'll present elsewhere. For now, a lighter icon (Martin has
already prepared one for me to use) should at least reduce the visual
pain.

>  * Is the workflow still the same for bug task editing?

I'm not sure I understand the question. The modeling of the data stays
the same, but we're moving towards only changing the values inline,
using AJAX (or in a boomerang form if JS is not available).

>  * If we had a "Find possible duplicates of this bug" feature, where
> would it go?

Haven't given that any thought, but I'd say on a different page,
linked from the right-hand column.