Closed Bug 1146982 Opened 9 years ago Closed 9 years ago

'Send to device' desktop widget - Development

Categories

(www.mozilla.org :: Pages & Content, defect)

Product:
www.mozilla.org
Component:
Pages & Content
Version:
Production
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: ckprice, Assigned: agibson)

References

Details

(Whiteboard: [kb=1715436] engagement-fxGrowth-2015) 

Development for the 'Send to device' widget.

This will appear on the iOS product page, Android product page, FF38 whatsnew and Sync page

UX: https://bugzilla.mozilla.org/show_bug.cgi?id=1146528#c7
Blocks: 1147523
No longer blocks: 1131702, 1136942
Per a meeting today, we verified the following

    Requirements
        iOS and Android marketing messages will be localized in the same 9 locales.
        If there is not a localized version of the product, there shouldn't be a requirement to translate a message.
        All priority and core iOS locales are translated in email marketing.
            Exception is Japan which has been identified as a priority iOS locale.
        If we do not have a localized email message, we should not send them an email.
        If we have a localized email message, but do not have a localized product, it's okay to send them to the App Store and allow Apple to redirect.
            ckprice to confirm that the experience here will be nice.
        Web is responsible for detecting if our email communication is translated in the user's locale.
    Cases
        1. If email message is not translated in iOS/Android to the user's locale, 2 CTA's on page both going to marketplace
            Ty: wbowden and alainez were concerned that google's version with dropdown menu http://cl.ly/image/321X3m2q400N would hide the options too much. Not sure if we want to show both in the context of our page designs or go immediately with their preferred direction.
        2. If email message is translated, single CTA which opens widget.
Still a few things to iron out with copy/design, but I think we're ready to start thinking about implementation.

References:

UX bug 1146528 comment 7
Designs bug 1146528 comment 11, bug 1146528 comment 12, bug 1146528 comment 13
Widget copy bug 1146528 comment 10
SMS/email copy/design bug 1146908
ExactTarget config bug 1152419

The places this will be implemented are:

1. /whatsnew landing page (2 versions: embedded and modal)
2. /firstrun landing page (2 versions: embedded and modal)
3. iOS product page (modal)
4. Android product page (modal)
5. Sync page (modal)
6. [possibly] Campaign download page (modal)

:jpetto, :agibson - let me know your thoughts on who should be assigned to this bug, and if we need another meeting before we start on development.

Reference manifest 38.1 - https://docs.google.com/a/mozilla.com/spreadsheets/d/1-GNqNvMxI2VTfOXHtUha-ud6kdYBNmevydxhNM42rd8/edit#gid=0
Flags: needinfo?(jon)
Flags: needinfo?(agibson)
I recently did the sms what's new page for FF 37, which is similar to this (but a bit less complicated). So I'm happy to wade into this bug just as soon as I finish the android page (which is nearly ready for a PR). 

I think if we need another meeting about this it will likely come out of starting work on this, if any questions arise. The best course of action might be to just get this straight into master, which other pages can then consume as and when ready.
Flags: needinfo?(agibson)
I agree that we should get this into master as a reusable module with a single implementation first, then issue separate PRs for all other implementations.

Thanks for jumping on this one Alex!
Flags: needinfo?(jon)
Whiteboard: engagement-fxGrowth-2015 → [kb=1715436] engagement-fxGrowth-2015
Assignee: nobody → agibson
Status: NEW → ASSIGNED
Cory, can you please provide a full list of locales that should get this widget?

Thanks
Flags: needinfo?(cprice)
(In reply to Alex Gibson [:agibson] from comment #6)
> Cory, can you please provide a full list of locales that should get this
> widget?
> 
> Thanks
Hey Alex, the list of languages can be found in bug 1152419 comment 0; hopefully you can glean the locales from that.

Just a quick note that if the send to device widget is not available in a certain locale, the page should display a badge (or badges) to the appropriate marketplace store.
Flags: needinfo?(cprice)
(In reply to Cory Price [:ckprice] from comment #7)
> (In reply to Alex Gibson [:agibson] from comment #6)
> > Cory, can you please provide a full list of locales that should get this
> > widget?
> > 
> > Thanks
> Hey Alex, the list of languages can be found in bug 1152419 comment 0;
> hopefully you can glean the locales from that.
> 
> Just a quick note that if the send to device widget is not available in a
> certain locale, the page should display a badge (or badges) to the
> appropriate marketplace store.

Thanks, I'll try and work out the most suitable list of locales from these languages.

Just for clarification, when you say "the page should display a badge", does this mean in the page (in place of a CTA button), or in a modal once the user clicks the CTA?

If a page is just targeting one platform (e.g. iOS product page or Android product page), it seems like we could just link the CTA button (which will be translated anyway) directly to the appropriate app store, to save the user needing to click twice. Thoughts?
Just a note that (In reply to Cory Price [:ckprice] from comment #7)
> Hey Alex, the list of languages can be found in bug 1152419 comment 0;
> hopefully you can glean the locales from that.
> 
> Just a quick note that if the send to device widget is not available in a
> certain locale, the page should display a badge (or badges) to the
> appropriate marketplace store.
NOTE: if on desktop, and user does not have access to the widget (see comment above), the user should see our custom button, not the marketplace badge.
(In reply to Cory Price [:ckprice] from comment #9)
> Just a note that (In reply to Cory Price [:ckprice] from comment #7)
> > Hey Alex, the list of languages can be found in bug 1152419 comment 0;
> > hopefully you can glean the locales from that.
> > 
> > Just a quick note that if the send to device widget is not available in a
> > certain locale, the page should display a badge (or badges) to the
> > appropriate marketplace store.
> NOTE: if on desktop, and user does not have access to the widget (see
> comment above), the user should see our custom button, not the marketplace
> badge.

Hi Cory, can you please clarify what you mean by "if on desktop"? Does this mean in relation to viewport size, or the users platform? The wording doesn't feel entirely clear.

Could this be reworded like "If the user is on iOS or Android, users should see a marketplace badge and not a custom button to open the widget?"

If so, this logic will likely need to live in each respective page, as opposed to inside the widget itself.
Flags: needinfo?(cprice)
I think it might be worth having a quick catchup on the logic being proposed here. I feel I'm not entirely clear on how this should behave for locales that don't get the widget (i.e. custom button or marketplace badge).

Also, if a non supported locale gets the custom button (which afaik opens a modal with two further CTA buttons), what strings are we using for those? I don't seem to see any in the copy doc.
(In reply to Cory Price [:ckprice] from comment #7)
> Hey Alex, the list of languages can be found in bug 1152419 comment 0;
> hopefully you can glean the locales from that.

I've expanded the list of languages to the following bedrock locales:

['de', 'en-GB', 'en-US', 'en-ZA', 'es-AR', 'es-CL', 'es-ES', 'es-MX', 'fr', 'hu', 'id', 'pl', 'pt-BR', 'ru']

If someone could verify that this looks ok, that would be great. Thanks
(In reply to Alex Gibson [:agibson] from comment #12)
> (In reply to Cory Price [:ckprice] from comment #7)
> > Hey Alex, the list of languages can be found in bug 1152419 comment 0;
> > hopefully you can glean the locales from that.
> 
> I've expanded the list of languages to the following bedrock locales:
> 
> ['de', 'en-GB', 'en-US', 'en-ZA', 'es-AR', 'es-CL', 'es-ES', 'es-MX', 'fr',
> 'hu', 'id', 'pl', 'pt-BR', 'ru']
> 
> If someone could verify that this looks ok, that would be great. Thanks
+ Ben Niolet - since the available locales are driven by what we can translate in ET. Does this list of locales look good?
Flags: needinfo?(cprice) → needinfo?(bniolet)
Yes. We support all of those languages with our email program.
Flags: needinfo?(bniolet)
(In reply to Alex Gibson [:agibson] from comment #11)
> I think it might be worth having a quick catchup on the logic being proposed
> here. I feel I'm not entirely clear on how this should behave for locales
> that don't get the widget (i.e. custom button or marketplace badge).
> 
> Also, if a non supported locale gets the custom button (which afaik opens a
> modal with two further CTA buttons), what strings are we using for those? I
> don't seem to see any in the copy doc.
Hi Alex - we have a meeting to go over this tomorrow.

In the meantime, some of the content in the Etherpad in comment 2 may help

Notably

    Cases
    1. If email message is not translated in iOS/Android to the user's locale, CTA(s) on page go to marketplace. We do not engage with the widget.
    2. If email message is translated, single CTA which opens widget.
(In reply to Cory Price [:ckprice] from comment #15)
> Hi Alex - we have a meeting to go over this tomorrow.
> 
> In the meantime, some of the content in the Etherpad in comment 2 may help
> 
> Notably
> 
>     Cases
>     1. If email message is not translated in iOS/Android to the user's
> locale, CTA(s) on page go to marketplace. We do not engage with the widget.
>     2. If email message is translated, single CTA which opens widget.

This still doesn't quite answer my question, but I'm probably not explaining it clear enough. Let's go through this in person tomorrow. Thanks.
Demo2 URL using a placeholder page:

https://www-demo2.allizom.org/styleguide/docs/send-to-device/

Still WIP and not yet functional
Just want to confirm that the STD widget will be mimicking the whatsnew 37 logic where if a user is in the US, they will have the option for SMS and the form will be displayed in their language. However, the actually SMS communication will just be in English.
Additional note: although we are launching June 2 with only 8-10 locales for the widget, the plan is to expand this to all of our supported locales, so please ensure the widget is translated in all/most locales.

Thanks
Thanks, completely missed that. I will expose the file to all locales then.
Cory, as this will likely need to land in master first, can you please let me know if there are any GA tracking requirements for this widget? (I'm assuming yes).

The widget will need to use the same global GA events for all pages it is consumed on.

Thanks
Flags: needinfo?(cprice)
Thanks Alex - I am working on a GA tracking doc now. Keeping my NI on
Bug 1159879 is created, with a link to the tagging matrix.
Flags: needinfo?(cprice)
I know we currently only have the 1 SMS message for Android, but what about the various emails? Do we know how we want that to work? Will these be new newsletters with specific welcome messages that will be the message with the link? If so do we know what these will be called?
Flags: needinfo?(bniolet)
I believe we want to handle these the way we did Fx37: These are not ongoing communication streams, but one-off messages. 

The way we handled 37 was to create a new "newsletter" in basket and accompanying flag on Master_Subscribers that had a welcome message. That welcome was the download-link email. 

So the form would have to have a unique slug that I could point basket to.
Flags: needinfo?(bniolet)
That's what I thought Ben. So we just need you to create said newsletters for the messages we need and tell me their newsletter slugs.
Flags: needinfo?(bniolet)
Which I think are just 3:

1. Android
2. iOS
3. Both

Right Cory?
ok. My understanding for this widget is there is only one message: Firefox for Android. If I'm wrong, someone speak up. 

Otherwise, let's use the existing one for Android (I'll need to update the message) 

Slug: 

download-firefox-android
Flags: needinfo?(bniolet) → needinfo?(cprice)
(In reply to Ben Niolet from comment #28)
> ok. My understanding for this widget is there is only one message: Firefox
> for Android. If I'm wrong, someone speak up. 

Obviously we don't _need_ iOS/Both for June 2nd. But if the Send to device WIP dev is currently handling these, can we go ahead and build out iOS/Both newsletters? They don't need to have real content at this time.

Thanks
Flags: needinfo?(cprice)
In that case, let's go with these slugs: 

1. Android: download-firefox-android
2. iOS: download-firefox-ios
3. Both download-firefox-mobile

I will get these added to basket and Master_Subscribers this afternoon. Will update here when it's done.
Ok. 

All three are live on basket staging (basket.allizom.org)

For mobile and ios, only EN is available (for both Text and HTML) and both will send the android message. 

When we are ready to move this to prod, I can update to basket prod.
I've updated them in the branch. Do you have the new message ID for the iOS SMS message as well?
Hi all -

Just checking up on this bug. When do we think we can see it in action on the Android page? https://www-demo2.allizom.org/en-US/firefox/android/
(In reply to Cory Price [:ckprice] from comment #33)
> Hi all -
> 
> Just checking up on this bug. When do we think we can see it in action on
> the Android page? https://www-demo2.allizom.org/en-US/firefox/android/

I needs to be merged to master before it can be put on the android page. 

You can already view it here:

https://www-demo2.allizom.org/styleguide/docs/send-to-device/

I believe we're just waiting on some basket changes before the form is fully testable on a demo server.
Commits pushed to master at https://github.com/mozilla/bedrock

https://github.com/mozilla/bedrock/commit/1dd50365982d56d88e548b3000ecf16ebb60b9ae
[bug 1146982] Add 'Send to Device' macro

https://github.com/mozilla/bedrock/commit/ffd9c6e15e4b2bf65b77a82e49b9eaf62d9cf9a0
Bug 1146982: Add view for send-to-device post.

Still need to:

* Add iOS SMS message.
* Add SMS message for "both" situations.

https://github.com/mozilla/bedrock/commit/d883ea29ff4b5c61d95bc4336476765d525f424d
[Bug 1146982] Send to device widget updates

https://github.com/mozilla/bedrock/commit/15b08aca8d1029795c6c6bfaf36bd456c104b3d8
Merge pull request #2919 from mozilla/bug-1146982-send-to-device-desktop-widget

[bug 1146982] Add 'Send to Device' macro
(In reply to Cory Price [:ckprice] from comment #33)
> Hi all -
> 
> Just checking up on this bug. When do we think we can see it in action on
> the Android page? https://www-demo2.allizom.org/en-US/firefox/android/

The widget is now in place on the Android page on demo2: https://www-demo2.allizom.org/en-US/firefox/android/
Everything will be live today. Standby.
Which basket instance is the demo form linked to? Dev, staging or prod?
Flags: needinfo?(pmac)
Flags: needinfo?(agibson)
Not quite, sure - I'll defer to pmac on this one?
Flags: needinfo?(agibson)
demos + dev is linked to basket-dev.
Flags: needinfo?(pmac)
Hey pmac, are you still seeing errors when calls are made to basket-dev? I'm trying to test the widget form and nothing seems to be making it to the ExactTarget sandbox.
Flags: needinfo?(pmac)
I see several "invalid phone number" errors, but nothing about errors with email submissions.
Flags: needinfo?(pmac)
ok. I can confirm that email submitted from the demo form shows up in the ExactTarget Sandbox environment.
Emails are firing correctly from Basket-stage.
Depends on: 1169026
All tested on demo2, which is connected to basket-stage, which is connected to ET prod.

QA doc here:
https://docs.google.com/spreadsheets/d/1c4HdaK_BjzvJf6DvZwKX9ZOa0aNZ76EawK7Sd1JrgJQ/edit#gid=0

mbrandt on deck to help test when the page moves to stage and then prod.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.