202463 - Prefill "Assign To:" with default component owner

Status: RESOLVED FIXED

(Bugzilla :: Creating/Changing Bugs, enhancement)

Description

[Steve Lamm]

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.

Comment 1

[Steve Lamm]

Attachment: Set "Assign To:" with default component owner

Adds an extra SQL join to enter_bug.cgi to get the login name of the default
owner.

Comment 2

[Steve Lamm]

Attachment: Simpler javascript: Set "Assign To:" with default component owner

The javascript in this version is a little more elegant and
handles a couple edge cases I have. My version of enter new bug
does not use the select widget if there is only one component.
In that case, it adds a label (and the new javascript checks for that
case).

Comment 3

[Bradley Baetz (:bbaetz)]

Comment on attachment 121006 [details] [diff] [review]
Simpler javascript: Set "Assign To:" with default component owner

use document.forms['Create'] rather than document.Create, for browser
portability.

+    my ($name, $description, $default_login, $default_realname) =
+	 FetchSQLData();
+    my ($name, $description, $login, $realname) = FetchSQLData();

You're also skipping every second row here...

Comment 4

[Steve Lamm]

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.

Comment 5

[Steve Lamm]

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 6

[Steve Lamm]

Attachment: Set "Assign To:" with default component owner (fix double fetch)

Comment 7

[Bradley Baetz (:bbaetz)]

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.

Comment 8

[Bradley Baetz (: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.

Comment 9

[Dave Miller [:justdave]]

ooh, this is pretty cool looking :)

Comment 10

[Bradley Baetz (:bbaetz)]

Fixed in CVS. Thanks for the patch!

Comment 11

[Gervase Markham [:gerv]]

> 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

Comment 12

[Bradley Baetz (:bbaetz)]

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.

Comment 13

[Gervase Markham [:gerv]]

> 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

Comment 14

[Steve Lamm]

Here is some background of what went into the feature design.

The motivation for the feature came from people asking, "How can I know
the default component owner before I file a bug?" It seems that at Yahoo! 
(where I work :-) ), people are likely to take the default, but they wanted to 
know who they were about to bug. I pointed people to the "Component:" link, but 
it happened enough times that it became clear the link needed help.

My first idea was to only change the link. Our enter bug page has a layout like 
the following:

   Product: Messenger        Version: unspecified
 Component: Chat
 Assign To: 
 ...

In the case it would be easy to add a link to the right of the component field:

 Component: Chat  (Describe Component)

That was a little be better, but I wanted to bring the default owners directly 
onto the enter bug page.

That gave way to a design like the following (never used it on the site):

   Product: Messenger
 Component: Chat
 Assign To: o Default owner: [e-mail]
            x Other:         _______________

Where "Assign To:" has a radio box with a drop down and a text input. The drop 
down would stay sync'd with the selected component. This really spelled 
everything out, but it was clunky.

Then came the javascript solution. I hate popups, so I originally discounted 
the idea. However, without it, it would not be clear how to get a default owner 
after making some changes. With the Y! layout it seemed less likely that 
someone would fill in "Assign To:" and then pick the component.

With the popup the feature will be annoying to users who are used to typing 
in "Assign To:" and then picking the component. Hopefully, it will not be too 
painful for a user to change that order. Without the popup, I user may be left 
stranded wondering how they can get the box to update again. The popup makes 
the feature more explicit. If the popup does prove to be terribly annoying, 
then the whole javascript feature should probably be abandoned. At least give 
it a try.

Comment 15

[Gervase Markham [: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 

Comment 16

[Myk Melez [:myk] [@mykmelez]]

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.

Comment 17

[Gervase Markham [:gerv]]

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

Comment 18

[Steve Lamm]

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?

Comment 19

[Gervase Markham [:gerv]]

No; we use very little JS, so normally all our UI is form widgets.

Gerv

Comment 20

[Gervase Markham [: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

Comment 21

[Steve Lamm]

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.

Comment 22

[Gervase Markham [:gerv]]

> 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

Comment 23

[Gervase Markham [:gerv]]

So, am I going to have to fix this up, then? :-)

Gerv

Comment 24

[Bradley Baetz (:bbaetz)]

I'd still like to wait for bmo to pick this up, and get user feedback.

Comment 25

[Gervase Markham [:gerv]]

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

Comment 26

[Steve Lamm]

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.

Comment 27

[Gervase Markham [:gerv]]

slamm: did you ever fix up that non-dialog version?

Gerv

Comment 28

[Steve Lamm]

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:  | [e-mail]       | |X| Use default component owner
               +-------------------------+ +-+

Select component Bar:
               +-------------------------+
   Component:  |  Foo                    |
               |* Bar *******************|
               +-------------------------+
               +-------------------------+ +-+
   Assign To:  | [e-mail]       | |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 "[e-mail]" shows up again
   * Select Foo, then "[e-mail]" gets filled in and the checkbox
     gets checked

Enter non-default owner:
               +-------------------------+ +-+
   Assign To:  | [e-mail]     | | | 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.)

Comment 29

[Gervase Markham [:gerv]]

slamm: looks good. Let's try it. Can you upload a patch?

Gerv