Closed Bug 1050232 Opened 10 years ago Closed 9 years ago

Improve layout of guided bug entry product selection

Categories

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

Production
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Due Date:

People

(Reporter: Gijs, Assigned: dylan)

References

(Blocks 1 open bug)

Details

Attachments

(2 files, 5 obsolete files)

(filed separately from bug 1050230 because I think that one's an easy win)

I think we should separate Software bits from Website bits (ie webmaker, marketplace, mdn, what-have-you) - although that will be a little tricky to do in such a way that non-techie folks that hit this webpage don't get lost with their issues with "Firefox doesn't work with this webpage" in one of the "website" sections...

I also think we should be using the horizontal screen real estate better.

Holly, I'm told you do most of our web design/UX work... could you have a look at this?
Flags: needinfo?(hhabstritt.bugzilla)
Ah, something I forgot to mention in comment #0: I think we should make the "I am an end user and need help" option much more prominent than the product selection itself.
What I said about this wrt webdevs applies just as much or more so to "ordinary" users:

> 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".
>
> Honestly I think the "product" question is just bad in general,
> partly because it's a mishmash of public-facing and internal
> categories, and partly because it's a classification designed for
> _our_ needs, not external users' needs.

I'm looking at ?format=guided again and I am doubly convinced that "product" is just as bad as "component" -- end users should never see it or have to think about it.

Here's what I would replace the *entire page* with (pseudo-Markdown):

# What are you having a problem with?

 * Firefox (our web browser)
 * FirefoxOS (our mobile operating system)
 * Thunderbird (our email client)
 * Other software developed by the Mozilla community (e.g. Seamonkey)
 * A website or network service operated by the Mozilla organization

# How would you like us to help?  /* "Firefox" was clicked above */

 * [I just want to make a brief suggestion.](https://input.mozilla.org/)
 * [I need help getting Firefox to work properly on my computer.](https://support.mozilla.org/firefox)
 * [A website I use doesn't work properly in Firefox, but does in another browser.](--> end-user guided site compat bug)
 * [A website I develop or maintain doesn't work properly in Firefox.](--> webdev guided bug)
 * [I want to make a detailed feature request for the Web platform.](--> webdev guided feature request)
 * [I believe I have found another kind of bug in Firefox.](--> end-user guided bug)
 * ... maybe a few more ...

Notes:

  "Firefox (our web browser)" should include Firefox for Android; end-users should not be exposed to the internal process detail that these are somewhat separate.

  "other software developed ..." should expand to a list if clicked, as should "a website or network service".  These lists should be of *end-user visible names*, NOT bugzilla products.

  The set of "how would you like us to help" choices should be adjusted for each possible choice of "what are you having a problem with".  For instance, I imagine that appropriate choices for developer.mozilla.org include things like "I need help because I can't log in" and "I believe a specific piece of documentation is incorrect."
And, just to make it crystal clear, the only way you ever get faced with the product list is if you hit the small link at the very bottom of the page that says something like "I don't need help filing bugs in this Bugzilla instance", which takes you to the non-guided enter_bug.cgi.
Attached image new-guided-bug-flow.png (obsolete) —
This is what I envision the "flow" being for the redesigned guided bug entry form.

This influences presentation a bit, and I envision the diamond boxes that are at the same level being displayed at the same time. the square boxes above the diamonds would be prominently displayed (a heading?).

The terminal points (bottom of the chart) would be either links to external locations (input, support) or the further customized bug entry forms.

Does this diagram make sense to you?

Thanks!
Flags: needinfo?(zackw)
Blocks: 1050220
No longer blocks: 1050220
Blocks: 1080933
That's essentially what I had in mind and makes sense as flow.  One thing I'm not altogether happy with is the phrasing of  "I believe I have found another kind of bug in Firefox."  but I don't have a better idea.
Flags: needinfo?(zackw)
After the prototype, my plan is for this to be largely data driven, so making changes to the wording / sequence will be possible without a code push. We can evolve it as the understanding of what is helpful to bug reporters changes.
Assignee: nobody → dylan
Alright, here is my horrible mock-up. https://bugzilla-dev.allizom.org/page.cgi?id=new-bug-guide.html

Some intentions that cannot be inferred from that:

1) the terminal points of everything that is not a link outside of Bugzilla will be on the same page.
At least, that is what I would prefer. 
2) As this will be data-driven, there isn't a limitation on how a particular bug reporting flow happens; during the entire process we're building up information to use to create a new bugs (this is needed for all the listed functionality of the superbug bug 1080933)
3) The first menu is really ugly, but at least it using more horizontal space. The final product would more resemble the grid on https://support.mozilla.org/en-US/

Let me know if this style of interaction is compatible with your vision, and I'll finish my plans for implementing it for reals.
Status: NEW → ASSIGNED
Flags: needinfo?(zackw)
Any thoughts on this user interface mock-up, glob?

https://bugzilla-dev.allizom.org/page.cgi?id=new-bug-guide.html
Flags: needinfo?(glob)
It's hard for me to tell how good this is going to be with most of it not yet there, but I think it's headed in the right direction.  I have three concrete comments:

1) Any time something looks like a link rather than a button, right-click -> "Open in New Tab" should work.

2) Any time there's a menu containing only one option, get rid of the menu and promote the one option to the parent level.  (It may make sense to rename that one option after the old name of the menu.)

3) "Firefox's developer tools" and "Firefox's user interface" do not make sense as suboptions of "A website I develop or maintain doesn't work properly in Firefox."
Flags: needinfo?(zackw)
unfortunately it's hard to provide deep UI feedback because this is a rough mock-up.


it feels very weird to transition from a "everything on one page with animations" to a whole page step-by-step wizard once you hit the real bug entry form.  i think it would be a better experience if the new landing page mirrored the current method step-by-step flow.


the initial page needs to have the "find product" ui, as well as links to "i don't need help" (link to the current workflow) and to the advanced bug entry form.


i don't agree with the hiding and/or removal of the other products; all products currently visible on the current guided bug entry form need to be present on the new page (either at the high level, or under 'other').  for example, the 'localization' should be a top-level icon because it's an excellent entry-point for new contributors.


> "Firefox (our web browser)" should include Firefox for Android

are you suggesting that we file all fennec bugs into the desktop product, and rely on triage to move it when appropriate?

we should at least have an option after selecting "Firefox" which prompts the user to select the platform, defaulting to desktop.
Flags: needinfo?(glob)
(In reply to Byron Jones ‹:glob› from comment #10)
> > "Firefox (our web browser)" should include Firefox for Android
> 
> are you suggesting that we file all fennec bugs into the desktop product,
> and rely on triage to move it when appropriate?
> 
> we should at least have an option after selecting "Firefox" which prompts
> the user to select the platform, defaulting to desktop.

I strongly agree that this distinction is important. I also think this should use the icons currently on https://bugzilla.mozilla.org/enter_bug.cgi?format=guided . :-)
(In reply to Byron Jones ‹:glob› from comment #10)
> unfortunately it's hard to provide deep UI feedback because this is a rough
> mock-up.

Yeah.

> it feels very weird to transition from a "everything on one page with
> animations" to a whole page step-by-step wizard once you hit the real bug
> entry form.  i think it would be a better experience if the new landing page
> mirrored the current method step-by-step flow.

I don't have a strong opinion on this, but I would personally be more inclined to change the "whole page step-by-step wizard" to match the new mockup.  It feels more like what Modern Web Apps do, it's potentially faster (fewer round-trips to the server) and it also potentially gives us finer control over how much Stuff is demanding the bug reporter's attention at any one time.

> the initial page needs to have the "find product" ui, as well as links to "i
> don't need help" (link to the current workflow) and to the advanced bug
> entry form.
> 
> i don't agree with the hiding and/or removal of the other products; all
> products currently visible on the current guided bug entry form need to be
> present on the new page (either at the high level, or under 'other').  for
> example, the 'localization' should be a top-level icon because it's an
> excellent entry-point for new contributors.

On this, though, I'm going to push back really hard.

The product list, like the component list, is an INTERNAL BUG MANAGEMENT TOOL.  End users don't understand it and they SHOULDN'T HAVE TO.  Presenting it AT ALL gives the impression that we REQUIRE end users to understand it or we will IGNORE THEM.  THIS IS BAD.

We can expect people to know that they are using Firefox or Thunderbird or Seamonkey or FirefoxOS or "a Mozilla website".  We can NOT expect them to understand that Firefox-for-desktop and Firefox-for-Android are two separate things for bug reporting purposes, particularly as our marketing is at pains to make it sound like it's all one thing.  We absolutely MUST NOT inflict a whole wall of other things (two full 800px-vertical screens! including a prominent "oh and there's MORE!" button!) that they probably have never heard of on them at the very first step.  THEY WILL GIVE UP AND GO AWAY.

(I wish we'd picked a more distinct name for FirefoxOS, but it is qualitatively different enough that I think we can expect people to know that that is what they have, rather than FfA.)

(Localization, though, that's a good point. 

> > "Firefox (our web browser)" should include Firefox for Android
> 
> are you suggesting that we file all fennec bugs into the desktop product,
> and rely on triage to move it when appropriate?

Yes, yes I was.  This, like selecting an appropriate component, is triage's actual JOB.  However...

> we should at least have an option after selecting "Firefox" which prompts
> the user to select the platform, defaulting to desktop.

"Are you using Firefox on: [] a phone or tablet device  [] a 'traditional' laptop or desktop computer" is a question users can reasonably be expected to answer.  I'm not opposed to adding that at the last stage of the workflow, where they are providing lots of details.
> (Localization, though, that's a good point. 

Whoops.

(Localization, though, that's a good point.  "I want to improve the translation of [thing] into my language" or "[thing] is poorly translated into my language" could be second-level signposts pointing toward localization.  But DO NOT PRESENT IT AS A TOP LEVEL CHOICE IT MAKES NO SENSE THERE UNLESS YOU ALREADY UNDERSTAND BUGZILLA.)

Also, from comment 11,

> I strongly agree that this distinction [between desktop and mobile Firefox] is important. 

It's an important distinction TO US, but it is NOT a salient distinction to the end user.  They have Firefox.  It runs on some sort of gadget which they may or may not think of as a "computer" or "telephone".  They can be prompted to identify the type of gadget, but that prompt belongs at the "fill in all the details of the bug" stage - this is a question akin to the old "Hardware" and "OS" dropdowns as far as they're concerned.

> I also think this should use the icons currently on https://bugzilla.mozilla.org/enter_bug.cgi?format=guided . :-)

To be clear, I do not object to the icons themselves, I object to a first-action forced choice among more than seven (plus or minus two) things, which do not all fit on one screen, and most of which are internal entities that an end user has never heard of.
(In reply to Zack Weinberg (:zwol) from comment #13)
> > I strongly agree that this distinction [between desktop and mobile Firefox] is important. 
> 
> It's an important distinction TO US, but it is NOT a salient distinction to
> the end user.  They have Firefox.  It runs on some sort of gadget which they
> may or may not think of as a "computer" or "telephone".  They can be
> prompted to identify the type of gadget, but that prompt belongs at the
> "fill in all the details of the bug" stage - this is a question akin to the
> old "Hardware" and "OS" dropdowns as far as they're concerned.

Hardware/OS are used really poorly in practice, and the only reason they're right half the time is because bugzilla prefills the correct value based on the reporter's OS. It's extremely rare that first time bugreporters adjust that value, nevermind that they do so correctly. The prefilling doesn't help Firefox for Android unless you report on Android (which few people do). I also think the icon version here is a lot more clear than having one-of-very-many-input fields making the user pick "is this on my mobile or my desktop/laptop", with the latter also getting confusing when it's about windows 8 tablets vs. android tablets and so on.

I will also assert that users who file bugs on Firefox for android will know they're filing bugs on Firefox for android.

The goal I had in mind when filing this was to make triage *easier*, not *harder*, which is what I am afraid your suggestion will do, because it'd mean everyone doing triage would have to have a 2-3 comment back and forth with the reporter about what OS/version of Firefox they see this on, in addition to all the other stuff (did you try safe mode, reset firefox, new profile, ...). Ultimately, it means more lost time as well as lost bugs, because reporters tire of answering all the questions and give up.

> > I also think this should use the icons currently on https://bugzilla.mozilla.org/enter_bug.cgi?format=guided . :-)
> 
> To be clear, I do not object to the icons themselves, I object to a
> first-action forced choice among more than seven (plus or minus two) things,
> which do not all fit on one screen, and most of which are internal entities
> that an end user has never heard of.

I can agree here; I think we should make the distinction between e.g. Firefox and "Core" based on something else than the icons on the start page. Other than doing a different layout, I don't have a magical solution for making all the icons into fewer icons.

Perhaps what we *could* do is check how often these components are used? My intuition would say that on an average week, Firefox gets 10-100 times as many new bugs filed as marketplace, which probably gets an order of magnitude more than SeaMonkey (or something along those lines). I think less-frequently-used projects/products should have a smaller presence on this page. Ideally, it'd be good to know how often bugs get filed for these things *through the guided workflow*, but I don't think that's data we have?
(In reply to :Gijs Kruitbosch from comment #14)
> (In reply to Zack Weinberg (:zwol) from comment #13)
> > > I strongly agree that this distinction [between desktop and mobile Firefox] is important. 
> > 
> > It's an important distinction TO US, but it is NOT a salient distinction to
> > the end user.  They have Firefox.  It runs on some sort of gadget which they
> > may or may not think of as a "computer" or "telephone".  They can be
> > prompted to identify the type of gadget, but that prompt belongs at the
> > "fill in all the details of the bug" stage - this is a question akin to the
> > old "Hardware" and "OS" dropdowns as far as they're concerned.
> 
> Hardware/OS are used really poorly in practice, and the only reason they're
> right half the time is because bugzilla prefills the correct value based on
> the reporter's OS.

I didn't mean to suggest that Hardware/OS were *good* questions as is!  All I'm saying is that the distinction between Firefox/desktop and Firefox/mobile is a *detail* which gets in the way if you force people to think about it up front.  IMNSHO.

Is there budget to do actual user testing on this redesign? I think it could really use some.

> The goal I had in mind when filing this was to make triage *easier*, not
> *harder*, which is what I am afraid your suggestion will do, because it'd
> mean everyone doing triage would have to have a 2-3 comment back and forth
> with the reporter about what OS/version of Firefox they see this on, in
> addition to all the other stuff (did you try safe mode, reset firefox, new
> profile, ...). Ultimately, it means more lost time as well as lost bugs,
> because reporters tire of answering all the questions and give up.

Right, I'm happy to have the "is this mobile" question in there somewhere, just not on the first page.

> I can agree here; I think we should make the distinction between e.g.
> Firefox and "Core" based on something else than the icons on the start page.
> Other than doing a different layout, I don't have a magical solution for
> making all the icons into fewer icons.
> 
> Perhaps what we *could* do is check how often these components are used? My
> intuition would say that on an average week, Firefox gets 10-100 times as
> many new bugs filed as marketplace, which probably gets an order of
> magnitude more than SeaMonkey (or something along those lines). I think
> less-frequently-used projects/products should have a smaller presence on
> this page. Ideally, it'd be good to know how often bugs get filed for these
> things *through the guided workflow*, but I don't think that's data we have?

I think we're in violent agreement on this part.  The first page needs to have fewer choices.  I'm also saying something slightly different, which is that the *categorization* on the first page should reflect how our end-users see the divisions between our products, rather than how *we* internally divide things up.

Perhaps another useful source of data here would be the support forums; can we figure out how often people wind up getting directed to file bugs from there, and which products/components they wind up in?
(In reply to Zack Weinberg (:zwol) from comment #12)
> I don't have a strong opinion on this, but I would personally be more
> inclined to change the "whole page step-by-step wizard" to match the new
> mockup.  It feels more like what Modern Web Apps do, it's potentially faster
> (fewer round-trips to the server) and it also potentially gives us finer
> control over how much Stuff is demanding the bug reporter's attention at any
> one time.

the current step-by-step implementation doesn't involve a server round-trip for each page.

i'm not strongly attached to either implementation, however i do feel that it should be consistent.  it would be less work to implement the new pages into the current guided pages than rework the current pages into a stacked page approach.

> On this, though, I'm going to push back really hard.
> [snip]
> But DO NOT PRESENT IT AS A TOP LEVEL CHOICE IT MAKES NO SENSE THERE UNLESS YOU ALREADY
> UNDERSTAND BUGZILLA

there's no need to yell to get your point across.

i don't disagree with hiding bugzilla's internal structure from new users, but i'd like to remind you that bugzilla is used for tracking more than just firefox development.  while firefox should continue to be by far the most important product, we can't just push aside others.


i'm not proposing that we continue to list the current top-level bugzilla products verbatim; sorry i wasn't clear about that in my comment.  consolidating firefox products and moving some products to a second level makes a lot of sense to me too, along with changing the experience to move closer to how users perceive our products.

looking at the current list:

---
firefox
firefox os
firefox for android
marketplace
webmaker
thunderbird
seamonkey
core
localisations
services
other

component search
advanced bug entry
---

i love dylan's comment 7 where he says the final result will be similar to sumo's page.  six boxes in a 3x2 grid fits nicely on the page.

i propose:

---
| firefox     | firefox os   | webmaker |
| thunderbird | localisation | other    |

component search
advanced bug entry
---

"firefox" covers both desktop and android, as per the current flow, along with:

> "Are you using Firefox on: [] a phone or tablet device  [] a 'traditional' laptop or desktop computer"
> is a question users can reasonably be expected to answer.  I'm not opposed to adding that at the last
> stage of the workflow, where they are providing lots of details.

"firefox os" should include a pointer towards "marketplace"

"webmaker" is an important product to mozilla (its growth is a company goal), and shouldn't be relegated to a 2nd level citizen.

"thunderbird" is thunderbird :)

"localisation" - i acknowledge that you don't think this should be a top level icon, but i don't agree with your statement that you require knowledge of bugzilla in order to understand what this means.  the current product description is imho very clear, and when selected we can display further information as well as linking to l10n's excellent documentation on how to engage with their team.

"other" would be a page with the following (with relevant icons and descriptions), maybe in a grid layout also:
- marketplace (yes again)
- seamonkey
- services
- other products

both the "component search" and "advanced bug entry" need to remain, and continue to be displayed at the end of the page.
I think we need to discuss and flesh out what exactly should be in the following interactions:

* end-user guided site compat bug
* webdev guided bug
* webdev guided feature request
* end-user guided bug

Are those meant to map to products? It sort of sounds like they would something like custom forms/questions. If that is the case, we'll need to figure out what information they need to collect (and how they differ from the current, final step of the guided bug process)
Flags: needinfo?(zackw)
(In reply to Dylan William Hardison [:dylan] from comment #17)
> I think we need to discuss and flesh out what exactly should be in the
> following interactions:
> 
> * end-user guided site compat bug
> * webdev guided bug
> * webdev guided feature request
> * end-user guided bug

I think that might be best done in separate bugs.  There's already bug 1050235 for "webdev guided bug and/or feature request", and there's also bug 1050224 and bug 1050226 which are closely-related enough that might make sense to merge them.

I do not know what good "end-user guided generic bug" and "end-user guided site compat" forms would look like.

> Are those meant to map to products? It sort of sounds like they would
> something like custom forms/questions.

Yes, custom forms.
Flags: needinfo?(zackw)
(In reply to Byron Jones ‹:glob› from comment #16)
> (In reply to Zack Weinberg (:zwol) from comment #12)
> > I don't have a strong opinion on this, but I would personally be
> > more inclined to change the "whole page step-by-step wizard" to
> > match the new mockup.  It feels more like what Modern Web Apps do,
> > it's potentially faster (fewer round-trips to the server) and it
> > also potentially gives us finer control over how much Stuff is
> > demanding the bug reporter's attention at any one time.
> 
> the current step-by-step implementation doesn't involve a server
> round-trip for each page.
> 
> i'm not strongly attached to either implementation, however i do
> feel that it should be consistent.  it would be less work to
> implement the new pages into the current guided pages than rework
> the current pages into a stacked page approach.

Oh, ok.  This is hardly a critical design choice, staying consistent
with the current design (and being easier to implement) are good
reasons to stick with the whole-page step-by-step presentation.

> i don't disagree with hiding bugzilla's internal structure from new
> users, but i'd like to remind you that bugzilla is used for tracking
> more than just firefox development.  while firefox should continue
> to be by far the most important product, we can't just push aside
> others.

Certainly! But please note the difference between pushing aside other
products, and presenting internal teams *as if* they were additional
products.  This is perhaps most obvious with the "Firefox (for
desktops)" vs "Firefox (for Android)" distinction.

[...]

> i love dylan's comment 7 where he says the final result will be
> similar to sumo's page.  six boxes in a 3x2 grid fits nicely on the
> page.
> 
> i propose:
> 
> ---
> | firefox     | firefox os   | webmaker |
> | thunderbird | localisation | other    |

so I like this except for "localisation"; yes, the localization *team*
is a distinct entity with its own workflow and its own approach to
attracting contributors, but that doesn't mean it's appropriate to
surface that on a page that is for end-users who are here to report
bugs.  Someone who wants to tell us that our translation of menu item
X into their native language doesn't make any sense, is going to be
confused whether they're supposed to click on the actual thing they're
using, or on "localisation."

I'm all for "$PRODUCT is poorly translated into my native language" as
a second-level guided option, but the process for people who are
already part of the localization team, or are being recruited into the
localization team, deserves its *own*, entirely separate set of pages
which maybe show up under "Custom bug entry forms" or something.

(And that frees up a slot for Marketplace, too!)

[...]
> both the "component search" and "advanced bug entry" need to remain, and
> continue to be displayed at the end of the page.

There certainly should be a way to get to plain enter_bug.cgi, but
isn't a single link enough? Text should be "I don't need help
filing bugs in this Bugzilla instance", or something like that.
That's better signposting as the thing you want only if you already
know the ropes.
Due Date: 2014-11-12
I think we can go a long way restructuring the HTML/CSS to display a grid of icons as discussed. I'm not going to be hiding the product/component search or the advanced view in this iteration, but I'll get it up to bugzilla-dev and we can begin the a cycle of feedback. This is essentially a re-skin, it will be possible to iterate on it a rapid way.

Even if we have agreement on hiding the advanced bug link all the time, and the product/component search, it would require some refactoring to the current guided bug entry. Let's see how far we can bend the current system to our collective will.
Due Date: 2014-11-12 → 2014-11-11
OS: Mac OS X → All
Hardware: x86 → All
This is taking a little longer than anticipated. :(
Nothing horrible, but incredibly fiddly. After trying to massage the current table-based layout into a grid (by moving rows/columns) I have decided that replacing the table for a sufficiently-styled list (with inspiration from sumo).
Due Date: 2014-11-11 → 2014-11-12
Attached patch bug-1050232-f1.patch (obsolete) — Splinter Review
Re-skin only for review. Note: it will require adding a step to merge the firefox and firefox for android links -- if we want to do that. It is also possible we could allow for more than 3 columns (depending on screen size?).
Attachment #8502891 - Attachment is obsolete: true
Attachment #8522392 - Flags: feedback?(glob)
Thinking about this a bit more, I will need to add the "firefox" step which asks if it is firefox on a laptop or desktop or if it is firefox for android. That gets us to 6 boxes.
Additionally, the "exit" links at the top can probably be made to use more horizontal space as well.
clearing stale needinfo request.
Flags: needinfo?(hhabstritt.bugzilla)
Comment on attachment 8522392 [details] [diff] [review]
bug-1050232-f1.patch

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

very nice; this is indeed an improvement.

incorporating notes from our quick irc discussion:

- change the icon size to 64x64
- remove 'firefox for android' option
  - don't add a new 'firefox flavour' step
  - on the last step, if the product is firefox add a checkbox to allow the reporter to indicate this is an issue with the android version
  - file all firefox bugs into firefox/untriaged
  - the "firefox" description needs to be much simpler, perhaps just "For bugs in Firefox, the Mozilla Foundation's web browser."
- there's text overflow issues: https://www.dropbox.com/s/ezkf1dbpwfzeyg8/Screenshot%202014-11-17%2013.29.55.png?dl=0
  - this issue may go away with the changes to icon sizes and product description
- add a link at the top of the dupes step for l10n for supported products (see https://wiki.mozilla.org/L10n:Overview)
  - the text should be "$product_name is poorly translated into my native language"
  - clicking on the link changes the product to "Mozilla Localizations"
- there's unfiltered directives and bug bare words

while not related to this patch, "while you're there":
- focus the input field when switching to the dupe search step

::: extensions/GuidedBugEntry/web/style/guided.css
@@ +59,5 @@
> +    height: 168px;
> +    min-height: 166px;
> +
> +    background-color: #FFF;
> +    background-image: -moz-linear-gradient(center top , #FFF 0px, #F6F4EC 100%);

let's avoid -moz prefixes:
background-image: linear-gradient(0deg, #F6F4EC, #FFF);
Attachment #8522392 - Flags: feedback?(glob) → feedback+
(In reply to Byron Jones ‹:glob› from comment #25)
> Comment on attachment 8522392 [details] [diff] [review]
> bug-1050232-f1.patch
> 
> Review of attachment 8522392 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> very nice; this is indeed an improvement.
> 
> incorporating notes from our quick irc discussion:
> 
> - change the icon size to 64x64
> - remove 'firefox for android' option
>   - don't add a new 'firefox flavour' step
Yep.

>   - on the last step, if the product is firefox add a checkbox to allow the
> reporter to indicate this is an issue with the android version
Keeping the table formatting (even/odd) is sort of annoying, going to use the nth-child() selector,
which will be ignored by IE8. It doesn't make it unusable, just less pretty.

>   - file all firefox bugs into firefox/untriaged
Firefox OS is still separate, correct?

>   - the "firefox" description needs to be much simpler, perhaps just "For
> bugs in Firefox, the Mozilla Foundation's web browser."
You cribbed that from my screenshot. And bug is spelled [% terms.bug %] of course.

> - there's text overflow issues:
> https://www.dropbox.com/s/ezkf1dbpwfzeyg8/Screenshot%202014-11-17%2013.29.55.
> png?dl=0
>   - this issue may go away with the changes to icon sizes and product
> description
That it did.
> - add a link at the top of the dupes step for l10n for supported products
> (see https://wiki.mozilla.org/L10n:Overview)
>   - the text should be "$product_name is poorly translated into my native
> language"
>   - clicking on the link changes the product to "Mozilla Localizations"
all of that is done -- in fact text overflow errors I had fixed over the weekend (as is evident from the screenshots linked in IRC).

> - there's unfiltered directives and bug bare words
Fixed.

> while not related to this patch, "while you're there":
> - focus the input field when switching to the dupe search step
This is a little trickier than you'd think, we have to do this in onShow()
otherwise you end up focusing the (hidden) field...

> ::: extensions/GuidedBugEntry/web/style/guided.css
> let's avoid -moz prefixes:
> background-image: linear-gradient(0deg, #F6F4EC, #FFF);
I think the other way is nicer, as that's what SUMO does. But I'm not fussed.

I'm working on the CSS improvement (nth-child) and I have made many small tweaks margins, padding, etc.
Attached patch bug-1050232-v1.patch (obsolete) — Splinter Review
Here are the UI bits. This should be independent of the other work (now). The other patches will require this one however.
Attachment #8522392 - Attachment is obsolete: true
Attachment #8526993 - Flags: review?(glob)
Attached patch bug-1050232-v1.1.patch (obsolete) — Splinter Review
Discovered a small bug while testing the perf/crash/etc keyword boxes.
Attachment #8526993 - Attachment is obsolete: true
Attachment #8526993 - Flags: review?(glob)
Attachment #8527262 - Flags: review?(glob)
Comment on attachment 8527262 [details] [diff] [review]
bug-1050232-v1.1.patch

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

- the product-list <ul> is very wide, causing horizontal scrollbars to appear, even when the window is wide enough to fit the content (eg 980px wide).  this appears to be the result of hardcoding 1200px twice in the stylesheet; perhaps you want max-width there instead.
- the boxes are not perfectly aligned horizontally (the bottom row is shifted to the left)
- the l10n link on the dupes step is missing (as per comment 25)

::: extensions/GuidedBugEntry/template/en/default/bug/create/comment-guided.txt.tmpl
@@ +3,5 @@
>  User Agent: [% cgi.param('user_agent') %]
>  [% IF cgi.param('build_id') %]
>  Build ID: [% cgi.param('build_id') %][% END %]
> +[% IF cgi.param('firefox_for_android') %]
> +**** Firefox for Android ****

i don't think all those asterisks are required, and they don't match the other items we insert.  just go with "Firefox for Android".

::: extensions/GuidedBugEntry/template/en/default/guided/guided.html.tmpl
@@ +496,5 @@
> +  <td colspan="2">
> +    <table border="0" cellpadding="0" cellspacing="0">
> +      <tr id="firefox_for_android">
> +        <td>
> +          <input type="checkbox" name="firefox_for_android" value="1">

this needs and id attribute too, to make <label for> work

::: extensions/GuidedBugEntry/template/en/default/guided/products.html.tmpl
@@ +11,5 @@
>     icon="firefox.png"
>  %]
> +For [% terms.bugs %] in Firefox, the Mozilla Foundation's web browser.
> +
> +(<a href="https://wiki.mozilla.org/Modules/All#Firefox">more info</a>)

since we can now link to a different url from the product's description, let's take the opportunity to link to something more helpful for new users: https://www.mozilla.org/en-US/firefox/desktop/

::: extensions/GuidedBugEntry/web/js/guided.js
@@ +616,5 @@
> +      Dom.removeClass('firefox_for_android', 'hidden');
> +    }
> +    else {
> +      Dom.addClass('firefox_for_android', 'hidden');
> +    }

the whole "additional details" row should be hidden, not just the checkbox and label.

::: extensions/GuidedBugEntry/web/style/guided.css
@@ +61,5 @@
> +    height: 168px;
> +    min-height: 166px;
> +
> +    background-color: #FFF;
> +    background-image: -moz-linear-gradient(center top , #FFF 0px, #F6F4EC 100%);

i still prefer avoiding -moz prefixed stuff here.
if you really want to use it, include webkit, opera, and un-prefixes variations.
Attachment #8527262 - Flags: review?(glob) → review-
Attached patch bug-1050232-v2.patch (obsolete) — Splinter Review
This patch should resolve everything from the previous review + autofocuses the dupes summary.
Attachment #8527262 - Attachment is obsolete: true
Attachment #8529300 - Flags: review?(glob)
Blocks: 1050252
Comment on attachment 8529300 [details] [diff] [review]
bug-1050232-v2.patch

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

this is looking great.
just some more tweaks around the new l10n link, but i'm fully expecting the next revision to be the last :)

the l10n link is missing for the following products (see https://wiki.mozilla.org/L10n:Overview):
- calendar
- addons.mozilla.org
- marketplace

the l10n is in need of some style; it looks out of place, especially on products with a 'support' message
- move it to below the 'support' message
- style it similar to the 'support' message (or maybe move it within that box?)

::: extensions/GuidedBugEntry/web/style/guided.css
@@ +44,5 @@
> +    width: 64px;
> +}
> +
> +#product_step {
> +    width: 1200px;

this needs to be max-width to prevent unnecessary horizontal scrollbars
Attachment #8529300 - Flags: review?(glob) → review-
Incorporates the styled l10n link (one of several possibilities, this was the nicest of the things I tried)
fixed the width too.
Attachment #8529300 - Attachment is obsolete: true
Attachment #8537845 - Flags: review?(glob)
These are some changes that don't effect behavior, should I roll them into the patch? They just fix some js issues.
Attachment #8537856 - Attachment description: bugzilla-1050232-js-fixes.patch → bug-1050232-js-fixes.patch
(In reply to Dylan William Hardison [:dylan] from comment #33)
> Created attachment 8537856 [details] [diff] [review]
> bug-1050232-js-fixes.patch
> 
> These are some changes that don't effect behavior, should I roll them into
> the patch?

yes :)
Note: glob was reviewing this (with rolled in js fixes) before the holidays.
Comment on attachment 8537845 [details] [diff] [review]
bug-1050232-v3.patch

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

r=glob \o/

::: extensions/GuidedBugEntry/template/en/default/guided/guided.html.tmpl
@@ +298,5 @@
> +      <img src="extensions/BMO/web/producticons/localization.png" width="24" height="24">
> +    </td>
> +    <td>
> +      <a href="javascript:void(0)" id="l10n_link">
> +        <span id="l10n_product"></span> is poorly translated into my native language,

s/,$/./
Attachment #8537845 - Flags: review?(glob) → review+
Comment on attachment 8537856 [details] [diff] [review]
bug-1050232-js-fixes.patch

r=glob
Attachment #8537856 - Flags: review+
To ssh://gitolite3@git.mozilla.org/webtools/bmo/bugzilla.git
   c840c16..7834fbf  master -> master
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Blocks: 1122127
Component: Extensions: GuidedBugEntry → Extensions
You need to log in before you can comment on or make changes to this bug.