On Tue, Oct 20, 2009 at 8:57 PM, Martin Albisetti <[email protected]> wrote: > Hello Launchpaderos and Launchpaderas, > > I've been thinking about the bug page. I've had a few attempts at creating > wireframes of what it could look like, but no matter how much I try, I > always get taken down a path that requires radical changes. Considering this > is the most used page in Launchpad, radical changes need to be made sensibly > and ensure that they are verifiable better. >
+1 > So, I will start working on different layouts while I discuss it with > different people and through the list, and we can slowly produce something > that works well for everybody. > > Problems I'm trying to solve: > Let me stop you here. Why are you trying to solve these problems? Do we have results from user testing? Do we have a cluster of bug reports that are all about UI on the bug page? That is, what are the inputs? Also, although there's a lot of good in thinking about the problems, I'd also like to have some idea of the constraints that a new bug page must satisfy. That way, others can go off and experiment. Set-based design ftw! > - Show the relationship between bugtasks better. Where did the bug > originate? Where was it fixed? What is it blocked on? In general, if a bug > has a bugtask on a package and on upstream, it's pretty safe to say that it > depends on upstream fixing it first. If it was first reported in the > package, we have origin. > Aaron made a good point about this. > Some of this may require data model changes, some of them don't. Lets > explore what we want to do first. > I very strongly agree with this approach. > - "Also affects..." is a mess. You can create another bugtask with 3 > different options (Also affects project, Also affects distribution and > Target to release). Target to release doesn't do what most people expect, > because it targets it to a series. A release comes from a milestone. > We need to improve the flow there, maybe collapse the "Also affects..." into > one picker that selects packages or products. > > - Descriptions should be more prominent. They describe the bug, they should > be more visible. > > - Related branches is too vague. If there's a branch linked to a bug, what > you're really saying is "this probably fixes it". We probably want to show > if there are any merge proposals attached to that branch, when it was last > updated, and maybe even let you subscribe to it from the bug. > This is a problem in the model, not in the UI. > - The subscribers portlet is too long. We have a mockup from a previous > sprint on a way to fix that, collapsing all the sections, giving you the > description on why they are subscribed in a tooltip and cutting it off after > a number of subscribers. Maybe you don't need to show my name on there if > there's already an unsubscribe button? > > - Adding attachments workflow needs to be finished off. Ajaxified, show them > in a better way than squished in small a box on the bottom right, attached > patches should be shown in the same place as linked branches, and images, in > a perfect world, should show a thumbnail. > > - You should be able to specify that a new tag is an official one, if you > have permissions on the project. > > - Tell me how much the bug affects users. Show me the number, show be a > flame, but show me something. > > - Maybe h1's should be a bit smaller in general, so we don't have so many > titles that wrap? > > - Being on a roll here, how about highlighting the reporters' comments? His > comments will most likely be very important. > I think you only want to do this subtly. If anything, I think you want to highlight comments from developers. Possible ways of calculating "developer" includes: - driver of a project - lots of karma in that project - commit rights to trunk - "standing" Hmm. We could do a lot better at being social, couldn't we? > > Phew, having gotten all of that out of my head, here's what I think we > should do for the immediate future: > > 1) Collapse activity information and comments like we do for emails. It's > way too noisy today. > > 2) Tweak the bugtask table so the status and importance don't use so much > width of it unnecessarily, add between all edit buttons and it's > object > > 3) Add more whitespace between the links below the table and the description > and whitespace between tags and related branches > > > > Apologies for the long email, and the people who got to the end, you are now > my friends. > ¡Mi amigo! Seriously, thanks for getting this rolling. jml _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
