Can someone update this page to make it clear which parts are comments which helped to shape and mould the newly-deployed look (and are therefore less relevant now it's been shipped), and which parts are post-upgrade comments on that look, as requested by the bmo "new changes" page? Thanks :-) [[User:Gerv|Gerv]] 03:35, 28 December 2006 (PST) ----- mconnor's proposal (which includes changes to the header) is [http://steelgryphon.com/firefox2/bmo/Bugzilla_bug4.html here]. preview of the work in progress is [https://landfill.bugzilla.org/prodpatches/show_bug.cgi?id=415 here]; note that logging in changes the appearance quite a bit. {| style="background: lightgray; border: 1px solid blue"| '''NOTE:''' Changes that don't have working patches by early evening PST Saturday December 23rd will not be included in the upgrade on Tuesday the 26th.|}<br> == Comments after bmo upgrade (or still pending comments) ==
(please include your rationale!)
=== Jesse ===I don't like the overall layout change. The three-column layout currently used at the top of bugs saves space, allowing me to see the CC list and the first few attachments without scrolling. Is there a good reason to switch to an entirely two-column layout?.
=== beltzner ===
* Agree with Jesse, 3 columns allows for more information density on a page and will actually make it easier to visually scan each chunk/grouping
* When no search results are available, just hide that row since it adds no valuable information
=== Peter =Summary of discussion prior to 26-Dec-2006 upgrade ==
(Note: this page was getting huge, and trying to rearrange and reclassify all the comments would have been a huge time sink. Instead, I very much like 've tried to fairly summarize things in a way useful for future discussions.) See the 2 column layout[http://wiki. The old 3-column layout only works when running with the browser window maximized (horizontally)mozilla. I almost never do that and so that caused a lot of very annoying horizontal scollingorg/index. The proposed 2 column layout scales much better in widthphp?title=Bugzilla:Bug_Layout_Revision&oldid=45267 last verbose version] for the complete comment list.)
=== LpSolit ===Now I strongly disagree to have the keywords, URL and status whiteboard fields at the very topThe redesign was largely based on a [http://steelgryphon.com/firefox2/bmo/Bugzilla_bug4.html proposal mockup] from mconnor. Changes were prototyped [https://landfill. This looks wrong to mebugzilla. More important is the block with the assignee + target milestone + severity, and should be moved higher in the pageorg/prodpatches/show_bug. The status and resolution should be combined with this blockcgi?id=415 here].
Links about votes are really === Issues not important and should be moved in the "Action" list (with XML, etc...).resolved by redesign ===
# When no search results are available, just hide that row since it adds no valuable information
# "Format for Printing" should be removed, replaced by appropriate media-specific CSS
## However, note that content of the current printing-formated page differs.
# Combine some fields to a single line. For example, Hardware + OS -> Platform
# Make "URL" an attachment (this is a new BZ feature)
# In the change section at bottom, remove the word "bug" and associated prepositions from "accept bug", "resolve bug ...", etc - it's implied
# Search and search navigation in multiple places seems odd. Try combing to a single line.
# Assignee needs an "(edit)" link
# Only show time estimate to logged in users.
# Some of the field names are links, others are not.
# Attachments should link to the comment describing them.
# The big radio list at the bottom of the page (right above the "Commit" button) really needs to be simplified, or even eliminated. Most of these actions could be some from the controls at the top of the page, with better design.
# The "Depends On" and "Blocks" fields should be clipped if they're really long (with a mechanism to show them all if desired). "Depends on: 99 bugs (2 open, 97 resolved)" seems more useful than a giant block of numbers.
# Bugzilla should lend a hand when you're filling out a field with a name (assigned to, qa contact, flags). "Default" is probably needed as a minimum, although a longer list of people appropriate for the task would be nice.
# The yellow header bar linking to mozilla.org seems completely useless. Maybe make it a footer, or just delete it entirely?
=== Dolske ===
* Status and Resolution have already been combined in the new version (now "Status: RESOLVED INVALID"). It might be worthwhile to combine a few other fields (ie, put them in the same row). For example, Hardware + OS -> Platform (System?). And perhaps Priority + Severity -> ???.
=== Napolj2 Problems/Objections with the redesign ===
I# Various comments about how the fields should be properly arranged. Everyone had their own rationale, so summarizing the ideas here isn'd move Assignee and QA Contact t useful. :-)# 3-column layout better than 2-column (saves space, higher information density, easier to just above the CC listscan each chunk/grouping)## However, as they all fall under the same conceptual category as may look worse if your browser isn't wide.## Have a single "People involved with this bug." Then Iblock# Old header looked better (redesign doesn'd put Priority, Severityt save space, and Target Milestone in consistency with Status/Resolution, Keywords, and Whiteboard, as they fall other Bugzilla pages)# "Preferences" changed to "Settings"# The "magically expanding comment box" is annoying.# Each comment should have more left-padding to move it under the category header# Action block (at bottom of page) now disconnected from the fields it operates on (at top of page)# Some colored regions have curved borders, others do not.# Too much whitespace between field and label.# Is "What state is this bug inView All". The remaining group link on attachments really useful?# Double clicking on my mail address at the bottom of Product, Component, Version, Hardware, the page and OS, describes this category of pasting it into a text field prepends it with "Where this bug occurs.# "
Ideally, URL should just be considered a type of attachment and not a whole separate field (though this would require converting all the existing URL fields for existing bugs into new attachments, and perhaps patching Bugzilla).
When you have a large amount of dependencies/blocking bugs, you can end up with one column being significantly longer that the other, as in [https://bugzilla-test.mozilla.org/show_bug.cgi?id=300030 the reflow refactoring bug]. (Maybe this won't be an issue since b.m.o has lots of flags too). Perhaps you could allow the dependency/block lists to span both columns? This can be done by moving them to a second TR (with colspan=3) within the outer TABLE. === Callek === My only comment is that the individal comments text-itself, could use some more left-padding, to indent it at least a bit more than the headers for each comment, as it is those headers appear to be part of surrounding comments, rather than headers at a brief glancing. (I thought that for brief a moment). == Comments before bmo upgrade, that are solved now ==(please only copy/paste previous comments here. See remark Gerv) === Jesse ===I like the wording changes and "edit" links. Those save space and make the page less cluttered. === beltzner ===* Compress the header as in mconnor's mockup, the repetition of the bug name and number is distracting and confusing* The actions section takes up too much space and is too visually prominent. There doesn't need to be a "format for printing" button, we should just use a sensible print.css file. Clone bug and "XML" are seemingly low value, too. Instead I'd propose something like: Bug 415 - blah blah blah blah (edit) [view activity] [jump to latest comment] (<-- small text) === Ancestor ===The dependency list tries to put as many entries in one line as it can. This becomes a problem when there are plenty of entries, because it pushes the right-hand column too far to the right. [https://landfill.bugzilla.org/prodpatches/show_bug.cgi?id=4728 see here for example]. === LpSolit ===Ancestor, about the dependency lists: it indeed tries to use as much place as possible, but will wrap to avoid the user to scroll horizontally, so this is fine and exactly what we want. If your screen is narrower, it will wrap more often. ''I know that but I feel it would be better to wrap the dependency list earlier so that the columns aren't so far apart from each other with a huge white space between them. - Ancestor'' The goal of including the bug summary in the header of the page is to save some vertical space. Repeating it again in the gray line is a regression. But I can understand you want it here for visibility. Now, links to go to the prev/next/first/last bug are taking too much space and should probably be moved on the same line as other "Action" links, i.e. XML, Format for printing, Last Comment. == Comments unsorted ==(deprecated: please only move comments out of this section to the sections before and after bmo upgrade - see remark Gerv) === Wolf ===Agree with Jesse and Beltzner about the two vs three column layout stuff (and hiding the actions when searching.). Except for the header compression. I find the header appears better when not compressed. (and as far as I can see, there's no space actually being saved by those changes.) I think mirroring the actions line at the top and bottom is useful. Removing the "Bug 415" (page title) portion might work on showbug, but on other pages, I don't think it does, since it provides useful information, which is only shown there. Plus the readdition of that value would likely end up being too wide with all the links on the same line. (See the activity log, etc). Also, why is preferences being changed to settings? Preferences seems to be more correct.I'm not sure print view is served well by being just print.css fixed (as the page says, its a full text bug list, not really just a css change. Agree about XML, not sure what the purpose for it is, not that it bothers me being there, either. Clone Bug might be of value, though, since it didn't work in bmo before. (Just having two links to me, suggests either over pruning, or that that line should be elsewhere.) === LpSolit ===Having the dependency lists on the left and having the CC list always visible is definitely the right approach (especially when you have a very long list of flags). Note on bug 415 that I reassigned the bug to timeless, who has no real name on b.m.o, and now the assignee field is left blank. If the user has no realname, then his email address should be displayed. Nit: please remove the now useless colspan=3 in the right table as the dependency lists have been moved to the left. === Vlad === This is minor, but the attachments table is pretty ugly. At the very least I'd like to see the double-weird-90's-style-3d-borders just become simple 1-pixel line borders. I also think that this page overall does too much "Field name: Value", and places all field names on the same importance as all others, when in reality they're not. This is very noticeable in the header, but also in the attachments table. Here's my take on some ideas for the attachments table: [http://people.mozilla.com/~vladimir/misc/bugz.html here]. The first table just has borders and backgrounds changed, deemphasizing obsolete attachments. The second is what I'd really like to see, because it makes the important information (basically, patch name, type, review flags) much more visible. === Dolske === * Putting page specific info (the bug title) into the top header seems like a unusual design, so the location would seem unexpected. Most sites have a relatively static header that one learns to ignore. === Napolj2 === I'd widen the attachments table to match whatever width the comments are line-wrapped at (or the width of the comment headers), for visual consistency. The bug description and number are in 3 places, including the page TITLE. I Like how MConnor does the header, with no bug-specific information in it. The voting links and first/last/prev/next links should be moved into the Actions bar to save space. Actually, those navigation links are useless to me, since I always open bug links from a search into new tabs. === ardissone (Camino) ===I concur with Jesse and beltzner about the information density benefits of the 3-column layout; specifically, it keeps (or can keep) both the product block ("what product am I in now?") and the assignee/target/prio at the top of the page, instead of having to debate over which of those two blocks are more important (and get second billing in the left column) and which gets buried. Right now I'm not happy with assignee/prio/target being at the bottom of that left column, but burying product there in earlier versions was just as annoying. The other issue I have is that the "action" block is now totally disconnected from the fields it modifies, and this seems problematic--especially on bugs with more than about 5 comments. The assignee/product/resolution data is at the "top" of the page and the buttons that change those data are at the very bottom. (I'm quite fond of the comment text area moving to the bottom, though; no more scrolling up and down the page to refer to the last comment when composing a new one!) === Silver === Two things really bug me with the new page: * The magical expanding comment box. It expands too much here, and doesn't seem to depend on browser window size, making it really, really annoying. (Yes, I know it's an option I can turn off, but it really helps to have things behave sanely by default.)* The Hide Obsolete/Show Obsolete links for the attachment table cause the browser to jump to the top of the table - really annoying. If it is to scroll anywhere, it should scroll by just enough up or down to keep the link (and bottom of the table) in the same place. That's trivial JS, too. === Wayne === There is a lot to like in this makeover which I won't go into except to say kudos to the team, and good comments above. Least controversial (hopefully) aesthetics first: * horizontal rulers IMO add nothing but space and are so 80s - begone forever (shaded text line is a more pleasing and more obvious visual cue) * shaded banner is sufficient to delineate each comment - the extra line at the end of each comment wastes space - begone (the only thing it could help IMO is writing comments on printed pages, which has got to be a rarity)* "additional comments" - shade the line (a natural extension of the progression of the comments above), could also shorten to "add comments"* in the change section at bottom, remove the word "bug" and associated prepositions from "accept bug", "resolve bug ...", etc - it's implied (and, as an example, not used in the text at top section of showbug) In addition: * (speaking for the poor _average_ bugzilla user) whiteboard I would argue when it has something useful is possibly the most important of all the items for communicating to the average reader something to which they need to pay attention (workaround comment #, warnings, don't comment unless, etc) - and therefore should stay in a prominent location or it is too easily missed. Respectfully disagreeing with LpSolit, I would argue at least above keyword.* 2-column vs 3-column - 2 is easier to read and I don't see significant space gains with 3 (this coming from someone who is all about screen real estate)* mconnor's layout below "Bug #" looks cleaner - not saying it's all better, but clean is appealing* "last comment" link doesn't belong on a line with search functions* a collection of actions is appealing but should not take an extra line up top - could "actions" be a drop down selection list next to "edit" on the shaded bug summary line?* votes can perhaps go anywhere - but I submit for the average user it is lost amongst everything up top - it may not be cleaner but somewhere near "commit" makes more sense from a usability standpoint* I very much dislike using two lines at the top, with "settings", logout and all kinds of links, where one line will do and which includes things which will be so infrequently used (unless there is a user pref to only display at bottom) Finally, search and search navigation in multiple places seems odd. After looking at the old layout, i.e. the line with "Bug List:", mconnor's and the current proposal, how about modified version with a single line for all functions related to '''navigating''' bugzilla (not navigating the bug or prefs). For example '''Bug:''' <u>New</u> '''Search:''' ______ Quick <u>Advanced</u> '''Search Results:''' <u>Edit</u> ''<u><< First</u> <u>< Prev</u> m of n <u>Next ></u> <u>Last >></u>'' === biesi ===Comments on https://landfill.bugzilla.org/prodpatches/show_bug.cgi?id=415 * <strike>Severity should move elsewhere, it's a property of the bug, it doesn't change over its lifetime (conceptually)</strike>* if I click the qa contact's "edit" link, the text field appears but the "edit" text doesn't change, even though it hides the textbox when I click it again ({{bug|365128}})* perhaps assignee should get an "edit" link as well, just like qa contact* IMO the time estimate should be shown to not logged-in users as well* <strike>adding a named tag to the currently displayed bug shouldn't require me to type in the bug#</strike> ({{bug|364835}})* IMO the dropdown list for the named tags and the textbox for creating a new tag should be on separate lines ({{bug|365127}}) === Jesse (2) Other mockups ===
==== Jesse ====
I've made a [http://www.squarefree.com/bugzilla-ui/spice-3col.html proposal] that uses a "3 columns at the top, 2 columns in the middle" layout (similar to current BMO layout) but based on the page with improved grouping and "(edit)" links. It saves a significant amount of vertical space, gives more room to the URL and whiteboard fields, and IMO looks pretty good. See [http://www.squarefree.com/bugzilla-ui/changes.html this page] for a list of changes I made.
=== Mats ===
I also prefer a 3-column layout to save vertical space.
The navigation box at the top (with purple background) only needs to be
one line IMO, like mconnor [http://steelgryphon.com/firefox2/bmo/Bugzilla_bug4.html suggested].
The "Target Milestone" should be changed to something shorter -
it makes the horizontal distance between the field names/values
above it too wide which in turn makes the left column unnecessarily
wide as a result.
Some of the field names are links, others are not.
I suggest adding a "title" attribute that describe their meaning
for the non-links (as you did for the individual Flags at [https://bugzilla-test.mozilla.org/show_bug.cgi?id=334136 bugzilla-test.mozilla.org])
and for the links describing what will happen if you click the link.
The summary header ("Bug# - Summary" with grey background) uses border radius,
but other boxes don't, e.g. comment headers (I'd prefer no border radius).
The horizontal distance between "Summary:" and the input to the right is too short. Same for "Alias:".
Attachments:
"Hide/Show Obsolete" should not scroll the page.
"View All" - is this really a useful feature? I have never used it that I can recall.
I don't like the auto-expanding "Additional Comments" when it's clicked (it scrolls
the "Commit" button out of view and I dislike non-standard behaviour for well known form elements in general - POLA).
Make the bigger size static, vertical space isn't that important here I think.
There is also a '''regression''': double clicking on my mail address at the bottom of the page and pasting it into a text field prepends it with "# ".
=== mconnor ===
Having spent some time flipping between the current prodpatches layout and Jesse's mockup, I find I keep skipping over the product/etc block, and the information isn't doesn't seem to scan in order. In the two column layout, skimming one column and then the other gives you all of the information in a relatively prioritized and well-grouped way, but I don't see a sane scanning order in Jesse's mockup that's efficient to me.
It does have a marginal effect on vertical space (one or two lines on my MBP screen), but information density is only useful if that density does not affect readability. Having five short columns instead of two taller ones just doesn't work for me. It feels cluttered and misaligned now, especially at my typical browser window width of 1200 pixels or so.
I will echo the header complaint, but we'd need to modify all of bmo, not just the show bug page, so we may have to fix that as a second pass, but I'll agree that its really not as effective as some feel.
=== Silver (2) ===
Referring to [http://www.squarefree.com/bugzilla-ui/spice-3col.html the 3 column layout]Reply from Silver:
* Less information is available "above the fold" here (it's lost the last modified time and votes).
* In addition to other comments against it, it actually gives me '''less''' space for the keyword/whiteboard/URL fields!
For these reasons, I object to it being used, and much prefer the existing 2 column proposal. ==== Dolske (2) ====
I had a few more ideas on streamlining things, and did a [http://people.mozilla.com/~dolske/bugzilla/ rough mockup] to see how well they work. It needs fine-tuning, ignore any fixable rough edges.
* The outlines and icons of form controls add a *lot* of visual complexity to the page. The mockup replaces almost all the HTML controls with just plain text (but you can reactivate the controls by clicking "edit"). This really improves readability, but the obvious cost is having to click "edit" to update fields is annoying. This needs improved.
** A subset of commonly used control could be active by default, or BZ could be smart about enabling controls based on the bug state (eg, an UNCONFIRMED bug is probably going to have it's state changes, Firefox/General bugs probably need a new component set).
** A single edit link per section/page, or state via flag in the URL/cookie. Mitigates problem somewhat.
** Can CSS styling of the controls make them more muted?
** At the very least, this makes a cleaner page for viewing bugs when you're not logged in (or don't have an account). If you can't edit something, we shouldn't show a control for it.
* The top part of the bug is using CSS3(ish) columns, so you will see 2 or 3 columns depending on how wide the browser is. Or, uhh, 1 column for narrow windows. And browsers that don't support -moz-column-width. There's not much control over where a column starts, so tweaking a design to work with different column counts is tricky (the mockup just happens to look fairly reasonable). Perhaps there are JS/DOM tricks that could help? I consider this a failed experiment as-is.
* The CC list is hidden again (ala mconner's mockup). While some don't like this, it just doesn't seem that much worse than the current design, which only shows 4 names in a scrolling list. Maybe overlaying the list when you hover over the field (like a giant tooltip) would be useful? That would allow you to easily see all the CCs at once. * Some space is saved by combining fields onto the same line. For example, OS + Hardware, Product + Component, etc. Other thoughts: * The big radio list at the bottom of the page (right above the "Commit" button) really needs to be simplified, or even eliminated. Most of these actions could be Combined some from the controls at the top of the page, with better design. * The "Depends On" and "Blocks" fields should be clipped if they're really long (with a mechanism to show them all if desired). "Depends on: 99 bugs (2 open, 97 resolved)" seems more useful than a giant block of numbers. * The linked labels (like Status) shouldn't be overloaded for help. (If they should, why not all of them?). Having a link for help somewhere on the page (header?) would be a good idea. Although "Keywords" probably needs a small link for allowed words (or conversion to a select box). * Bugzilla should lend a hand when you're filling out a field with a name (assigned to, qa contact, flags). "Default" is probably needed as a minimum, although a longer list of people appropriate for the task would be nice. * Is the Hardware field really even useful? It seems like OS alone should suffice, with a comment explaining any particular hardware dependency. * The yellow header bar linking to mozilla.org seems completely useless. Maybe make it a footer, or just delete it entirely? === Jesse (3) === In response to Silver: It's true that at certain resolutions, votes and last-modified have been traded for dependencies in my mockup. But at most resolutions (especially once the header gets fixed), strictly more information is available without scrolling down. I don't know why you're seeing the URL field become smaller in my mockup than in the reference; it's bigger for me. Perhaps you're using a browser other than Firefox trunk and the CSS to stretch the fields isn't working? In response to Dolske: Wow, getting rid of the form element borders seems to help a lot. (Bugzilla 3 already does that for people who are not logged in, btw.) Some CSS could be used to simply hide the borders of inactive form elements: .subtle { border: 1px solid transparent; padding: 1px; } .subtle:hover, .subtle:focus { border: 1px inset black; } This seems to work pretty well for <input type="text"> and <select>. For fields that are next to each other (e.g. product/component), I guess the first part (e.g. product) would need to be plain text that is replaced by a form element when clicked, so it doesn't take up space equal to the length of the longest product name. I like a lot of your other ideas. === ardissone (2) === Regarding the issues with Jesse's mockup: Do any of the projects in bmo use '''Flags:''' that take a requestee? If not, Jesse's mockup potentially has a lot more space available for in that keywords/whiteboard/URL block (give them 2 cols and flags the rightmost). I think '''Last Modified:''' could easily be moved up to the top of the third column with '''Reported:''' (as in mconnor's mockup), thereby moving that info back into a higher-profile location. reed told me that the SWAG table shouldn't be appearing in bmo at all, so you get even more above the fold in Jesse's mockup without it.... === Jomel === While not strictly a layout issue, my most common gripe with the show_bug page is that the list of attachments provides no link whatsoever to the comment accompanying each attachment, which generally explains what exactly the attachment does and how complete it is (comments immediately afterwards are often also relevant). In a popular bug it can take a long time to find these important comments. See [https://bugzilla.mozilla.org/show_bug.cgi?id=248037 bug 248037].
