Closed
Bug 1229772
Opened 9 years ago
Closed 9 years ago
Improve Tab Groups migration page text (update title, should contain information about the Firefox-tabgroups-backup.json created on Desktop, ...?)
Categories
(Firefox Graveyard :: Panorama, defect)
Firefox Graveyard
Panorama
Tracking
(firefox45 verified)
VERIFIED
FIXED
Firefox 45
Tracking | Status | |
---|---|---|
firefox45 | --- | verified |
People
(Reporter: flod, Assigned: Gijs)
References
Details
Attachments
(2 files, 1 obsolete file)
Just upgraded Nightly after bug 1222490 landed, and I was surprised to find a file on my desktop. I read the page and didn't bother opening the Learn More link: I was aware that Tab Groups was going away (warning has been there for a while), I read the page but there's no mention of this file. I think we have to tell users that we're going to create a file on their desktop: no need to go into details on why or how to use it, there's a link to SUMO for that, but creating a file without warning sounds wrong. Also, if you close that page, you might find the file later and wonder why and when it was created.
Assignee | ||
Comment 1•9 years ago
|
||
In bug 1221050 Madhava mentioned that he'd like the title to be changed, but after the patch had already landed. Let's just use this bug for general improvements to the strings there. Matej's suggestions for the title were: (In reply to Matej Novak [:matej] from bug 1221050 comment #121) > [...] here are some options: > > "Tab Groups are gone, but not your tabs" > > "We've removed Tab Groups, but saved your tabs" > > "Sorry, Tab Groups have been discontinued" I also concur with flod that we should give some indication of the file having been created and leave the details to the SUMO article. Philipp / Verdi: who from the UX side can drive getting us final strings here? Is there anything else in the page that needs to change?
Blocks: 1221050
Flags: needinfo?(philipp)
Flags: needinfo?(mverdi)
Summary: Tab Groups removal should contain information about the Firefox-tabgroups-backup.json created on Desktop → Improve Tab Groups migration page text (update title, should contain information about the Firefox-tabgroups-backup.json created on Desktop, ...?)
Comment 2•9 years ago
|
||
> (In reply to Matej Novak [:matej] from bug 1221050 comment #121) > > [...] here are some options: > > > > "Tab Groups are gone, but not your tabs" > > > > "We've removed Tab Groups, but saved your tabs" > > > > "Sorry, Tab Groups have been discontinued" > Philipp and I just talked about this. Let's go with "We've removed Tab Groups, but saved your tabs" > I also concur with flod that we should give some indication of the file > having been created and leave the details to the SUMO article. Let's put the file in the profile folder since it's a backup of data from the current profile. This way we remove confusion about a file on the desktop, we don't need to tell people about this file on the restore page and people reading the sumo page can still be given instructions on how to use the file. > Is there anything else in the page that needs to change? The other thing we wanted to do survey people about their tab usage. A few hundred responses would work, 1000 would be great. The three options I've been discussing are: * Add a link to the survey in the sumo doc. This is simple to do but it's likely we won't get enough responses to be helpful. * We could add this link to the restore page - could get us enough responses. That requires another string. Also, the moment we've removed tab groups may not be the best time to survey people. * We could show an info bar with this link on the next restart - could get us enough responses. Still requires a string plus whatever code it takes to display an infobar on a later session.
Flags: needinfo?(philipp)
Flags: needinfo?(mverdi)
Assignee | ||
Comment 3•9 years ago
|
||
(In reply to Verdi [:verdi] from comment #2) > Let's go with "We've removed Tab Groups, but saved your tabs" OK. > > I also concur with flod that we should give some indication of the file > > having been created and leave the details to the SUMO article. > > Let's put the file in the profile folder since it's a backup of data from > the current profile. This way we remove confusion about a file on the > desktop, we don't need to tell people about this file on the restore page > and people reading the sumo page can still be given instructions on how to > use the file. As I noted both on IRC when this bug was originally discussed, and in bug 1221050 comment 57 for the initial implementation, I explicitly did not want to put it in the profile folder, because it is privacy-sensitive data and keeping it hanging about indefinitely is a bad idea. Can you please reconsider this, or if not, provide reasoning as to why it would be OK to leave the file there? > > Is there anything else in the page that needs to change? > The other thing we wanted to do survey people about their tab usage. Asking them what, exactly? What data are you aiming to get? To inform what decisions? Wouldn't telemetry be a much better way to get this data (objectively, too!)? > A few > hundred responses would work, 1000 would be great. The three options I've > been discussing are: > * Add a link to the survey in the sumo doc. This is simple to do but it's > likely we won't get enough responses to be helpful. > * We could add this link to the restore page - could get us enough > responses. That requires another string. Also, the moment we've removed tab > groups may not be the best time to survey people. I don't really mind adding another string, but equally I'm really skeptical of the value here. > * We could show an info bar with this link on the next restart - could get > us enough responses. Still requires a string plus whatever code it takes to > display an infobar on a later session. What is "a later session" specifically - 3 startups later ? Version 46? Something else? Would you want to show this to everyone or just people who'd seen the migration? Note that after the migration has finished there is no way to determine the user used to use tab groups. An info bar here sounds like it will be too intrusive and potentially even more infuriating for users than asking them to fill it in from the migration page.
Flags: needinfo?(mverdi)
Comment 4•9 years ago
|
||
(In reply to :Gijs Kruitbosch from comment #3) > As I noted both on IRC when this bug was originally discussed, and in bug > 1221050 comment 57 for the initial implementation, I explicitly did not want > to put it in the profile folder, because it is privacy-sensitive data and > keeping it hanging about indefinitely is a bad idea. > > Can you please reconsider this, or if not, provide reasoning as to why it > would be OK to leave the file there? > I don't think it's a privacy issue to leave it in the profile because the profile is already full of all kinds of privacy sensitive data including backups of bookmarks and sessions. > > > Is there anything else in the page that needs to change? > > The other thing we wanted to do survey people about their tab usage. > > Asking them what, exactly? What data are you aiming to get? To inform what > decisions? Wouldn't telemetry be a much better way to get this data > (objectively, too!)? > Yes, data to inform decisions. Telemetry is certainly useful but that kind of data doesn't tell you why someone does something, only that they do it. Surveying people we know were using a system to manage many tabs is a good way to learn more about what worked and what didn't. > > I don't really mind adding another string, but equally I'm really skeptical > of the value here. > We need both quantitative and qualitative data so I think a survey in this case would be good since direct observation or interviews are probably not possible. > > What is "a later session" specifically - 3 startups later ? Version 46? > Something else? Would you want to show this to everyone or just people who'd > seen the migration? Note that after the migration has finished there is no > way to determine the user used to use tab groups. My thought was the next session and shown only to people who'd seen the migration. Maybe it could be based off of the existence of the backup file? > > An info bar here sounds like it will be too intrusive and potentially even > more infuriating for users than asking them to fill it in from the migration > page. Yes that's certainly a possibility - I'm worried about that too.
Flags: needinfo?(mverdi)
Comment 5•9 years ago
|
||
Putting the file on the desktop is necessarily _wrong_, but I do think the profile is the better place for it. Really, this is just us being extra-cautious with user data in case there's some unforseen screwup -- users should never need to think about this file or do anything with it. We can have a followup bug to delete the file in a release or two. (Although we've been bad at remembering to actually do that -- bug 1013947 *cough*). (This should probably be a separate bug, since it doesn't really have anything to do with the page content.) I also don't think a survey is going to add any value. It's the wrong time to be asking, and we're just going to get a lot of "you suck I'm switching to Opera" from angry people. And given that there is no work planned on a replacement in the foreseeable future, when/if we get around to it this isn't likely to be terribly useful.
Comment 6•9 years ago
|
||
Additionally, there has been an addon created that can just use the profile data as-is. Having it in both places (or the option to be in both places) would be optimal. At the risk of adding complexity here, might it make sense to expand on the "we've removed tab groups" messaging to include a learn more button, and also present the user with the ability to generate an export on demand vs. us creating it and eventually having to delete it automagically?
Assignee | ||
Comment 7•9 years ago
|
||
(In reply to Kev Needham [:kev] from comment #6) > Additionally, there has been an addon created that can just use the profile > data as-is. Having it in both places (or the option to be in both places) > would be optimal. Having it on desktop *and* the profile solves neither problem, though - it'll leak the privacy-sensitive data, and it'll surprise people when they find it on desktop with no explanation. From comment #4 and #5, it seems we should just stick it in the profile. I'll file a followup for that. (also, flod: sorry for hijacking your bug...). > At the risk of adding complexity here, might it make sense > to expand on the "we've removed tab groups" messaging to include a learn > more button, There is already a learn more link on the page. See the screenshot in bug 1221050. This would increase the number of actions the user can take on this page to 3 (go to sumo page, recover some tabs/windows, create additional backup file). If we do save the info to a separate file (in the profile or on desktop) automatically first, I'm not sure I see value in letting the user copy it somewhere else. > and also present the user with the ability to generate an > export on demand vs. us creating it and eventually having to delete it > automagically? The data for this file is often going to be huge for users of tab groups - think easily several mb - and we won't have it if we don't explicitly save it, so generating it on demand isn't really a thing we can do. Saving it as part of this page's data and then writing it to disk separately only when asked (but potentially keeping it as part of the main session file for months while people keep the migration page open "just in case" they want to reopen a background group) sounds like it won't lead to the experience we want. I agree with dolske on the survey and don't think it's a good idea. If we really want to do it, we will need the details for this page very very soon - we might not be able to get anything about it done in mozlando, if whistler/portland were anything to go by, and 45 branches right after that. I do have a separate question I want to ask explicitly: none of the add-ons are officially made by us and therefore I'm hesitant to endorse them - but it's clear that realistically, they will be what the user who's looking at this page *wants*. Should we call these out explicitly on the migration page?
Flags: needinfo?(mverdi)
Comment 8•9 years ago
|
||
(In reply to :Gijs Kruitbosch from comment #7) > (In reply to Kev Needham [:kev] from comment #6) > The data for this file is often going to be huge for users of tab groups - > think easily several mb - and we won't have it if we don't explicitly save > it, so generating it on demand isn't really a thing we can do. Saving it as > part of this page's data and then writing it to disk separately only when > asked (but potentially keeping it as part of the main session file for > months while people keep the migration page open "just in case" they want to > reopen a background group) sounds like it won't lead to the experience we > want. Thanks for info on Learn more. I read harder after I posted. Doh. Wrt the on-demand generation, my intent was to provide that instead of copying it to the desktop or other place we'd copy it, giving the user the ability to put it where they want at their option. Understand the complexity, just thought it was an option that could be considered because it does prevent the file from being put in a place without the user being aware. Concur that it doesn't solve the profile data, but I think the balance of leaving it in the profile for several releases so that it can be recovered, especially given the personal nature of the profile to begin with, makes that less of an issue. We could also look at incorporating clean up into Firefox reset at some point, too. > I do have a separate question I want to ask explicitly: none of the add-ons > are officially made by us and therefore I'm hesitant to endorse them - but > it's clear that realistically, they will be what the user who's looking at > this page *wants*. Should we call these out explicitly on the migration page? We may want to make the dialog say that there may be additional options to extend support, and users should consult the learn more link (or a dedicated link from "there may be alternatives" or some such). In there we could get more specific about the add-ons and how they aren't supported by mozilla, and give pointers to them as alternatives. I wouldn't want to put links directly into the product because there may be more add-ons we become aware of that are better suited on a page that can be updated quickly.
Comment 9•9 years ago
|
||
(In reply to :Gijs Kruitbosch from comment #7) > I do have a separate question I want to ask explicitly: none of the add-ons > are officially made by us and therefore I'm hesitant to endorse them - but > it's clear that realistically, they will be what the user who's looking at > this page *wants*. Should we call these out explicitly on the migration page? No let's not call out any specific add-ons on this page. I'll add that info to the support doc. I do like Kev's suggestion about the link text. Let's do this: Replace: "Firefox has bookmarked all your groups, so you have not lost anything. Learn More" With: "Firefox has bookmarked all your groups so you haven't lost anything. Learn about Tab Group replacement add-ons." Let's also skip the survey on this page. I'll add it to the support page. Maybe the more descriptive link text will drive more visits.
Flags: needinfo?(mverdi)
Assignee | ||
Comment 10•9 years ago
|
||
Bug 1229772 - improve wording on tab groups migration page, r?mconley,verdi
Attachment #8695980 -
Flags: review?(mverdi)
Attachment #8695980 -
Flags: review?(mconley)
Assignee | ||
Comment 11•9 years ago
|
||
(In reply to Verdi [:verdi] from comment #9) > (In reply to :Gijs Kruitbosch from comment #7) > > I do have a separate question I want to ask explicitly: none of the add-ons > > are officially made by us and therefore I'm hesitant to endorse them - but > > it's clear that realistically, they will be what the user who's looking at > > this page *wants*. Should we call these out explicitly on the migration page? > > No let's not call out any specific add-ons on this page. I'll add that info > to the support doc. I do like Kev's suggestion about the link text. Let's do > this: > > Replace: "Firefox has bookmarked all your groups, so you have not lost > anything. Learn More" > With: "Firefox has bookmarked all your groups so you haven't lost anything. > Learn about Tab Group replacement add-ons." I'm assuming the changes in punctuation (have not / haven't, "groups, so" vs. "groups so") here are accidental. Note that I had to change the structure of the l10n text here a little bit, because the link text is so long that it wraps, and: > "Firefox yada yada yada. Learn > about stuff" looked dumb/ugly, and because I thought in the previous incarnation the description and link text were related, and now they mostly aren't anymore (from an l10n/English perspective - obviously they're still about the same project, but the add-ons are not related to the bookmarks per se). Again, the colour of the link text is because I followed it.
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Comment 12•9 years ago
|
||
Comment on attachment 8695980 [details] MozReview Request: Bug 1229772 - improve wording on tab groups migration page, r?mconley,verdi https://reviewboard.mozilla.org/r/27229/#review24635 ::: browser/base/content/aboutTabGroupsMigration.js (Diff revision 1) > - let text = descElement.getAttribute("_description_label"); > - let learnMoreText = descElement.getAttribute("_learnmore_label"); > - let link = document.createElement("a"); > link.href = SUPPORT_URL; > link.target = "_blank"; > - link.textContent = learnMoreText; > - // We don't want to assign the label (plaintext, because we took it out of > - // getAttribute, so html entities have been resolved) directly to innerHTML. > - // Using a separate element and then using innerHTML on that would mean we > - // depend on the HTML encoding (or lack thereof) of %S, which l10n tools > - // might change. > - // So instead, split the plaintext we have and create textNodes: > - let nodes = text.split(/%S/).map(document.createTextNode.bind(document)); > - // then insert the link: > - nodes.splice(1, 0, link); > - // then append all of these in turn: > - for (let node of nodes) { > - descElement.appendChild(node); > - } Whoa - I really don't understand why we were doing this before. How come this was necessary, and why is it no longer necessary?
Attachment #8695980 -
Flags: review?(mconley)
Assignee | ||
Updated•9 years ago
|
Attachment #8695980 -
Flags: review?(mconley)
Assignee | ||
Comment 14•9 years ago
|
||
Comment on attachment 8695980 [details] MozReview Request: Bug 1229772 - improve wording on tab groups migration page, r?mconley,verdi Review request updated; see interdiff: https://reviewboard.mozilla.org/r/27229/diff/1-2/
Assignee | ||
Comment 15•9 years ago
|
||
(In reply to Mike Conley (:mconley) - Needinfo me! from comment #12) > Comment on attachment 8695980 [details] > MozReview Request: Bug 1229772 - improve wording on tab groups migration > page, r?mconley,verdi > > https://reviewboard.mozilla.org/r/27229/#review24635 > > ::: browser/base/content/aboutTabGroupsMigration.js > (Diff revision 1) > > - let text = descElement.getAttribute("_description_label"); > > - let learnMoreText = descElement.getAttribute("_learnmore_label"); > > - let link = document.createElement("a"); > > link.href = SUPPORT_URL; > > link.target = "_blank"; > > - link.textContent = learnMoreText; > > - // We don't want to assign the label (plaintext, because we took it out of > > - // getAttribute, so html entities have been resolved) directly to innerHTML. > > - // Using a separate element and then using innerHTML on that would mean we > > - // depend on the HTML encoding (or lack thereof) of %S, which l10n tools > > - // might change. > > - // So instead, split the plaintext we have and create textNodes: > > - let nodes = text.split(/%S/).map(document.createTextNode.bind(document)); > > - // then insert the link: > > - nodes.splice(1, 0, link); > > - // then append all of these in turn: > > - for (let node of nodes) { > > - descElement.appendChild(node); > > - } > > Whoa - I really don't understand why we were doing this before. How come > this was necessary, and why is it no longer necessary? We were inserting a link into a longer string, and had no .properties files available (only DTDs), and I wanted to avoid having HTML in the DTD strings (with l10n notes to tell localizers not to translate it, which may or may not help), or escaping issues with the string ("&" signs that you stick in the dtd as & and then get resolved to "&" when you getAttribute the localized string, and then if you .innerHTML them later might be problematic), so it got a bit "fancy" to use Tim's phrase from bug 1221050. Now there's essentially just two sentences, one of which is a link. So they can just be hardcoded in the markup and we can only set the target and href in code (to avoid hardcoding the link into the markup). I guess I could put the _blank in the markup, too.
Updated•9 years ago
|
Attachment #8695980 -
Flags: review?(mverdi) → review+
Comment 17•9 years ago
|
||
Comment on attachment 8695980 [details] MozReview Request: Bug 1229772 - improve wording on tab groups migration page, r?mconley,verdi https://reviewboard.mozilla.org/r/27229/#review24745 ::: browser/base/content/aboutTabGroupsMigration.xhtml:37 (Diff revision 2) > - <p id="mainDescription" > + <p id="mainDescription">&tabgroupsmigration.description2;<br /><a id="sumolink">&tabgroupsmigration.learnaboutaddons;</a></p> I don't see too many uses of <br /> in our content pages. Maybe just make #sumlink a display:block?
Attachment #8695980 -
Flags: review?(mconley) → review+
Assignee | ||
Comment 18•9 years ago
|
||
(In reply to Mike Conley (:mconley) - Needinfo me! from comment #17) > I don't see too many uses of <br /> in our content pages. Maybe just make > #sumlink a display:block? I tried it, but that means the focus rectangle becomes much too big if the screen is wide enough that there is space besides the link (or narrow enough for it to wrap). <br> is pretty standard HTML, so I decided to keep it. Let me know if you feel very strongly and I can fix it in a follow-up commit. remote: https://hg.mozilla.org/integration/fx-team/rev/4c661487b6f0
Comment 19•9 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/4c661487b6f0
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 45
Comment 20•9 years ago
|
||
Verified as fixed on 45 track - Aurora builds, on following OSes: Windows 7 x64: buildId: 20151221004011, Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0 Ubuntu 14.04x: buildId: 20151221004011, Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0 Mac 10.10: buildId: 20151221004011 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Firefox/45.0 Verified on Nightly 46 on following OSes: Windows 7 x64: buildID: 20151220030223, Mozilla/5.0 (Windows NT 6.1; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0 Ubuntu 14.04 x64: buildID: 20151220030223, Mozilla/5.0 (X11; Linux x86_64; rv:46.0) Gecko/20100101 Firefox/46.0 Mac 10.10: buildID 20151221030239, Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:46.0) Gecko/20100101 Firefox/46.0
Status: RESOLVED → VERIFIED
Updated•9 years ago
|
Product: Firefox → Firefox Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•