Add "Not applicable" selection to Milestone, Version and Platform fields in Trac

[koki]

Milestone, Version and Platform and not applicable to Drupal and/or Trac bug reports. So, for better clarity when entering website related bug reports, please add a "Not applicable" to selection to these fields.

[axeld]

There is already the empty selection for these (which I would prefer personally), only platform is missing such an entry.

[koki]

The empty selection does not mean anything and it's not that obvious either. If the empty entry is meant for "not applicable" bug reports, why not change the label to something that reflects the actual purpose of the selection (i.e., not applicable, none, etc.)? Such more specific label could help avoid wrong selections and the need of admins to change them afterwards.

[umccullough]

From a usability point of view, Jorge's position on this is very common. Users do generally feel better about selecting *something* into a drop down box rather than nothing.

I can't recall how many times I've discussed the concept of "empty = not defined" with our customers (for my company) only to have them insist that "N/A" or "Unknown" was preferable over blank. For a user, this is an indicator that they didn't simply forget to fill in the details, but that they intentionally set it to an appropriate value. It also assures them that they won't have to know this value in order to save a record.

For me personally, I don't care - blank works for me too :)

[axeld]

I don't mind relabeling the empty entry, I just wouldn't like to have extra entries for "N/A".

[koki]

Replying to umccullough:

From a usability point of view, Jorge's position on this is very common. Users do generally feel better about selecting *something* into a drop down box rather than nothing.

It is not good practice (nor is it common AFAIK) to have unlabelled controls in a GUI. Maybe in a drop-down menu an empty selection that is not visible does not strike as awkward at first glance; but move the same functionality to a group of radio buttons (where all selections are exposed), and you will see how visually awkward, unintuitive and potentially confusing it would be have an unlabelled/unspecified selection.

Replying to axeld:

I don't mind relabeling the empty entry, I just wouldn't like to have extra entries for "N/A".

Relabeling the entry (to N/A, None or the like) would work IMHO.

[nielx]

Replying to koki:

Replying to umccullough:

From a usability point of view, Jorge's position on this is very common. Users do generally feel better about selecting *something* into a drop down box rather than nothing.

It is not good practice (nor is it common AFAIK) to have unlabelled controls in a GUI. Maybe in a drop-down menu an empty selection that is not visible does not strike as awkward at first glance; but move the same functionality to a group of radio buttons (where all selections are exposed), and you will see how visually awkward, unintuitive and potentially confusing it would be have an unlabelled/unspecified selection.

Okay, I agree, but I think you're overanalyzing the problem. I think it is actually that people don't care to alter the default values to 'empty' ones.

Replying to axeld:

I don't mind relabeling the empty entry, I just wouldn't like to have extra entries for "N/A".

Relabeling the entry (to N/A, None or the like) would work IMHO.

I will try another approach:

I am going to write a short script that changes the Version, Milestone and Platform field to an empty one, and that disables the fields when the component Website is selected. I think that would most effectively solve the problem. Any thoughts?

[koki]

Replying to nielx:

I will try another approach:

I am going to write a short script that changes the Version, Milestone and Platform field to an empty one, and that disables the fields when the component Website is selected. I think that would most effectively solve the problem. Any thoughts?

That sounds like the ideal solution, but there may be situations where a change/enhancement for the Website subcomponent could be tied to a milestone, such as when preparing the website for a release (as was the case for alpha 1).

Perhaps the script can automatically select "N/A" as the default for the Website components, but not disable the controls in case they need to be overridden?

[nielx]

Replying to koki:

Replying to nielx:

I will try another approach:

I am going to write a short script that changes the Version, Milestone and Platform field to an empty one, and that disables the fields when the component Website is selected. I think that would most effectively solve the problem. Any thoughts?

That sounds like the ideal solution, but there may be situations where a change/enhancement for the Website subcomponent could be tied to a milestone, such as when preparing the website for a release (as was the case for alpha 1).

I agree.

Perhaps the script can automatically select "N/A" as the default for the Website components, but not disable the controls in case they need to be overridden?

Okay, I have a version 1 of the script that can be found at: ​http://hg.haiku-os.org/trac-customizations/rev/0f0b9d549af5

What it does: when the 'Website' component is selected, it will clear the Version, Milestone and Platform fields and it will disable them.

This only applies to the new ticket page (at /newtickets). This enables it for developers that handle the ticket to set them anyway they like (for maximum flexibility). So if they think a version applies, or a milestone they can do so.

This change makes the assumption that these fields are filled in wrongly because the reporter does not take the time to set them to None. That's why I think it is not necessary to add an N/A field.

Opinions?

[nielx]

Deployed. Reopen if there are any issues. Tested on Safari 4.0 and Firefox 3.5 on Mac OS X.

[nielx]

Unfortunately, while the patch does select the empty options, it does not seem to send that to the server. I will need to refine the javascript for it to work.

[nielx]

Fixed in ​revision 9. I removed the code that disables the controls. First of all, if you disable the controls they aren't sent to the server, and then Trac fills in the default values.

I could circumvent that, but I decided to first see how it goes with simply modifying the field values, and then if that proves too ineffective, add that disabling code.