1229772 - Improve Tab Groups migration page text (update title, should contain information about the Firefox-tabgroups-backup.json created on Desktop, ...?)

Status: VERIFIED FIXED

(Firefox Graveyard :: Panorama, defect)

Description

[Francesco Lodolo [:flod]]

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.

Comment 1

[:Gijs (he/him)]

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?

Comment 2

[Verdi [:verdi] Best to slack me]

> (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.

Comment 3

[:Gijs (he/him)]

(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.

Comment 4

[Verdi [:verdi] Best to slack me]

(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.

Comment 5

[Justin Dolske [:Dolske]]

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

[Kev Needham [:kev]]

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?

Comment 7

[:Gijs (he/him)]

(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?

Comment 8

[Kev Needham [:kev]]

(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

[Verdi [:verdi] Best to slack me]

(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.

Comment 10

[:Gijs (he/him)]

Attachment: MozReview Request: Bug 1229772 - improve wording on tab groups migration page, r?mconley,verdi

Bug 1229772 - improve wording on tab groups migration page, r?mconley,verdi

Comment 11

[:Gijs (he/him)]

Attachment: New copy

(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.

Comment 12

[Mike Conley (:mconley) (:⚙️)]

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?

Comment 13

[:Gijs (he/him)]

Attachment: New copy v2

Comment 14

[:Gijs (he/him)]

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/

Comment 15

[:Gijs (he/him)]

(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.

Comment 16

[Verdi [:verdi] Best to slack me]

https://reviewboard.mozilla.org/r/27229/#review24727

Comment 17

[Mike Conley (:mconley) (:⚙️)]

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?

Comment 18

[:Gijs (he/him)]

(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

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/4c661487b6f0

Comment 20

[Brindusa Tot, Desktop QA]

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