Closed Bug 1050224 Opened 10 years ago Closed 8 years ago

Improve guided bug entry form to filter out web devs specifically

Categories

(bugzilla.mozilla.org :: Extensions, defect, P2)

Product:
bugzilla.mozilla.org
Component:
Extensions
Version:
Production
Platform:
x86
macOS
Type:
defect

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: Gijs, Assigned: dylan)

References

Details

Attachments

(1 file, 2 obsolete files)

1050224_5.patch
18.92 KB, patch
Details | Diff | Splinter Review
Blocks: 1050226
(In reply to :Gijs Kruitbosch from comment #0)
> I think we need UX input on what would be best here (which might not be
> either of these options). I don't know if we have UX people who focus on
> bugzilla - Glob?

bram - do you have time to provide some input?


perhaps the best way forward is for me to throw together a prototype of the changes onto our development site, and iterate over the design.
Flags: needinfo?(glob) → needinfo?(bram)
Assignee: nobody → glob
adjusting the "description" here to clarify the distinction with 1050226.


(In reply to :Gijs Kruitbosch from comment #0)
> From my m.t.bmo post:
> 
> ----------------
> Concretely, after the "Which product" question, we should add a page that
> prompts people if they are web developers / work on the web. I think the
> small box at the top of
> https://bugzilla.mozilla.org/enter_bug.cgi?format=guided should be replaced
> with one that simply says "I need help", with the remainder being sorted out
> *after* picking a product. 
> ----------------
> 
> Zack Weinberg suggested:
> 
> ----------------
> In fact, I think we might
> want to offer a different bug flow for web developers *before* they
> even get to the "product?" question.  (Looking at ?format=guided right
> now, I think what I'm saying is the box at the top with specific
> prompts should be bigger, maybe even the only thing you see unless you
> click "none of the above", and the "Report an issue with Firefox on a
> site that I've developed" sentence should be shorter and more
> obviously the right thing to click if you are a web developer.)
> ----------------
I wrote a detailed suggestion for improving the first ?format=guided screen in bug 1050232.
Blocks: 1080933
Assignee: glob → dylan
Flags: needinfo?(bram)
Status: NEW → ASSIGNED
Priority: -- → P2
Attached patch 1050224_1.patch (obsolete) — — Splinter Review 
Here's the patch I'll be putting on dev to get user feedback on.
Attached patch 1050224_2.patch (obsolete) — — Splinter Review 
And here's the one without a strange error from TRAMP...
Attachment #8606380 - Attachment is obsolete: true
Making the webdev-mode accessible is the current focus of this bug, which also has evolved into changing the so-called "exit text" at the top of the page. 

This change is up on bugzilla-dev, and feedback would be really great. Are there more specific people I should needinfo?

https://bugzilla-dev.allizom.org/enter_bug.cgi?format=guided
Flags: needinfo?(gijskruitbosch+bugs)
(In reply to Dylan William Hardison [:dylan] from comment #6)
> Making the webdev-mode accessible is the current focus of this bug, which
> also has evolved into changing the so-called "exit text" at the top of the
> page. 
> 
> This change is up on bugzilla-dev, and feedback would be really great. Are
> there more specific people I should needinfo?
> 
> https://bugzilla-dev.allizom.org/enter_bug.cgi?format=guided

Maybe mhoye is interested.

This looks nice! Some notes:

* Finding dupes seems to time out or something. My test summaries were: "The JS debugger does not set breakpoints in XBL files correctly" and "Yet another issue with flexbox that dholbert can probably fix in his sleep". Maybe that's just to do with the server bugzilla-dev runs on?

* At least for the developer tools and core css/html/etc. case, there seems to be no clear call to action to provide a testcase (either as a link or as an attachment). Doing so would be really useful.

* It might be good to let developer tools reporters pick the component where they want to file the bug within Developer Tools? There are a number of components for the separate tools. Also needinfo'ing pbrosset in case he has feedback.

* The more I look at this, the more I think it might make sense to do what Zack's (quoted) suggestion in comment #2 says, and to hide the bottom section (product picker) behind a "none of the above" option.
Flags: needinfo?(pbrosset)
Flags: needinfo?(mhoye)
Flags: needinfo?(gijskruitbosch+bugs)
(In reply to :Gijs Kruitbosch from comment #7)
> * Finding dupes seems to time out or something. My test summaries were: "The
> JS debugger does not set breakpoints in XBL files correctly" and "Yet
> another issue with flexbox that dholbert can probably fix in his sleep".
> Maybe that's just to do with the server bugzilla-dev runs on?

yes, it's a slow database.

> * The more I look at this, the more I think it might make sense to do what
> Zack's (quoted) suggestion in comment #2 says, and to hide the bottom
> section (product picker) behind a "none of the above" option.

that makes sense for web developers, however you're looking at the default page for all users who want to report firefox bugs.
hiding the product list behind a "none of the above" option for most users would result in a worse experience.

> In fact, I think we might want to offer a different bug flow for web developers *before* they
> even get to the "product?" question.  (Looking at ?format=guided right

the landing page for webdevs is https://bugzilla-dev.allizom.org/enter_bug.cgi?format=guided&webdev=1
(In reply to Byron Jones ‹:glob› from comment #8)
> (In reply to :Gijs Kruitbosch from comment #7)
> > * The more I look at this, the more I think it might make sense to do what
> > Zack's (quoted) suggestion in comment #2 says, and to hide the bottom
> > section (product picker) behind a "none of the above" option.
> 
> that makes sense for web developers, however you're looking at the default
> page for all users who want to report firefox bugs.
> hiding the product list behind a "none of the above" option for most users
> would result in a worse experience.

I mean, I don't use format=guided, and don't know anybody who does. I think a significant number of the people who currently file bugs through it would be better served by SUMO. I don't think clicking "none of the above" is a significant hurdle for people who really actually need/want to file a bug rather than "make my Firefox work again", but I defer to people actively working on contribution/triage, which would be mhoye. :-)
(In reply to :Gijs Kruitbosch from comment #9)
> I mean, I don't use format=guided, and don't know anybody who does.

it's the default bug creation experience of users who don't have editbugs rights (ie. almost all our users).
(In reply to Byron Jones ‹:glob› from comment #10)
> (In reply to :Gijs Kruitbosch from comment #9)
> > I mean, I don't use format=guided, and don't know anybody who does.
> 
> it's the default bug creation experience of users who don't have editbugs
> rights (ie. almost all our users).

Right, and I know that, and I think a significant number (not a majority, but still probably anywhere between 10 and 30% of them) would be better off being shown SUMO than the rest of the guided bug flow. :-)
Would it be better if we remembered (in a cookie or per-user or whatever) that you'd clicked "none of the above" and showed them to you by default for the next bug you filed? And/or if we didn't show it for canconfirm users? (not sure how many of those we have...)
(In reply to :Gijs Kruitbosch from comment #7)
> * It might be good to let developer tools reporters pick the component where
> they want to file the bug within Developer Tools? There are a number of
> components for the separate tools. Also needinfo'ing pbrosset in case he has
> feedback.
Test with https://bugzilla-dev.allizom.org/enter_bug.cgi?format=guided&webdev=1
Looks cool!
I agree with Gijs that when choosing the devtools category, the component should probably be shown and pre-filled with "Developer Tools". Making this a drop-down with all the sub-components we have would even be better indeed. We do have almost a 1 to 1 mapping between the tools (the tabs in devtools) and the components, so letting people choose the right one could help.
Flags: needinfo?(pbrosset)
(In reply to :Gijs Kruitbosch from comment #11)
> Right, and I know that, and I think a significant number (not a majority,
> but still probably anywhere between 10 and 30% of them) would be better off
> being shown SUMO than the rest of the guided bug flow. :-)

to word that differently, i agree that the majority of users are better served by the current workflow :)

perhaps a solution is to change the 3 top items into 3 boxes that are the same size as the product boxes.  that will draw more attention to those options, and give us some more real estate to better describe them.
(In reply to Byron Jones ‹:glob› from comment #14)
> (In reply to :Gijs Kruitbosch from comment #11)
> > Right, and I know that, and I think a significant number (not a majority,
> > but still probably anywhere between 10 and 30% of them) would be better off
> > being shown SUMO than the rest of the guided bug flow. :-)
> 
> to word that differently, i agree that the majority of users are better
> served by the current workflow :)
> 
> perhaps a solution is to change the 3 top items into 3 boxes that are the
> same size as the product boxes.  that will draw more attention to those
> options, and give us some more real estate to better describe them.

This sounds like a good idea, yes.

However, playing devil's advocate to myself, if that ends up meaning we push the rest of the page below the fold that might be more hostile to users that want those parts than a click-through... I defer to you and/or UX folks in making a decision to do nothing / pursue any of the suggested things. :-)
(In reply to Byron Jones ‹:glob› from comment #14)
> (In reply to :Gijs Kruitbosch from comment #11)
> > Right, and I know that, and I think a significant number (not a majority,
> > but still probably anywhere between 10 and 30% of them) would be better off
> > being shown SUMO than the rest of the guided bug flow. :-)
> 
> to word that differently, i agree that the majority of users are better
> served by the current workflow :)
> 
> perhaps a solution is to change the 3 top items into 3 boxes that are the
> same size as the product boxes.  that will draw more attention to those
> options, and give us some more real estate to better describe them.

I think we can use some of the horizontal space to make the exit box *shorter*, using two columns instead of one. Maybe a few smaller boxes?
Thanks for the call, Gijs.

There's a lot to unpack here; I think we're conflating three or four problems into one form that will not serve any of them that well. I see three different questions here:

- Can we change the bug-intake process so it produces bugs more likely to get resolved? We're using "can we make it land in the right component" as a weak proxy for this, but it means a bunch of other things like "does this have a reproducible test case or a regression range", "does it have a specific version/device/whatever", and a handful of other things. 

- Can we direct users with problems to the place most likely to help them fix those problems and keep using Firefox? This discussion seems to be about noise-reduction in Bugzilla, not about what are maybe more important questions about how people with this class of problem end up on this page, and how we can make them happy to be a part of our user base and community, and maybe if we're really lucky how we can convince them to be more involved.

- Can we distinguish webdev/webcompat bugs from non-developer issues, to appropriately fast-track those issues to devtools, webcompat or maybe accessibility or standards advocacy?

I don't think that we can deal with all of those at once in a way that's elegant and helpful.

Let me put this idea to you: right up front we start out by owning our worst problems outright.

"How can we help?" 

[ Firefox is slow or crashes - click here for a solution ]  <-- take people directly to https://support.mozilla.org/en-US/kb/refresh-firefox-reset-add-ons-and-settings. 
[ I have a question about a Firefox feature ] <-- Take people to https://support.mozilla.org/  
[ I have a suggestion for a change in Firefox ] <-- input.mozilla org. 
[ I need to file a bug in one of Mozilla's products ] <-- reveal the stuff under "None of the above; my bug is in" to let people pick their category.

And we add "I have a web development problem" to _that_ list - I would ditch Thunderbird as a tier-1 menu item in favor of FxDevEd, as much as I love them, but I'd offer them a Thunderbird-specific landing page as an olive branch - which then takes you to https://bugzilla-dev.allizom.org/enter_bug.cgi?format=guided&webdev=1 

(I'd include "I see a third-party webpage that doesn't work with Firefox" as a fourth option there, and have that go over to webcompat.)

BUT: 

Let me also put the idea to you that "file a bug" should also menu item in Firefox Developer Edition directly under Tools -> Web Developer, that takes you to that page directly, and that this would be a much more effective filter than adding it to a page already intended for the larger community. I think that's a different bug than this one, but one worth pursuing.

AND:

It would be neat to know how many bugs from from people googling "Firefox bug" and ending up in Bugzilla, when they should have gone to Sumo or the help menus. Is there a way for us to get some google juice added to Sumo, such that they appear as the tier-1 result for "firefox+bug" instead of bmo?
Flags: needinfo?(mhoye)
(In reply to Mike Hoye [:mhoye] from comment #17)
> Thanks for the call, Gijs.
> 
> There's a lot to unpack here; I think we're conflating three or four
> problems into one form that will not serve any of them that well. I see
> three different questions here:
> 
> - Can we change the bug-intake process so it produces bugs more likely to
> get resolved? We're using "can we make it land in the right component" as a
> weak proxy for this, but it means a bunch of other things like "does this
> have a reproducible test case or a regression range", "does it have a
> specific version/device/whatever", and a handful of other things. 
> 
> - Can we direct users with problems to the place most likely to help them
> fix those problems and keep using Firefox? This discussion seems to be about
> noise-reduction in Bugzilla, not about what are maybe more important
> questions about how people with this class of problem end up on this page,
> and how we can make them happy to be a part of our user base and community,
> and maybe if we're really lucky how we can convince them to be more involved.
> 
> - Can we distinguish webdev/webcompat bugs from non-developer issues, to
> appropriately fast-track those issues to devtools, webcompat or maybe
> accessibility or standards advocacy?
> 
> I don't think that we can deal with all of those at once in a way that's
> elegant and helpful.
Indeed. There is also the issue that BMO is used to track bugs in products marginally related or unrelated to Firefox and Gecko. In an ideal world I would be able to identify if someone was reporting a firefox bug or something more general without having to ask them. Different funnels for products would be really helpful, although this would run into the same problem of SUMO: People end up on enter bug first. 
I do think considerations about bug noise are important, but I think the experience of filing a bug should be painless.

> Let me put this idea to you: right up front we start out by owning our worst
> problems outright.
> 
> "How can we help?" 
> 
> [ Firefox is slow or crashes - click here for a solution ]  <-- take people
> directly to
> https://support.mozilla.org/en-US/kb/refresh-firefox-reset-add-ons-and-
> settings. 
> [ I have a question about a Firefox feature ] <-- Take people to
> https://support.mozilla.org/  
> [ I have a suggestion for a change in Firefox ] <-- input.mozilla org. 
> [ I need to file a bug in one of Mozilla's products ] <-- reveal the stuff
> under "None of the above; my bug is in" to let people pick their category.
> 
> And we add "I have a web development problem" to _that_ list - I would ditch
> Thunderbird as a tier-1 menu item in favor of FxDevEd, as much as I love
> them, but I'd offer them a Thunderbird-specific landing page as an olive
> branch - which then takes you to
> https://bugzilla-dev.allizom.org/enter_bug.cgi?format=guided&webdev=1 
> 
> (I'd include "I see a third-party webpage that doesn't work with Firefox" as
> a fourth option there, and have that go over to webcompat.)

This makes me think: Ditch the top exit buttons entirely, and add those question/actions to a second screen revealed when the user clicks on "Firefox" or "Firefox OS" buttons. Also replacing Thunderbird with Firefox Dev Edition seems like a really natural way to have people file webdev bugs.

> BUT: 
> 
> Let me also put the idea to you that "file a bug" should also menu item in
> Firefox Developer Edition directly under Tools -> Web Developer, that takes
> you to that page directly, and that this would be a much more effective
> filter than adding it to a page already intended for the larger community. I
> think that's a different bug than this one, but one worth pursuing.

+1 this idea. This should happen. We could perhaps add a url rewrite to make the URL simpler / more direct: https://bugzilla.mozilla.org/newbug-developer or something. 

> AND:
> 
> It would be neat to know how many bugs from from people googling "Firefox
> bug" and ending up in Bugzilla, when they should have gone to Sumo or the
> help menus. Is there a way for us to get some google juice added to Sumo,
> such that they appear as the tier-1 result for "firefox+bug" instead of bmo?

I would be interested in this too. I haven't ever gone through SUMO -- does it ever lead back to BMO? Would it be worthwhile if a user *came* from SUMO to omit links /back/ to SUMO? I think if I was a user with a problem I would be incredibly annoyed at being sent back and forth.
I have made two (experimental) changes visible on bugzilla-dev:

1) Your wording links to SUMO and input.mozilla.org (IMO?) is now displayed for the "Firefox" button.
2) Exit links are not displayed on the bare enter_bug page.

I've held off replacing Thunderbird with Firefox Dev Edition, but I could make that change -- or even add another row of product icons with the space savings from #2.

Now, it's possible this change is an evolutionary dead end, but I think it is hard to judge without seeing it in the "flesh".

I know that some want the exits to *replace* the product icons, but that change is unacceptable among the bmo dev team. What we can do now is direct users directly to the firefox flow:

https://bugzilla-dev.allizom.org/enter_bug.cgi?format=guided#h=firefox|

As an aside, https://bugzilla-dev.allizom.org/enter_bug.cgi?format=guided seems more approachable to me.
(of course, I am as far from the typical user.)

After some poking out this, I would like to contrast it to the change proposed by :glob in comment #14 --though I don't like the idea of pushing things farther down the screen.
(In reply to Dylan William Hardison [:dylan] from comment #19)
> I have made two (experimental) changes visible on bugzilla-dev:
> [..]
> https://bugzilla-dev.allizom.org/enter_bug.cgi?format=guided seems more approachable to me.

i like this.  there's quite a few things to fix up (eg. sumo and input applies to more than just firefox) but i think this is a step in the right direction.

> I've held off replacing Thunderbird with Firefox Dev Edition

+1 i don't think that change is necessary.
(In reply to Dylan William Hardison [:dylan] from comment #19)
> I have made two (experimental) changes visible on bugzilla-dev:
> [...]
> https://bugzilla-dev.allizom.org/enter_bug.cgi?format=guided#h=firefox|
> 
> As an aside, https://bugzilla-dev.allizom.org/enter_bug.cgi?format=guided
> seems more approachable to me.
> (of course, I am as far from the typical user.)

This looks great, and, I agree (including the caveat). Mike?


Regarding having a devedition/devtools "file a bug" button/menu entry, I swear there's a bug for this already, but I couldn't find it... but yes, that should be a different bug.
Flags: needinfo?(mhoye)
(In reply to :Gijs Kruitbosch from comment #21)
> (In reply to Dylan William Hardison [:dylan] from comment #19)
> > I have made two (experimental) changes visible on bugzilla-dev:
> > [...]
> > https://bugzilla-dev.allizom.org/enter_bug.cgi?format=guided#h=firefox|
> > 
> > As an aside, https://bugzilla-dev.allizom.org/enter_bug.cgi?format=guided
> > seems more approachable to me.
> > (of course, I am as far from the typical user.)
> 
> This looks great, and, I agree (including the caveat). Mike?
> 
> 
> Regarding having a devedition/devtools "file a bug" button/menu entry, I
> swear there's a bug for this already, but I couldn't find it... but yes,
> that should be a different bug.

bug 1108387
 https://bugzilla-dev.allizom.org/enter_bug.cgi?format=guided

Looks good, though I think we have them backwards. When I said "we start out by owning our worst problems outright", I really meant that we lead out with the options you've got on

https://bugzilla-dev.allizom.org/enter_bug.cgi?format=guided#h=firefox

_first_, rather than after picking "Firefox", on the theory that 90%+ of the people who find their way to that page will be there because of Firefox. 

Can I convince you to run an experiment and change the categories on that h=firefox page to:

- change the "Firefox" title to: "How can we help?"
- Break "Firefox is slow" and "I have a question" out into their own slots.
- Change "Bug Reporting" to "Bug reporting for Firefox users"
- Add "Bug reports for other products" at the end. 

... and have users land on that one first, and the format=guided link second, via "bug reporting for firefox users"?



(On that second page, you could probably replace Webmaker with DevEdition. All the components of Webmaker have their own issue trackers on Github, less than 30 people who don't work here have _ever_ filed bugs against it in Bugzilla, and AFAICT from asking around it's pretty much a dead product.)
Flags: needinfo?(mhoye)
(In reply to Mike Hoye [:mhoye] from comment #23)
>  https://bugzilla-dev.allizom.org/enter_bug.cgi?format=guided
> 
> Looks good, though I think we have them backwards. When I said "we start out
> by owning our worst problems outright", I really meant that we lead out with
> the options you've got on
> 
> https://bugzilla-dev.allizom.org/enter_bug.cgi?format=guided#h=firefox

as per previous comments here and in other bugs we need to keep the landing page cross-product, not firefox specific.  however firefox will continue to be front-and-centre.

> you could probably replace Webmaker with DevEdition

devedition isn't a separate product.. do you mean https://bugzilla-dev.allizom.org/enter_bug.cgi?format=guided&webdev=1 ?
if so, please file a separate bug so we can track and discuss this.  webmaker was added via bug 895282 and we'd need to ensure that removing it is appropriate.
Attached patch 1050224_5.patch — — Splinter Review 
For reference -- not for review (yet). Code should be on -dev shortly.
Attachment #8606383 - Attachment is obsolete: true
Blocks: 1265117
Per discussion in bug 1265117, closing this as incomplete.
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
Component: Extensions: GuidedBugEntry → Extensions
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: