launchpad-dev team mailing list archive

[Tom Berger <tom.berger@xxxxxxxxxxxxx>]

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.

>> * All bug-related actions are now on the right hand side. That should
>> make them easier to find.
>
> +1
>
> "Also notified" has never had a clear meaning to me, maybe it means
> "Implicitly subscribed" and should say so?

Actually, I'm not sure one is better than the other. Will it really be
clearer if we used the phrase you are suggesting? But I agree that
this can be confusing to many users, so any suggestions for
improvement are welcome.

> On for example
> <https://bugs.edge.launchpad.net/bzr/+bug/392355> there are two
> screenfuls of people 'also notified', many of whom I've never heard of
> and don't care about.  I am sometimes interested in who's specifically
> shown interest in the bug by subscribing but I don't think I've ever
> cared about the 'also notified' list.  So it seems like a waste of
> space.  If it's really needed, maybe it can be behind a disclosure
> triangle.

If we already require the user to click to show the list, we could
think of many ways to display it (a popup, a new page). The reason the
list of subscribers (direct and indirect) is there is so that you know
who is going to receive an email when you change something. I think
that's very important information, but it may be possible to find a
better way to display it.

> Let's keep a link for reporting a new bug, and put it above the fold
> (thereby fixing a bug).  I do that all the time when it turns out the
> bug I thought was mine is in fact different.  Also, I think if this
> link is not reasonably prominent, it encourages some users to add
> random unrelated comments to whatever bug they land on.

+1 and +1. I have omitted the link from the mockup by mistake. We
should keep it, and should be where people expect it - high up in the
actions section of the right-hand column.

> 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.

> 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.

>  * 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 ;)

>  * Original description: this is ok in this position cause it really
> does relate to the description, but it would be cooler if there was
> just a timeline entry saying "description changed" and linking to the
> previous version.  (Isn't this already there? If so, just remove the
> link under the description.)

Yes, that's already in place (though it can be improved a bit). I
think it's still important to indicate that the description has
changed next to it, because it is implicitly associated with the bug
reporter, who may not have written the latest version.

> Moving those links would break up the "big list of random actions"
> effect still somewhat present in this mockup, and instead get more
> towards the bug having attributes you can act upon.

Actually, I don't think there's a clear winner between these two
competing paradigms. Moving everything into the right hand column
would probably result in the same loss of information. It can be very
difficult to orient oneself within a very long list of actions and
properties. I think what we need to do is strike a balance between the
two, based on these principles. That's hard to do, though, so lots of
tweaking will be required before we get it right. All ideas very
welcome.

> 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.

>> * The search portlet is gone. People can use the common search box or
>> go up one level for an advanced search.
>
> The common search box is not visible in this sketch but presumably it's there.

It is in the sketch. I don't think it's prominent enough, but that's a
Launchpad-wide problem.

> 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.

>> * 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.

> It looks like you got rid of the unfolding dialog under the status.
> This is the only way at the moment to change some things, and the only
> way altogether to change status and explain why you're changing it.
> Perhaps it should stay until things are properly batched in both mail
> and the web site.

I agree. We should keep it until you can get the same workflow using AJAX.

> I like your pencil icon here better than the one actually used in lp,
> because it looks more like a pencil.

Heh. Yes, the edit icon is painful right now. It will be improved in
the future, I hope.

> 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.

> 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.

> There is some inconsistency in both the current page and I presume
> this one as to whether clicking the bugtask fields takes you to the
> relevant thing (milestone, project, person), or lets you edit it
> (status, importance).  That may not be a problem, if the rule is
> "takes you there, if there is any 'there', otherwise edits it."

If you ask me, the rule should be, if it's editable, clicking it lets
you edit it. Seems not everyone agrees, so for now we have a mixed
approach, where we indicate using colour whether something goes to a
new page or opens and editor inline. I think this is another one of
these cases where we fix broken navigation by breaking it even more.

> 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.

> You seem to have quietly dropped the "offer mentorship", which is good.

Ah, you noticed. I was hoping to sneak it out quietly :)

If anyone doesn't think that it should go, now would be a good time to speak up.

> 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.

> 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.