-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin Albisetti wrote on 20/10/09 20:57: >... > 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.
Nothing wrong with that. :-) As long as any new design is obviously better, and you introduce it all at once to minimize disruption. It's not clear that any of the problems you list require radical changes to solve, though -- they could all be fixed incrementally. Maybe this would be more obvious with a wireframe or two. >... > - 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. It doesn't really matter where the bug originated -- what matters is what software it actually affects. As for upstream fixing it first, the Papercuts project is a pretty big counterexample to that. There is a bit of history here, though, which could inspire some simplification. The "Won't Fix" status was originally intended to be "Won't Fix Here", where a bug does affect a project/package but really does need to be fixed elsewhere. (For example, a bug in a library that could theoretically be worked around by an application using the library, but in practice the library should just be fixed.) But people never used it that way; even Launchpad developers now use "Won't Fix" merely as a euphemism for the harsher-sounding "Rejected". Therefore, there is no point in "Won't Fix" and "Rejected" coexisting; they should be merged. >... > - "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. Absolutely. <http://launchpad.net/bugs/1334> > - Descriptions should be more prominent. They describe the bug, they > should be more visible. It would help if the description used the same font size as normal Launchpad text. And I think getting rid of the "Bug Description" heading would help here, too, because it's crowding the space under the Affects table. > - 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. In addition to what Aaron said, I'm often now seeing the trunk branch for a project linked to a bug report. I don't know why it's happening, but I'm not sure it's useful to someone reading the bug report. > - 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. It's too long for what? People do, and should, behave differently when commenting on a bug report that has 200 subscribers than on one that has three subscribers. And listing every subscriber is probably the most effective way of communicating that -- more visually obvious than, for example, just giving a count. (You don't actually need to know the exact number, you just need a sense of the audience size.) Another case to consider is: I'm talking about a bug with someone, and they ask me to check that they're subscribed to the bug report. With the current design, I can do this with the browser's Find command. If the subscriber list is displacing other information (e.g. the list of linked blueprints), I suggest moving that information into the main content area. > Maybe you don't need to > show my name on there if there's already an unsubscribe button? That might be a bit non-obvious. > - 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. Yes! And filetype icons for the others. > - You should be able to specify that a new tag is an official one, if > you have permissions on the project. With some careful design, I think the whole "official tags" bureaucracy could be abolished. > - Tell me how much the bug affects users. Show me the number, show be > a flame, but show me something. This could be merged with the subscriber list somehow. > - Maybe h1's should be a bit smaller in general, so we don't have so > many titles that wrap? Relatedly, it's awkward to have the Edit button for a bug summary to be in a different place depending on the length of that summary and on the width of the browser window. I wonder if the visual style for a bug description's Edit button could be beautified and generalized to other often-wide text. > - Being on a roll here, how about highlighting the reporters' comments? > His comments will most likely be very important. Yep. <http://launchpad.net/bugs/58670> > > 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. Yes. <https://dev.launchpad.net/BugHistory> > 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 Maybe this can be solved with consistent CSS for all things that have edit buttons. > 3) Add more whitespace between the links below the table and the > description and whitespace between tags and related branches >... As above, I think just nuking the "Bug Description" heading -- and leaving the placement of everything otherwise the same -- would work. Cheers - -- Matthew Paul Thomas http://mpt.net.nz/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrgYE0ACgkQ6PUxNfU6ecq/kQCg1Bhf2f1SAWAYx1koM8VCbXJA 17IAoKKfLdSaJLihAo8XG/FjYoAPnZIl =LkUA -----END PGP SIGNATURE----- _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
