Pontoon Add-on promotion - personal notes and ideas for technical solution

Pontoon
#1

Hello Pontoon team.

After the call on Thursday March 11 (thank you once more for inviting me), I started looking into the MDN documentation and thinking about how to let Pontoon know that Pontoon Add-on is installed.

tl;dr The technical solution may highly depend on the desired behaviour.

Who is the target audience?

For the first iteration, I propose to limit ourselves to users, who are signed-in to pontoon.mozilla.org AND use it in Firefox.

I am happy to later invest time to bring Pontoon Add-on back to Chrome and other browsers, which I dropped because poor communication with Chrome Web Store. Or improve the configuration for other instances than pontoon.mozilla.org - it’s there, but the UX is not great.

An open question is, whether we see users as whole accounts, or as individual independent sessions. I.e. what should happen in case the user works in Pontoon from multiple devices, but not all of them have Pontoon Add-on installed, or if the user clears cookies and cache and signs to Pontoon without Pontoon Add-on once again?

What are the events?

Now what are the events that may affect the promotion state, and how to track them?

  • Promotion dismissed
    The user dismissed the promotion - they don’t want to use Pontoon Add-on. Their preference can to be stored in Pontoon or in local or session storage.

  • Pontoon Add-on installed
    The user installs the add-on (either via promotion or independently). The add-on can “call home” to store the information in Pontoon (after installation or periodically), or for each Pontoon pageload modify the DOM, window, session or local storage, so Pontoon can detect the add-on is present.

  • Promotion acted on, but add-on not installed
    The user navigated to AMO or started installation of the add-on, but did not finish it. What to do here, if anything, depends on what is the desired behaviour.

  • Pontoon Add-on uninstalled
    The user removed the add-on from their browser, or stopped using that particular device. What to do here depends on what is the desired behaviour, but right now I am not sure if and how this can be detected by the add-on at all.

Feature specification

I didn’t find any user specification in the repository. Can we write one, or start with a user story description and iterate over that? We can of course implement all the options I mentioned above, but it can become unnecessary complicated, and also mean more user data being transferred back and forth, which has both privacy and security implications.

#2

Hi Michael,

Thanks for starting the discussion!

Just a few high-level notes:

  1. We’d like to target registered Pontoon users in Firefox (Chrome is a plus).
  2. We’d identify users by their account and store any relevant data (e.g. “dismissed” flag) in their user profile in the DB (as opposed to cookies and sessions).
  3. We’d promote the add-on if we detect that user does not have the Pontoon Add-on installed or hasn’t dismissed the promotion yet (i.e. by clicking on the CTA button to install the add-on or by clicking the explicit Dismiss button).
  4. Optionally, after a period of time (e.g. 30 days), we could repeat the previous step to catch users that have failed to install the add-on or uninstalled it.

Note that Flod started a spec about a generic infobar component, which also talks about using it to promote Pontoon add-on.

1 Like
#3

For the record, the project is now tracked under bug 1705242.