launchpad-dev team mailing list archive

[Tom Berger <tom.berger@xxxxxxxxxxxxx>]

2009/9/8 Jonathan Lange <jml@xxxxxxxxxxxxx>:
> On Tue, Sep 8, 2009 at 5:26 PM, Tom Berger<tom.berger@xxxxxxxxxxxxx> wrote:
>> 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.
>>
>
> The new branch page has it on the top right. e.g.
>  https://code.edge.launchpad.net/~launchpad-pqm/launchpad/db-devel
>  https://code.edge.launchpad.net/~launchpad/lp-dev-utils/trunk

Well, that's exactly what I'm proposing. It's just that on the bug
page the sidebar starts lower.

> (sorry to those who cannot see the private branch)
>
> This is different from the bugs page design, and for all I know might
> be different from team privacy or what have you. What's going to give?
>
>>> 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.
>>
>
> OK. That makes sense.
>
>>> 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.
>>
>
> Glad to hear it :)
>
>>> 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.
>>
>
> I think this makes a lot of sense.
>
>>>  * 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.
>>
>
> I like that plan, both the goal and the steps to reach it. Can we have
> some hover text or something that explains what it is?

Sure, all we need to do is add a title to the link.

>>>  * 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.
>>
>
> Merge proposals are definitely a better object to link to, if they exist.

And if not? I think what we should do is display both. Link to the
branch, and if it's proposed for merging show that and link to the
merge proposal.

> +1 on the 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.
>>
>
> Cool.
>
>>>  * 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).
>>
>
> That's kind of what I meant.
>
> Historically, one of the problems with the bugs page has been that
> there are two "Comment" fields that interact surprisingly if you don't
> know what you are doing, or forget which one you've typed in.
>
> Also, recent changes to the bugtask form have increased the number of
> accidental status changes and have made it harder to conceptually link
> a comment, a status change and a priority change (bug 412925).
>
> Is this design meant to address either of these issues? If not, how
> are we going to address them?

We probably won't solve these problems for 3.0, but we do have a plan.
We will present the changes grouped when they're done by the same
person within the interval for mail notification. Also, we have a very
vague plan for prompting the user to add a comment after they've done
some changes (but no design yet).

>>>  * 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.
>>
>
> Yeah, that makes sense.
>
> That reminds me. Where on the new design can one find links to duplicate bugs?

That's yet another omission. Let me think of something. Ideally I'd
like them not to be in the side-bar, but if we don't find any better
solution we can leave  them there.