1037663 - Make custom bug entry forms more discoverable

Status: RESOLVED FIXED

(bugzilla.mozilla.org :: User Interface, defect, P2)

Description

[Stephany Wilkes]

It would be great if the Project Kickoff Form could be placed at the same, highly visible level as a new bug, especially since the Project Kickoff form should be done in lieu of a traditional bug. Today, if people don't have prior knowledge of the Project Kickoff Form, or haven't bookmarked it from previous use, it's not easy to find.

Today the form is here:
https://bugzilla.mozilla.org/form.moz-project-review

Can we add an item to the "New" page in Mozilla called "Mozilla Project Kickoff Form" with text below that says "Use this to begin new Mozilla projects that require legal and/or finance approval"? 

Copied Michelle to see if there are reasons not to do this, or if there is any copy finance might want to change for the "New" page.

Comment 1

[:glob ✱]

as the "new bug" page is used for all users, the list of products/forms visible on it need to be relevant to most users.  while the project kickoff form is highly relevant to your group, it isn't something that we will be adding to the "new" page.

i agree that the custom bug forms are not easy to find (there are 34 custom forms right now); morphing bug to accommodate the broader use-case of increasing the visibility of most (but not all) custom forms.

Comment 2

[Dylan Hardison [:dylan] (he/him)]

Could we accomplish this by (optionally) targeting forms for specific component prefixes? Much like how you can watch components in a given product that match a prefix string? The downside would be added complexity to enter_bug.

Comment 3

[:glob ✱]

(In reply to Dylan William Hardison [:dylan] from comment #2)
> Could we accomplish this by (optionally) targeting forms for specific
> component prefixes?

we already do this at a product level, however this isn't really possible to do at a component level.

the issue is you select the component on enter_bug from a <select> field.  we can't use the onchange event to trigger loading the custom form because retaining any entered data would be complicated (and most likely impossible), the user experience would be very jarring, and it would inhibit browsing the component list to find an suitable component.


one possible solution for this would be to add an additional step after the product is selected which lists the forms available for that product.  this would have to be decided per-product (ie. we shouldn't do this automatically for all products), but it may work out well for legal and marketing.

Comment 4

[Dylan Hardison [:dylan] (he/him)]

Something like:

if $product has components with registered forms, add additional step.
The additional would display a list of components, and if you choose one with a custom form, you get the custom form and otherwise you get normal enter_bug? 

Alternatively, we could just add a link (or drop down) to the top of normal enter_bug that lists alternate forms. Either way it makes them more discoverable -- and it doesn't require that *all* custom forms are registered in this way,

Comment 5

[David Lawrence [:dkl]]

(In reply to Dylan William Hardison [:dylan] from comment #4)
> Something like:
> 
> if $product has components with registered forms, add additional step.
> The additional would display a list of components, and if you choose one
> with a custom form, you get the custom form and otherwise you get normal
> enter_bug? 
> 
> Alternatively, we could just add a link (or drop down) to the top of normal
> enter_bug that lists alternate forms. Either way it makes them more
> discoverable -- and it doesn't require that *all* custom forms are
> registered in this way,

We could simply only redirect to the custom form *if* the component is explicitly specified in the URL such as when you select an entry from the prod/comp search box. We then just keep a mapping of products/component combinations in extensions/BMO/lib/Data.pm like we do for the custom fields.

But I agree that this may not work in all combinations and that eventually we need a page embedded somewhere that lists all of the valid available custom forms and a description on their purpose. Can we embed some special variables in the templates themselves that identify themselves as a custom form, which product they are for, a component, a form name, and a description of the form itself. And then have a drop down or list dynamically generated after looking into each template in the bug/create dir that has a format tag?

dkl

Comment 6

[Dylan Hardison [:dylan] (he/him)]

(In reply to David Lawrence [:dkl] from comment #5)
> We could simply only redirect to the custom form *if* the component is
> explicitly specified in the URL such as when you select an entry from the
> prod/comp search box. We then just keep a mapping of products/component
> combinations in extensions/BMO/lib/Data.pm like we do for the custom fields.

I think that's not much different than having to go do a special URL for the forms, from the user's perspective. 

> But I agree that this may not work in all combinations and that eventually
> we need a page embedded somewhere that lists all of the valid available
> custom forms and a description on their purpose. Can we embed some special
> variables in the templates themselves that identify themselves as a custom
> form, which product they are for, a component, a form name, and a
> description of the form itself. And then have a drop down or list
> dynamically generated after looking into each template in the bug/create dir
> that has a format tag?

Hmm. Template toolkit has a META directive that sets metadata, basically a compile-time SET. So you could do that -- looking at the compiled-but-not-executed templates to build that information.

It would look like [% META form_name = "a form" form_component = "my component" form_description = "description here" %]

We would cache the result of course. Not sure this is better than another table that describes available forms, but it keeps the overhead of adding a form down.

Comment 7

[:glob ✱]

Attachment: screenshot of enter_bug showing custom bug entry forms

Comment 8

[:glob ✱]

Attachment: 1037663_1.patch

- adds a file where we define the custom forms we want to expose on enter_bug
  - forms can be limited by group membership
  - forms can be any url (ie. we can link to other bug trackers)
- adds a page which lists all defined custom forms
- removes obsolete employee-incident form
- removes obsolete airmo presentation form

Comment 9

[David Lawrence [:dkl]]

Comment on attachment 8493186 [details] [diff] [review]
1037663_1.patch

Review of attachment 8493186 [details] [diff] [review]:
-----------------------------------------------------------------

Question: Should we add <a href="page.cgi?id=custom_forms.html">Custom [% terms.bug %] entry forms</a> to the guided entry landing page?

Looks good and works well. r=dkl

::: extensions/BMO/template/en/default/global/choose-product.html.tmpl
@@ +194,4 @@
>     src="extensions/BMO/web/images/guided.png" width="16" height="16" border="0" align="absmiddle"></a>
>    <a id="guided_link" href="enter_bug.cgi?format=guided"
>     >Switch to the [% terms.Bugzilla %] Helper</a>
> +  | <a href="page.cgi?id=custom_forms.html">Custom [% terms.Bug %] entry forms</a>

nit: terms.bug

::: template/en/default/bug/create/create.html.tmpl
@@ +775,4 @@
>     src="extensions/BMO/web/images/guided.png" width="16" height="16" border="0" align="absmiddle"></a>
>    <a id="guided_link" href="enter_bug.cgi?format=guided&amp;product=[% product.name FILTER uri %]"
>     >Switch to the [% terms.Bugzilla %] Helper</a>
> +  | <a href="page.cgi?id=custom_forms.html">Custom [% terms.Bug %] entry forms</a>

nit: terms.bug

Comment 10

[:glob ✱]

To ssh://[e-mail]/webtools/bmo/bugzilla.git
   9773ddf..7a70134  master -> master