launchpad-dev team mailing list archive

[Tom Berger <tom.berger@xxxxxxxxxxxxx>]

2009/9/8 Martin Pool <mbp@xxxxxxxxxxxxx>:
> 2009/9/8 Tom Berger <tom.berger@xxxxxxxxxxxxx>:
>> 2009/9/8 Martin Pool <mbp@xxxxxxxxxxxxx>:
>>> 2009/9/5 Tom Berger <tom.berger@xxxxxxxxxxxxx>:
>>> 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 misremembered how it worked at the moment.  In some other pages (or
> proposals?) privacy is indicated by a hashed bar across the whole
> page, and the control is next to that.
>
>>
>>>> * 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.
>
> Maybe you can tell me what it means now, then we can work out a short
> label for it?

It means "People who will receive email despite not being directly
subscribed to the bug, for one of several possible reasons, like have
an important role in the project or being subscribed to all email for
the project".

>>
>>> 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).
>
> Right.
>
>> 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.
>
> That's really interesting.  I've never thought about it that way.  Is
> it that you think "oh that's a lot of people, maybe I won't send
> mail", or is it "I have to be sure that Fred sees this, let me check
> he's subscribed?"
>
> Either way, by the time you have 20 or even 10 random people on the
> list it seems to be of limited use.
>
> If I want to be sure a particular person sees it, I'd normally
> subscribe them directly.  And in that case I typically want more than
> just 'this will get to their mail box' but something a bit more
> semantic.

The use case where you want to be sure someone will receive your email
is, I think, more important. This conversation, though, makes me
re-think the whole in-page subscribers list. Maybe it's not such a
great idea to have it there. Let's think if we can come up with a
better way of satisfying all the important use cases without showing
the subscribers list there. Either way, I don't think we'll be able to
make substantial changes in time for 3.0, so I suggest proceeding with
the portlet as-is and trying to improve it later.

>>> 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.
>
> I'd think about giving it the extra emphasis of a colored link as is
> used on some other pages.

Yes. We should use the same format used everywhere in the 'get
involved' portlet (but without the title or the additional links).

>>
>>> 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.
>
> ok
>
>>
>>> 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.
>
> https://bugs.edge.launchpad.net/malone/+bug/132733
>
> It has nothing to do with releases! :-)  Well, indirectly it's going
> to affect it, but it doesn't connect up the launchpad objects called
> Bug and Release afaik.
>
>
>>
>>> 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.
>
> True, though many other people will also see this and not know.
>
> I don't think it's actually a problem here on reflection.  It was a
> problem on the product bugs home page (prior to this revamp) where it
> was shown with a big scary icon and no explanation.
>
>>>  * 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 ;)
>
> True, but the current location is not great.

I don't actually have a problem with the location (nor do I feel that
information is lost placed between the description and comments), but
I've heard this opinion from more than one person, so let's try and
come up with new ideas.

>>
>>>  * 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.
>
> Personally I don't care about this; anyone who's used Launchpad knows
> it can be edited, and it's almost always edited to make things better
> and clearer, not to make the reporter look bad.

I don't think there's much harm in keeping the link, and it is
sometimes useful, so unless I'm convinced that we'll be much better
off without it, I'd like to keep it for now.

>>> 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.
>
> Fair enough.
>
> I think the overriding issue here is: stuff between the description
> and comments are effectively buried.  I don't know if you've tried to
> follow those links but it grates a bit every time I do it.
>
> One way around it, if we don't want them in a portlet, would be to
> show the act of attaching the branch in the interleaved history, like
> we would if someone attached a patch.  Then the relevant ones will
> typically be near the bottom.

We do that anyway (not for everything, but that will be completed).
The problem is that to get to the information you need to scroll and
look at all items in the list. Some information, we want to be visible
as soon as the page loads.

Could a different formatting, but without changing the location, improve things?

>>> 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.
>
> https://bugs.edge.launchpad.net/malone/+bug/353890
>
> I want to see one block on this bug which says
>
>  Groucho Mark on 31/2/1935
>  status: New -> Confirmed
>  blah de blah blah blah comment
>
> not two.

Yes, that's definitely something we want to do. It might not make it
for 3.0, but if not I hope it will be scheduled soon after 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.
>
> Oh, is it moving to the bottom of the page?  That seem poor.

I agree. You can see examples on some of the pages that have already
been converted. I think that way it's impossible to find without
knowing it's there in advance.

>>> 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.
>
> Hearty approval.
>
>>
>>>> * 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.
>
> That's true, I'm a bit out of date, despite probably having used the
> current 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.
>
> The rememberthemilk.com one is nice - but that's out of scope.
>
>>
>>> 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 think your point above is probably right - let's make the overall
> bugs home page good, then you won't need this.  People can use browser
> tabs or windows.
>
>>> 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.
>
> That would be simple and consistent, but I think problematic if
> followed more widely - for instance when a branch is linked to a bug
> I'm going to want to go to that bug much more often than I'll want to
> change the linkage.
>
>> 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.
>
> Of course the problem is that green and blue (at least) can be either
> link colors or semantic (bug status) colors.

Right, but of course linking to a status is pretty meaningless, so
that's not an option.

>>
>>> 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.
>
> It's not a high priority.  If you just changed to showing the date
> that would look less weird and probably be fine.
>
>>> 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.
>
> <crickets>
>
>>> 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.
>
> --
> Martin <http://launchpad.net/~mbp/>
>