User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4 Show bug looks too complex, is poorly laid out and in some instances is difficult to use. I am looking for ways to simplify the whole editing a bug process and am starting with show_bug. With the upcoming AJAXification, a lot of capabilities could be opened up in show_bug. The following is a list of bugs that have mostly to do with just show_bug: bug 286375 bug 296115 bug 117481 bug 204739 bug 343358 bug 344961 bug 301280 bug 44335 bug 202213 bug 53009 I intend this bug to be some sort of talking point/demo center/tracking bug for the UI changes affecting show_bug in this upcoming version (this should be to show_bug.cgi what Bug 130835 is to index.cgi). Reproducible: Always

Here is a compilation of some ideas. It isn't finished, and I am not sure I like parts of it. What I do like (and would like to point attention to): the tab bar the cc list It looks really aweful in IE; I suggest viewing it in firefox 1.5 at at least 1024x768 full screen (I don't know what other browsers work).

This bug is a dupe, which I'm still looking for. We already have people working on redesigning Bugzilla and bugs already exist.

gandalf, I'm pretty sure this bug is a dupe, but I cannot find it right now. The closest I could find is bug 339877. :) I don't think we need another meta bug about the UI. More specific bugs are much more useful IMO.

first comment, if fields are checked, they shouldn't be that hidden. that bug is in the four security group, but i had to click randomly to discover that. anything it's in *is* important. second. I'm not going to waste my time expanding things just to find out what things are available. if you don't want to waste entire table rows for a list of available flags, that's fine, but at least make a <p> available flags: foo, bar, baz, bleh, yadder, yadda, yad</p> so that I can quickly recognize that there's a flag I might consider setting. Oh, and whatever evil magic is done for this junk. I expect to be able to use user css and preferably server side prefs to control my default view. i.e. if someone feels that the default behavior is to collapse everything, a user should be able to tell bugzilla to default to expanding everything. and this includes the ability of the user to still use the ui afterward to collapse things. as well as being able to click the widgets to show/hide things. -- this will necessitate the class name actually *changing* at least with the first click (so that the user css doesn't permanently force the display to hidden or visible).

Moved some fields around, this is very unfinished still (I think it is beginning to describe where I am going though). For best results 1024xnnn. notes: I am trying to get rid of trapped whitespace (which is actually very difficult when you realize that whole sections can be turned off, and some sections are size dependent on the number of items available). Right now the only thing that is still hidden is the resolution, by a css rule (it only shows up when the bug is marked resolved). I have resized the input box for the moment (and to a strange size too, 63 columns). Just ignore that (the timesheet and attachments are poor too). If you think the tab-bar is good, I could prepare a patch to them sitewide.

Several people are working on the same thing. glob, where is the bug in which you proposed two different approaches of show_bug?

Now I am getting somewhere, I have styled some of it and gotten to the point where I think you can see some of the goals. Some of the goals I feel I've achieved so far include: * most fields fit within a 1024x768 window (click on the edit tab to demonstrate in firefox) * Required field identifier (yellow) * can't change field identifier (red) * sans-serif font * readable obsolete attachment links (need to change bug links and enhancements in buglists) * centered form (the current only takes up the left half of the screen which means I always seem to have my head at a strange angle) Please comment on this so far, I think I am almost ready to begin making it into a template. Before I do so, I will draw up a "view" format. It will be a lot simpler, focused on viewing what the bug is about, instead of what status the bug is in; sort of like kde and gnome bugzillas but slightly more powerful. I would especially appreciate input on styling. Still to do: fix field dimensions translate to ems better down-level browser compatibility (non-gecko browsers, IE 6 is mostly working except for some margins, haven't checked anything else)

(In reply to comment #8) I don't like it. It's still very complicated and flat. You're presenting the user everything in one place, giving him thousands of options at the same time, and using dark background you make the UI even more "bloated". Also, you're putting all the data about the but in on top, while the stuff that users will most often interact with (comments) is at the far bottom of the page. Also, I still don't see any reason to split between edit and view. Bottom line - It's not me who can make such decisions, so don't feel blocked by my opinion, but for me it's a total oposite direction from where I think we should go. Our goal should be to stack things, so the important things are big and visible and accessible in easiest way, while everything that is less usable, rare needed, can require more effort to get it (expand some collapsed widget? or background tab?) or smaller. If you take a look at my approach for search query: http://landfill.mozilla.org/gandui/query.cgi you can get a taste of what I'm talking about.

(In reply to comment #9) > Also, you're putting all the data about the but in on top, while the stuff that > users will most often interact with (comments) is at the far bottom of the > page. > > Also, I still don't see any reason to split between edit and view. This "edit" mode would be more for the people who need to change many aspects of the bug. The view mode would be for the people who just make comments, maybe add a dependency or a blocker or an attachment. For example, in my companys bugzilla, I often find myself changing the Priority, Severity, cc people, a couple group checkboxes, dependancies, blockers and the status of the bug all at the same time. However, our testers tend to add themselves to the cc list, add a comment and put something in the whiteboard. It is important for me to be able to quickly navigate around and change different aspects of the bug (but not so much to read the comments, esp the description, it tends to be easy to remember given the summary). Normally it wouldn't matter to me if the comments even made it on the bug I am working on; I read them in my email. The testers on the other hand absolutly need the comments to be very easy to get to. > > Bottom line - It's not me who can make such decisions, so don't feel blocked by > my opinion, but for me it's a total oposite direction from where I think we > should go. Our goal should be to stack things, so the important things are big > and visible and accessible in easiest way, while everything that is less > usable, rare needed, can require more effort to get it (expand some collapsed > widget? or background tab?) or smaller. Our goal shouldn't be to stack things. It should be to simplify things. In certain cases, simplifying involves stacking (the footer for example), but this isn't necessarily true. > If you take a look at my approach for search query: > http://landfill.mozilla.org/gandui/query.cgi you can get a taste of what I'm > talking about. I hardly feel that simplifies anything. I could just see it now, a new user comes to bmo and starts looking for the bug he wants to report (lets say he is going to report "Bad sorting in describecomponents.cgi" on 2.16). He enters that text in the search field. It doesn't return anything (default search has resolution unmarked and duplicate). So he goes to the next tab and selects bugzilla 2.16 and gets rid of "in describecomponents.cgi". Still nothing. So he goes and reports the new bug only to see it marked immeadiatly as a dupe of bug 148157. How is he supposed to know he needs to change the "attribute" resolution from duplicate to fixed? If it is a rarely needed field, he shouldn't have to change it. No; tabs are the wrong direction for most cases. While I agree that query.cgi needs some reworking, I don't think tabs are the way to go (with that page, or this page).

(In reply to comment #10) > This "edit" mode would be more for the people who need to change many aspects > of the bug. The view mode would be for the people who just make comments, maybe > add a dependency or a blocker or an attachment. Ok. I'm not convinced because I fail to imagine the pros of this, but if you can really come up with two good UI's for those two different tasks, I'll be happy. In most cases I ever met with, splitting edit and view introduces more problems than it solves and all the view UI needs is ability to switch the field into edit form. > I hardly feel that simplifies anything. I could just see it now, a new user > comes to bmo and starts looking for the bug he wants to report (lets say he is > going to report "Bad sorting in describecomponents.cgi" on 2.16). He enters > that text in the search field. It doesn't return anything (default search has > resolution unmarked and duplicate). So he goes to the next tab and selects > bugzilla 2.16 and gets rid of "in describecomponents.cgi". Still nothing. So he > goes and reports the new bug only to see it marked immeadiatly as a dupe of bug > 148157. How is he supposed to know he needs to change the "attribute" > resolution from duplicate to fixed? If it is a rarely needed field, he > shouldn't have to change it. Well. You just gave a rather complex situation as an example to prove that the whole concept is bad. More, this problem can be (and will be of course) easly fixed by providing summary of all selections currently active on the right side of the area. > No; tabs are the wrong direction for most cases. While I agree that query.cgi > needs some reworking, I don't think tabs are the way to go (with that page, or > this page). I'm happy to see other approaches, but you still did not provide any prove why tabs are bad here. We're still getting back to the issue that there's no final decision on who is the target of Bugzilla application. If the ultimate target is an experienced developer navigating the complex tool with 100% of freedom, than I really like your approach. It organizes the current bug edit UI while keeping the current amount of widgets, fields untouched. The only flaw then, from my point of view, is the fact that comments are so far away while they're probably more used than anything else. But if our target are users reporting bugs, than this UI doesn't resolve any of the major problems, keeping Bugzilla UI still way to complex for the users, way to bloated for them and making the barier way to high for most people to even consider touching such huge and complex UI. It also adds a new UE problem, by adding a lot of dark and making the screen look even "heavier".

The point is to make it easy for the users of bugzilla (those who comment). My idea is to simplify it, in this mode, while still retaining much of the abilities. The reason to have 2 views is because there are two different types of users to bugzilla. Certain users would gravitate towards a mode like this, while others would best be suited to a more traditional approach where they have the ability to edit any part of the bug very quickly (the other attachment). I feel this mode should facilitate being able to quickly understand what the bug is about. To put it another way: View mode is about viewing the bug, editing is secondary Edit mode is about editing the bug, viewing is secondary Since the fact is, all that needs to be done to support 2 modes is create the files: edit.html.tmpl edit-edit.html.tmpl (or edit-view.html.tmpl depending on which is default) It shouldn't be a problem to allow both modes.

Okay, I'm morphing this into our general "update show_bug.cgi" bug. It's going to become a meta bug for tracking the various types of enhancements.

Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set the "blocking3.2" flag to "?", and either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2.

We are going to branch for Bugzilla 4.4 next week and this bug is either too invasive to be accepted for 4.4 at this point or shows no recent activity. The target milestone is reset and will be set again *only* when a patch is attached and approved. I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else.