Comments from Dan: 1. The invite should be all about the caller and provide details of the shared content if shared content there is 2. Big CTA 3. It should be as short as possible - e.g. one line of benefit text 4. It should communicate no downloads, logins, registrations etc (we can worry about whether they have an incompatible browser on the landing page) 5. Be as Firefox-branded as possible*

In Fx39 the Hello URLs will have 60 characters total for the full URL including 34 characters for the identification of the conversation. This makes it hard to share on Twitter and not ideal on other social networks. Adam, are we able to use a URL shortening service (perhaps mzl.la) and would 11 the minimum number of required characters identifying the conversation to allow a large enough namespace to avoid having guessable ?

Twitter actually auto shortens URLs coming from the shareplane with a t.co URL looking like http://t.co/vMwdg793Jf so it looks like we'll have that out of the box anyway. Whatever URL gets shared on Twitter through the shareplane, 117 characters are left to use for free text. Matej, could you please help us design a message that would work given the 117 character constraints? To start with we'll likely to use this message for all share providers (Twitter, Facebook, VK, Google...) - moving forward beyond Fx39 we'll likely look into separate messages for different share providers taking into account there respective constrainsts.

(In reply to Romain Testard [:RT] from comment #2) > Adam, are we able to use a URL shortening service (perhaps mzl.la) and would > 11 the minimum number of required characters identifying the conversation to > allow a large enough namespace to avoid having guessable ? I see you figured out the answer to your question for Twitter, but wanted to clear something up here regarding the use of link shorteners. Keep in mind that there are two parts of the URL here -- the 11 characters you mention was chosen to large enough to avoid spam calls. The remaining portion of the URL for Fx39 are a crypto key. They're transmitted in the fragment portion of the URL explicitly for the purpose of preventing Mozilla (or any other single entity, for that matter) from being able to decrypt room context information. Storing them in a link shortening service would defeat the purpose of encrypting the room context information.

To be clear, if people are putting these links into Twitter, and Twitter shortens the links, that's fine -- the user is throwing them out into the public sphere and have indicated the level of privacy they expect by doing so. What I worry about is any systematic storage of these links in a shortener by Mozilla.

(In reply to Romain Testard [:RT] from comment #3) > Twitter actually auto shortens URLs coming from the shareplane with a t.co > URL looking like http://t.co/vMwdg793Jf so it looks like we'll have that out > of the box anyway. > Whatever URL gets shared on Twitter through the shareplane, 117 characters > are left to use for free text. > > Matej, could you please help us design a message that would work given the > 117 character constraints? > To start with we'll likely to use this message for all share providers > (Twitter, Facebook, VK, Google...) - moving forward beyond Fx39 we'll likely > look into separate messages for different share providers taking into > account there respective constrainsts. Reading through this bug, I'm not totally clear what this copy is supposed to communicate, how it will be used or who will see it. Could you provide a little more info (and maybe a quick mockup)? Thanks.

(In reply to Adam Roach [:abr] (Traveling through March 30 -- will be slow to respond) from comment #5) > To be clear, if people are putting these links into Twitter, and Twitter > shortens the links, that's fine -- the user is throwing them out into the > public sphere and have indicated the level of privacy they expect by doing > so. What I worry about is any systematic storage of these links in a > shortener by Mozilla. OK, sounds fine. We'll let third parties shorten the links if it's part of their service but we won't do it ourselves systematically.

(In reply to Matej Novak [:matej] from comment #6) > Reading through this bug, I'm not totally clear what this copy is supposed > to communicate, how it will be used or who will see it. Could you provide a > little more info (and maybe a quick mockup)? Thanks. For a complete mockup, please see https://bug1128101.bugzilla.mozilla.org/attachment.cgi?id=8569938.

In reply to Matej Novak [:matej] from comment #6) > (In reply to Romain Testard [:RT] from comment #3) > > Twitter actually auto shortens URLs coming from the shareplane with a t.co > > URL looking like http://t.co/vMwdg793Jf so it looks like we'll have that out > > of the box anyway. > > Whatever URL gets shared on Twitter through the shareplane, 117 characters > > are left to use for free text. > > > > Matej, could you please help us design a message that would work given the > > 117 character constraints? > > To start with we'll likely to use this message for all share providers > > (Twitter, Facebook, VK, Google...) - moving forward beyond Fx39 we'll likely > > look into separate messages for different share providers taking into > > account there respective constrainsts. > > Reading through this bug, I'm not totally clear what this copy is supposed > to communicate, how it will be used or who will see it. Could you provide a > little more info (and maybe a quick mockup)? Thanks. The detailed requirements can be found on the US field of bug 1132301 We leverage the shareplane to share Hello URLs through the social networks that it supports. We want to define the message used when sharing through Twitter since there are limitations regarding the number of characters - given that Twitter auto shortens the shared URLs using 22 characters plus 1 space we're left with 117 characters to design a message informing the user that he's invited to talk to the message sender and ideally communicate that that no downloads or registrations are required. For other share providers without such restrictions on the limit of characters I assume that we should use the same text as the e-mail text; i.e: - if URL context is added similar text to bug 1142532 - if no URL context is added similar text to what we have currently (bug 1113090) Hope this helps clarify things.

Removing my flag for now. I believe Romain and I figured this out over email (i.e. to use what's in the mockup in comment 8, which looks good to me), but please flag me if you need anything else.

Agreed we'll use the wording with Twitter per the Twitter mock on https://bug1128101.bugzilla.mozilla.org/attachment.cgi?id=8569938 Facebook and other providers will use the same wording as the Facebook mock on the above link.