launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxxxxxx>]

On Tue, Sep 8, 2009 at 5:59 PM, Tom Berger<tom.berger@xxxxxxxxxxxxx> wrote:
> 2009/9/8 Martin Pool <mbp@xxxxxxxxxxxxx>:
>> 2009/9/5 Tom Berger <tom.berger@xxxxxxxxxxxxx>:
>>> 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:
>>
>> It looks nice.
>>
>>>
>>> * 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.
>>
>> Please think twice before getting rid of the hashed border for
>> privacy.  I think it works well.
>
> I don't understand what is it you think we're getting rid of. The only
> change is that the box moves to a new location.
>

I think Martin is referring to the grey & white barber shop stripes on
the left border of the page. They aren't visible in your mockup.

>> Why not change the oddly phrased "does this bug affect you" link
>> (there is a bug for this) to just be
>>  * this bug affects me
>>  * this bug doesn't affect me
>> then we can later show how many people have clicked each one (fixing a
>> very popular bug!)
>
> When we show the question it's because we don't know and want you to
> answer. When you've answered, we display one of the options you
> mention.
>
>> Similarly "Nominate for release" is misnamed; it should be "request
>> fix in series", and "also affects distribution" perhaps likewise.
>
> Again, I'm not convinced that the phrase you are suggesting is
> necessarily better. I'm not a heavy user, and I know how it works, so
> I may be the wrong person to judge this. I definitely want to hear
> more opinions about this.
>

Me too. Speak up distro folk!

>> Data between the large block of text in the description and the large
>> block of text in the comments is easily lost (there is a bug for
>> this).  Can we hove those things away to the right hand side?  I think
>> we can
>>
>>  * CVE reference: move to a portlet with a CVE field and edit icon
>> next to it; for bonus points give some clue what "CVE", if not the
>> monetary unit of Cape Verde.
>>
>>  CVE security vulnerability: ______ {/}
>
> I rather not do that, because it will take more space, and will be
> even more difficult to find (as you will usually have to scroll). I
> also don't think it's necessary to explain what CVE is - very few
> people work with the CVE database, and they always know what it means.

But if a bug has a CVE reference, and I don't know what CVE means, how
do I know I can safely ignore it?

>>  * Branches: a portlet of branches, and a (+) link branch -- for bonus
>> points this follows the principle of putting actions near the thing
>> they act upon.  Also it would be great to information there about the
>> state of merge proposals connected to those branches.
>
> I don't think putting branches in a portlet will work very well. One
> reason is that we want them to be quite prominent. If they're in a
> portlet they are likely to be without the viewport when the page first
> loads. Also, branch names tend to be long, some people just have
> annoyingly long nicknames ;)
>

I agree, a portlet probably won't work.

OTOH, Martin is right that the branch links are easily lost between
the description and the comments.

Speaking of which, have we tried putting tags above the description?
I'm not 100% convinced it's better, but would be interested to
compare.


>> Your sample data shows the somewhat annoying bug that status changes
>> are now fragmented from the text that describes them.  I understand if
>> you want to tackle that separately though.
>
> I don't think I understand what you mean by that.
>

I think Martin means that if I go to a bug, and say, "We aren't going
to fix this because it would take four years to fix and only make life
better for one user", mark the status as "Wont Fix" and then hit
submit (or do the same via email), then the "status change" will be
visually separated from the comment, even though the are the one
conceptual change.

>> The search box also gave you a link to 'all open bugs' which was
>> sometimes useful, but may be obsolete if the bugs homepage changes to
>> be more like a bug list.
>
> Exactly. I think that sticking lists and links everywhere is a bandage
> approach to difficult interaction and navigation. Wherever possible, I
> much rather fix how easy it is to find, remember, navigate to and
> operate the piece you need, than sticking a shallow copy of it on many
> pages.
>

Agreed.

However, there's also a lot to be said for aggregating, particularly
on something as interesting & central as the bug page.

>>> * The description, activity items, comments and comment input are
>>> nicely aligned.
>>> * 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.
>>> * The link to the original description floats to the right of the tags.
>>
>> Will the comment field still work the same way, as far as the
>> unfolding part for attachments?
>
> That's no longer how it works. Eventually, we'd like you to be able to
> add attachments inline using AJAX. That's a bit complicated to
> implement, so for now you have to use the boomerang form.
>

"a bit complicated to implement"? My sources tell me that this is
something of an understatement.

>> This does look really nice, and gives room for growth.  I think it
>> would be cool for example to show some portlets about other relevant
>> bugs, for instance likely duplicates, or overall project bug
>> statistics (filters/tags/targeted) as on the bugs home page.
>
> I'm open to the idea of showing other relevant bugs, but I also want
> to take the opportunity and clean up the bug page. The more marginal
> information we add, the harder it becomes to focus on the core. I
> think this is one of the main problems with the current design.
>

Exactly.

Which starts making me think. This new design is definitely a
substantial improvement, in that it reduces clutter and makes
interesting things more obvious. But it would be much more exciting if
it were accompanied by reasons why people are actually on the page in
the first place, and designed in terms of what they want to do there.

I realize that's a lot of work, and I don't think we have to do it for
3.0 necessarily. But I'd love to at least _talk_ about it before 3.0.

>> I would think about putting the bug number just before the summary,
>> rather than after it, and making that bug number be a link to the
>> short form url for the bug (https://launchpad.net/bugs/1234) so that
>> people can easily drag it.
>
> OK, that's a good idea. I haven't thought of that use case when I moved it.
>
>> And then along with the date originally reported it would be a bit
>> interesting to show the relative date last touched ("3 days ago" or
>> "1/2/09") - this can be inferred from the activity log but it would
>> mesh with people valuing the recently-changed-bugs list.
>
> Another nice idea. The challenge is to make it easy to understand
> which date is which. Let's give it a try.
>

We do this on branches. Guh. "Created on <foo> by <bar>, last modified
on <baz> by <qux>"

We used to do this on branches. I'm a little bit disappointed that it went away.


>> The dates sometimes look weird at the moment, because it says "3
>> seconds ago" which is  factually wrong by the time the page arrives in
>> my browser.  I think Launchpad needs some other representation of time
>> which goes "12:20 today", "3:30 yesterday", "29/2/2000".  Soyuz I
>> think recently did something similar.
>
> I like that idea. Pretty low-priority, as far as I'm concerned, but if
> there's already a better implementation in Soyuz (or another module)
> we should be consistent and use that across Launchpad.
>

As far as I'm aware, no other app in Launchpad has a better date
display. I believe that we are already consistent in our use of date
time formatters, as described in:
    https://dev.launchpad.net/DatetimeUsageGuide

There are a couple of known bugs in the formatter (it maxes out at
"weeks", iirc). Fixing them would be pretty easy, I think.

>> I realize you're focusing more here on the layout than on fixing ever
>> request for the bugs page, but it would be great if some of the
>> simpler ones could get done at the same time.
>
> It would be good to fix as much as we can. Most important, though, is
> to lay down the foundations on which we can make incremental fixes in
> subsequent releases.
>

I very strongly agree with this priority.

But if we're going to do that, let's make sure we've got the use cases
covered. (Or at least be conscious of which ones we are ignoring).

>> Hope that helps.  I'd be very happy to see screenshots or updates as
>> you go along.
>
> Sure, I'll update, though because of time, it's quite likely the most
> of the work on the next steps will be done already in code.
>

Wuu.

That's a long email. Thanks so much for taking the time to read it :)

jml