Closed Bug 202463 Opened 17 years ago Closed 17 years ago
Prefill "Assign To:" with default component owner
Prefill "Assign To:" with the default component owner. - Each time someone changes the component, it updates "Assign To:" - If someone changes "Assign To:" then changes the component, then it asks (via confirm()) if they want to change "Assign To:" to the default owner. - With <noscript> it uses the old behavior.
Adds an extra SQL join to enter_bug.cgi to get the login name of the default owner.
Attachment #120889 - Attachment is obsolete: true
Attachment #121006 - Flags: review-
That is what I get for pulling out part of my changes without testing them. I will put together a better patch. I did not know about the form reference portability. Thanks for catching that. I will include that change in my next patch.
My new code is ready and waiting for cvs-mirror.mozilla.org to come back so I can make a patch. I noticed that enter_bug.cgi does not pick a default component. Is that the desired behavior? Here at Yahoo!, every product has a "General" component which gets picked by default. As for the form naming convention, the document.formName style looks like it should be ok. It was in NN 2 and IE 3. Also, it is used several places in bugzilla itself.
Comment on attachment 121436 [details] [diff] [review] Set "Assign To:" with default component owner (fix double fetch) Let me try to get to this this weekend.
Attachment #121436 - Flags: review?(bbaetz)
Comment on attachment 121436 [details] [diff] [review] Set "Assign To:" with default component owner (fix double fetch) OK, this is fine. the text is a bit ugly, since the browser gives you OK/Cancel, not Yes/No. Not sure of a better wording, though. window.confirm is also DOM0, but theres no real equivalent standard replacement, and if it fails everything is still going to work, so r=bbaetz.
Attachment #121436 - Flags: review?(bbaetz) → review+
ooh, this is pretty cool looking :)
Flags: approval? → approval+
Fixed in CVS. Thanks for the patch!
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
> If someone changes "Assign To:" then changes the component, > then it asks (via confirm()) if they want to change "Assign To:" > to the default owner. The first part of this patch (updating the component owner field) is a really good idea, but I can see this part getting irritating really fast. If I've typed in an assignee, and then change the component, I get a popup. I say no. I then change it again, and get another popup, and have to say No again. Why have the popup at all? If they've typed an assignee into the box, we should just accept their decision (and throw an error as normal if that person doesn't have a Bugzilla account.) As mpt so memorably put it, "Popups are the telemarketers of the UI world." We should only have them when we need them, and I don't see the need here. Gerv
Because they may have typed the assignee in, then changed their mind about the bug. Lets leave it in as-is, and see what people say after this goes in on bmo.
> Because they may have typed the assignee in, then changed their mind about the > bug. Then they could clear the field again; the old behaviour (empty field == default assignee) is presumably still present. We could make the JS kick back in if the field was cleared, without too much effort. I would say that the case where someone types in an assignee and then sets the component (and gets an irritating and unnecessary popup) is much, much more likely than the case where they type in an assignee and then decide it's the wrong person, and don't clear the field (which is the obvious thing to do) and then change the component. We should assume that the user knows what they want when they type in that box, and accept their decision. Gerv
I agree with all you've said up to this point: > However, without it, it would not be clear how to get a default owner > after making some changes. For years, people on b.m.o. have understood and seen the phrase "leave blank for default component owner". I don't think it's a big step, in the unlikely event that you type in an owner and then change your mind and actually want the default, to simply blank the field. If you then submit the form, The Right Thing will happen. If you then change the component, you will be pleasantly surprised when the field updates again, which is also The Right Thing. But thinking about it, this whole UI actually has a problem; if you type into the field and change your mind, as above, you don't know who the default component owner is any more unless you re-select the same component (not an intuitive action.) Your combination dropdown/textfield solution was better in this respect - although if we just went for browsers with a good DOM, it would just be some text rather than a dropdown. Gerv
The motivation behind this feature (showing people who will get their bug) is a good one, and pre-filling the assignee field when the user selects a component is a good solution, but Gerv's right; this popup is likely to be more annoying than helpful. We shouldn't be afraid to make a decision for the user in these situations, we should just provide a means for them to change it if they don't like the decision we made. The decision likely to be correct in more situations is obviously to accept the user's custom assignee, since they know better than us who should take the bug. This just leaves us to provide a means for changing this selection. Bugzilla already has at least one such method, although it's not too convenient: the "reassign bug to owner and QA contact of selected component" radio button in the "edit bug" form that appears when you submit a new bug report. Some browsers like Mozilla also have an undo feature for text fields that solves the problem (if it works for changes made by code). Finally, the "leave it blank to get the default" message also works, although it would be nice to get rid of it (the more obvious our fields, and the less explanatory text needed for users to use them properly, the better) and be able to show people the default even after they make a customization without making them delete the custom value first. If other browsers we are targeting also have undo, then that is probably enough; otherwise we need a Bugzilla solution. I don't think the radio buttons solution is so bad. We use something similar on the "create attachment" page, and it works pretty well. Another possibility is to have a "Default" button next to the assignee field that sets the field to the default value and is disabled if no component is selected or the default value is already in the field.
Myk makes a good point; we should accept the user's decision, because they can always change it if they make a mistake. Having a better mechanism for changing the assignee on the main bug page is bug 173341 - moving that text field into the main body of the form - which I do think we should do. If we don't think that the "Undo" feature of browsers is sufficient, then I like Myk's solution of a button marked "Default" to the right of the text box, which you press. This would also work for the main bug page once the assignee field has moved up into the main body of the bug (a UI problem which, up to now, I had no solution to.) You would write the button using document.write() and put the "leave blank" message in <noscript> tags as an alternative. Gerv
I would suggest using something other than a form button to avoid confusion with the submit button. Perhaps a link, a link in brackets, or a link in parenthesis. Does Bugzilla have any standard for that sort of thing?
No; we use very little JS, so normally all our UI is form widgets. Gerv
So, I'd say the plan of action is: - Remove the pop-up and accept the user's choice unconditionally - If JS is available, provide a "Default" button to the right of the assignee text field which resets it to the default owner for the current component - Otherwise, put in the current "leave blank..." text. slamm: would you be willing to implement this change for us? Gerv
How about a checkbox instead of a button? +----------------+ +-+ | slamm@yahoo | |X| Use default +----------------+ +-+ That shows you when you have the default allows you to pick the default later. Hmm, I like this. I like it better than my patch too. The button would be confusing with the submit button. For forms of more than a few elements, the submit buttons should be above and below their other form elements. That way it is easy to find them. A good example is yahoo mail. A number of bugzilla pages could be improved by following this guideline.
> That shows you when you have the default allows you to pick the default later. That sentence makes no sense. :-| > The button would be confusing with the submit button. I don't agree that the only use for buttons on HTML forms is as submit buttons. If this were generally acknowledged to be true, there would be no <button> or <input type="button"> tags. If the button says "Use default" (compare with "Post Bug"), and was greyed out if the default was already in the box, I don't think there would be confusion. Gerv
So, am I going to have to fix this up, then? :-) Gerv
I'd still like to wait for bmo to pick this up, and get user feedback.
On the basis that we might see a first in UI history - a large group of users saying "Wow! This popup's great! We want more!"? ;-) What's most likely is that they'll sigh, go "Duh, what a dumb bit of software", but not bother to complain. In my view, the thing we want to get feedback on is the UI most consistent with UI design principles. If people then complain, we should reconsider. We shouldn't throw out an inferior UI and see how many people it annoys. Gerv
I have a non-dialog based version that I am trying out. If I get some time in the next few days, I will put up a new patch.
slamm: did you ever fix up that non-dialog version? Gerv
I have a non-dialog version that I plan to use. In comment #21, I botched a description of it, so here is another attempt. When "Enter New Bug" loads: +-------------------------+ Component: | Foo | | Bar | +-------------------------+ +-------------------------+ +-+ Assign To: | | | | Use default component owner +-------------------------+ +-+ Select component Foo: +-------------------------+ Component: |* Foo *******************| | Bar | +-------------------------+ +-------------------------+ +-+ Assign To: | firstname.lastname@example.org | |X| Use default component owner +-------------------------+ +-+ Select component Bar: +-------------------------+ Component: | Foo | |* Bar *******************| +-------------------------+ +-------------------------+ +-+ Assign To: | email@example.com | |X| Use default component owner +-------------------------+ +-+ Uncheck "Use default component owner": +-------------------------+ Component: | Foo | |* Bar *******************| +-------------------------+ +-------------------------+ +-+ Assign To: | | | | Use default component owner +-------------------------+ +-+ * Clears text From here, * Recheck the checkbox, then "firstname.lastname@example.org" shows up again * Select Foo, then "email@example.com" gets filled in and the checkbox gets checked Enter non-default owner: +-------------------------+ +-+ Assign To: | firstname.lastname@example.org | | | Use default component owner +-------------------------+ +-+ * Checkbox gets unchecked * Switching components does not change the text or the checkbox. (Caveat: If you pick a component where the person you entered is the default owner, then the checkbox gets checked again.)
slamm: looks good. Let's try it. Can you upload a patch? Gerv
You need to log in before you can comment on or make changes to this bug.