Bugzilla, YUI, and other things.

Saturday, February 27, 2010

A new layout for the Attachments page

There were some comments today about the attachments page and how wonky it is. Bug 101770 has become the place where I've decided to post a response and possible solution to the problem but since I'm sure folks don't want to bother going to the bug here are the images that I posted. Let me know what you think. My hope is that we'll be able to implement this new UI quickly and make a big improvement without making anyone too upset about losing the current Attachments UI.

Things to note. The comments box and the attachment iframe would be elastic so they would grow with the width of the page. Clicking edit attachment as comment would cause the comment box to go away and the big area would turn into a comment.

My hope for this layout is to 1 give more realestate to the comment box that is equal to the area on the current bug page as well as make it easier for people editing the patches directly to have more room.

This UI also puts the focus where it belongs, on the attachment itself.

Things to note. I'm not at all happy with the placement of the patch and obsolete checkboxes. Any suggestions on where those should go is greatly appreciated.


  1. Looks great!

    You could put the checkboxes above the flags. Remember there's also a private checkbox.

    I take it that the edit box for the summary also displays the mime-type edit box?

    Make sure that the comment box isn't *too* elastic--we want it to have a reasonable minimum size, and its size is more important than the size of the Flags column. Ideally the comment box should be at least 80 characters wide.

    When a patch can't be displayed in the UI, I imagine the iframe simply won't appear, and there will just be a little message there?

    Calling the link (edit) on the summary might be a little confusing, no? People might think it was a link to edit the attachment.


  2. I never understood why you can add an attachment inline when filing a bug, but for an existing bug you have to go to a separate page. I much prefer the former. I've lost count of the number of times I've typed a comment into the normal comment box and then realised that I should have gone to the "add attachment" page first, thus necessitating that I cut and paste the comment across.

  3. > I never understood why you can add an attachment inline when filing a bug, but for an existing bug you have to go to a separate page.

    Originally you couldn't add attachments inline when filing a bug, that's a feature we added only in relatively recent versions of Bugzilla. Unfortunately, Bugzilla's original design is that attachments were added on a separate page. Adding them on the show_bug.cgi page is currently technologically a lot harder than simply fixing up the attachment UI.


  4. I wonder whether there might be a way to avoid having to have the two large boxes (attachment display and comment) on screen at once? Fitting those together seems to be the difficult trick about designing this UI.

    How about a three-tab design:

    View | Edit Attachment As Comment | Comment

    The first (the default) shows the patch in an iframe, the second in a text box (as now) and the third just gives you an empty text box.

    The only use case this prevents is the one of someone wanting to write a comment _about_ the patch, with reference to it, but without it being inline comments on the patch itself. is that common?

    If so, perhaps the "Comment" tab could be one above the other, each using half the space?


  5. @Gerv well the big use case i can think of is someone looking at an image or something other than a patch and wanting to comment on it which at least from the designer perspective one would hope people would do that a lot.

    I think the big problem is this:
    1. view of the patch/image is currently a 2nd class citizen and off the screen by fields
    2. Comment is 2nd class citizen because it is so absurdly small.

    This layout attempts to fix both of those issues.

  6. I think the flags belong on the left.

    I'm tempted to suggest taking the existing layout, shrinking the height of the iframe, and placing the comments underneath (comments box probably 80 characters but the iframe stretching if there is space.)

    Then when editing as comment, the iframe and comments merge into a single big textbox which resembles the existing edit as comment view but with a minimum 80 character width.

  7. This is obviously better. The key content is the patch, the flags and such are subservient and shouldn't be as important. The only modification I'd make is associating the actions closer with the object (the patch) instead of placing them all the way at the bottom.

  8. Not that I disagree with the many clever tweaks suggested here, but I just want to say that overall I love the new design. :) Thanks for working on this.