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)
Tracking
()
RESOLVED
FIXED
Due Date:
People
(Reporter: Gijs, Assigned: dylan)
References
(Blocks 1 open bug)
Details
Attachments
(2 files, 5 obsolete files)
17.07 KB,
patch
|
glob
:
review+
|
Details | Diff | Splinter Review |
5.03 KB,
patch
|
glob
:
review+
|
Details | Diff | Splinter Review |
(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)
Reporter | ||
Comment 1•10 years ago
|
||
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.
Comment 2•10 years ago
|
||
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."
Comment 3•10 years ago
|
||
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.
Assignee | ||
Comment 4•10 years ago
|
||
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)
Comment 5•10 years ago
|
||
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)
Assignee | ||
Comment 6•10 years ago
|
||
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 | ||
Updated•10 years ago
|
Assignee: nobody → dylan
Assignee | ||
Comment 7•10 years ago
|
||
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)
Assignee | ||
Comment 8•10 years ago
|
||
Any thoughts on this user interface mock-up, glob? https://bugzilla-dev.allizom.org/page.cgi?id=new-bug-guide.html
Flags: needinfo?(glob)
Comment 9•10 years ago
|
||
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)
Comment 10•10 years ago
|
||
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)
Reporter | ||
Comment 11•10 years ago
|
||
(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 . :-)
Comment 12•10 years ago
|
||
(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.
Comment 13•10 years ago
|
||
> (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.
Reporter | ||
Comment 14•10 years ago
|
||
(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?
Comment 15•10 years ago
|
||
(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?
Comment 16•10 years ago
|
||
(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.
Assignee | ||
Comment 17•10 years ago
|
||
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)
Comment 18•10 years ago
|
||
(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)
Comment 19•10 years ago
|
||
(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.
Assignee | ||
Updated•10 years ago
|
Due Date: 2014-11-12
Assignee | ||
Comment 20•10 years ago
|
||
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
Assignee | ||
Comment 21•10 years ago
|
||
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
Assignee | ||
Comment 22•10 years ago
|
||
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)
Assignee | ||
Comment 23•10 years ago
|
||
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.
Comment 25•10 years ago
|
||
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+
Assignee | ||
Comment 26•10 years ago
|
||
(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.
Assignee | ||
Comment 27•10 years ago
|
||
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)
Assignee | ||
Comment 28•9 years ago
|
||
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 29•9 years ago
|
||
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-
Assignee | ||
Comment 30•9 years ago
|
||
This patch should resolve everything from the previous review + autofocuses the dupes summary.
Attachment #8527262 -
Attachment is obsolete: true
Attachment #8529300 -
Flags: review?(glob)
Comment 31•9 years ago
|
||
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-
Assignee | ||
Comment 32•9 years ago
|
||
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)
Assignee | ||
Comment 33•9 years ago
|
||
These are some changes that don't effect behavior, should I roll them into the patch? They just fix some js issues.
Assignee | ||
Updated•9 years ago
|
Attachment #8537856 -
Attachment description: bugzilla-1050232-js-fixes.patch → bug-1050232-js-fixes.patch
Comment 34•9 years ago
|
||
(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 :)
Assignee | ||
Comment 35•9 years ago
|
||
Note: glob was reviewing this (with rolled in js fixes) before the holidays.
Comment 36•9 years ago
|
||
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 37•9 years ago
|
||
Comment on attachment 8537856 [details] [diff] [review] bug-1050232-js-fixes.patch r=glob
Attachment #8537856 -
Flags: review+
Assignee | ||
Comment 38•9 years ago
|
||
To ssh://gitolite3@git.mozilla.org/webtools/bmo/bugzilla.git c840c16..7834fbf master -> master
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Comment 39•9 years ago
|
||
now live on https://bugzilla.mozilla.org/enter_bug.cgi?format=guided
Updated•5 years ago
|
Component: Extensions: GuidedBugEntry → Extensions
You need to log in
before you can comment on or make changes to this bug.
Description
•