1475126 - Determine shipping strategy for Firefox Monitor

Status: RESOLVED FIXED

(Firefox :: Firefox Monitor, enhancement, P1)

Description

[(inactive) Nihanth Subramanya [:nhnt11]]

I'm opening this bug to track the effort to land the UI code for the Firefox Monitor project into m-c.

Before we start on a patch, I want to gather some opinions on how we want to ship this. The two routes I see are a) system add-on, b) bake into browser code.

Arguments in favor of system add-on:
- The UI is really not functional or useful without the accompanying web service (or tool, or whatever you want to call it - I'm sticking with service for now), so I see elegance in shipping this in a self-contained manner. This will make it much easier to maintain as the service evolves.
- There is strong motivation to ship this in 62, and I feel better about uplifting this into beta as a system add-on.
- The code so far is already built as a WebExtension, so system add-on means less engineering effort to port it, which is important considering the timeline.

Arguments against system add-on:
- From what I gather, the general sentiment is against this approach and I hesitate to create disturbance in the Force.
- Performance concerns (though FWIW, this is not a startup-sensitive feature and if we can defer loading it that is absolutely fine).


Johann: needinfo'ing you to sanity-check the arguments in favor of the system add-on route, since you know the project fairly well at this point I think.

Florian: needinfo'ing you to get your opinion on "yet another system addon". Could you lay out the exact perf concern (I believe it's about browser startup performance) and whether it's possible to avoid it by loading this add-on lazily?

Also, a general plea: if you have additional arguments for either side please share, and if there's anyone in particular that I missed whose opinion is important here, please add them to the conversation. Thanks!

Comment 1

[Johann Hofmann [:johannh]]

From the last meeting I attended (which was already over a week ago or so) it was my impression that we'd try to "ship" the add-on as a Shield study to some part of the release population in 62, so no need to uplift system add-ons.

> - There is strong motivation to ship this in 62, and I feel better about uplifting this into beta as a system add-on.

Note that however you decide to expose this to a larger part of the release population it will need an independent set of Firefox peer review, QA, and other sign-off processes, and those should pay much stricter attention to impact to the user experience than I did when reviewing the low-exposure study.

My biggest concern is that the study is showing these quite invasive doorhangers on a _ton_ of popular sites without any other purpose than making users sign up to our service and without a good idea about user impact (because this didn't have the time to bake on Nightly or even Beta). Running a (very) quick Shield study is no substitute for riding the trains.

I originally proposed the shield-to-release strategy because I want to give everyone more time to figure out the user experience and potentially launch this to Nightly and Beta before going directly to release.

The study was intended to draw a lot of attention to the service to gauge interest and measure interaction. Are we certain that we want to expose our entire user population to this? Is this exactly how we would have built the service if we had started off building it in m-c or are we doing this because it's just in the Shield study right now? Do we have a plan for rediscoverability?

There is a lot at stake when we start covering half the screen with a scary warning on some of the most popular sites on the internet.

Maybe you have this stuff figured out already and I'm just behind. I'll try to join your meeting tonight. :)

Independent of how the user experience will look and the way that this becomes part of m-c, we should simultaneously start drawing up a better way of getting future patches checked into central. I'm not a big fan of the "develop on GitHub, mass-checkin lots of git commits via bugzilla" method that some folks (AS, DevTools) are practicing. It lacks transparency for other developers, bug reporters and release management. I would suggest just opening a component on Bugzilla for Firefox Monitor and switching development over there (once the initial set of patches is ported over).

Comment 2

[(inactive) Nihanth Subramanya [:nhnt11]]

(In reply to Johann Hofmann [:johannh] from comment #1)

Let me try to respond to your concerns.

> From the last meeting I attended (which was already over a week ago or so)
> it was my impression that we'd try to "ship" the add-on as a Shield study to
> some part of the release population in 62, so no need to uplift system
> add-ons.

I'll be honest, I did not take the idea of using Shield as a release level distribution system very seriously. I want to move away from relying on Shield wrapper code. Overall this idea feels like procrastination.

> > - There is strong motivation to ship this in 62, and I feel better about uplifting this into beta as a system add-on.
> 
> Note that however you decide to expose this to a larger part of the release
> population it will need an independent set of Firefox peer review, QA, and
> other sign-off processes, and those should pay much stricter attention to
> impact to the user experience than I did when reviewing the low-exposure
> study.

I can assure you that the people working on this feature share all of your concerns. We are working towards feature-completion (including review, QA, etc) and this bug was filed proactively in anticipation of work we'll need to do sooner or later. :)

> My biggest concern is that the study is showing these quite invasive
> doorhangers on a _ton_ of popular sites without any other purpose than
> making users sign up to our service and without a good idea about user
> impact (because this didn't have the time to bake on Nightly or even Beta).
> Running a (very) quick Shield study is no substitute for riding the trains.
> I originally proposed the shield-to-release strategy because I want to give
> everyone more time to figure out the user experience and potentially launch
> this to Nightly and Beta before going directly to release.

We are not going to be spamming the user with doorhangers everywhere. I believe this is being addressed by UX and should be clear in the final spec. I have already raised the concern about not respecting the release cycle. We do not intend to ship something for the sake of shipping - this bug is an optimistic lookahead.

> The study was intended to draw a lot of attention to the service to gauge
> interest and measure interaction. Are we certain that we want to expose our
> entire user population to this? Is this exactly how we would have built the
> service if we had started off building it in m-c or are we doing this
> because it's just in the Shield study right now? Do we have a plan for
> rediscoverability?

Rediscoverability is something we've discussed and is being taken seriously by UX. It should be clear in the final spec.

> Maybe you have this stuff figured out already and I'm just behind. I'll try
> to join your meeting tonight. :)

Indeed, please accept my apologies for not providing all the context in the original bug report, I was trying to start the conversation and I think that part was a success. :)

> Independent of how the user experience will look and the way that this
> becomes part of m-c, we should simultaneously start drawing up a better way
> of getting future patches checked into central. I'm not a big fan of the
> "develop on GitHub, mass-checkin lots of git commits via bugzilla" method
> that some folks (AS, DevTools) are practicing. It lacks transparency for
> other developers, bug reporters and release management. I would suggest just
> opening a component on Bugzilla for Firefox Monitor and switching
> development over there (once the initial set of patches is ported over).

I'm not at all trying to isolate this project away from m-c. That's not the intention of the system add-on route. I noticed the lack of a Firefox Monitor Bugzilla component when filing this bug and will be looking into creating one as the path to landing this gets clearer.


I want to emphasize that the system add-on route appeals to me primarily because this is not a web platform feature, it's not a direct web-browsing enhancement, it's an external service - and even if Mozilla is the provider, I feel uncomfortable landing it as a core part of Firefox. It relies on a third-party data provider. Services evolve with the Web, and it feels philosophically right to keep this as an extension. It's a branded product feature, and, to provide one example, will not gel too well with forks of Firefox.

Let me know what you think.

Comment 3

[Graham Perrin]

>  Target: Firefox 62

(In reply to Nihanth Subramanya [:nhnt11] from comment #0)

> … a) system add-on, …

<https://robwu.nl/crxviewer/?crx=https%3A%2F%2Fbugzilla.mozilla.org%2Fattachment.cgi%3Fid%3D8988925> for 1.2 (using the attachment to bug 1463301) shows: 

> strict_min_version": "61.0"

Beyond 1.2: 

- if route (a) is taken, then might the extension be compatible with Firefox ESR 60? 

Imagine some users wishing to add it, manually, to ESR; and so on.

TIA

Comment 4

[(inactive) Nihanth Subramanya [:nhnt11]]

(In reply to Graham Perrin from comment #3)
> >  Target: Firefox 62
> 
> (In reply to Nihanth Subramanya [:nhnt11] from comment #0)
> 
> > … a) system add-on, …
> 
> <https://robwu.nl/crxviewer/?crx=https%3A%2F%2Fbugzilla.mozilla.
> org%2Fattachment.cgi%3Fid%3D8988925> for 1.2 (using the attachment to bug
> 1463301) shows: 
> 
> > strict_min_version": "61.0"

The Shield study targeted users running the current Firefox 61 release.

> Beyond 1.2: 
> 
> - if route (a) is taken, then might the extension be compatible with Firefox
> ESR 60? 
> 
> Imagine some users wishing to add it, manually, to ESR; and so on.
> 
> TIA

I have not so far considered supporting ESR. I'm not sure how we would distribute the add-on in that case. Supporting ESR will likely be a post-62 effort.

Comment 5

[Florian Quèze [:florian]]

Going with a system add-on will have a tiny startup performance cost, like all system add-ons. Although that may be fixable in the future if at some point we stop loading all add-ons before the first browser window, and only load early the add-ons that need to show some UI.

IMO your strongest point in favor of making it a system add-on is making the feature easy to disable, either to unship it if we no longer want to support the service, or for forks that many not want to ship a browser with this dependency on an external service.

Talking about uplifting this to beta before you even have a stable spec is worrying though. And it'll also be a concern for localization.

Comment 6

[(inactive) Nihanth Subramanya [:nhnt11]]

The conclusion is to land this as a system add-on. I'm going to limit this bug's scope to simply contain the discussion in it as well as this conclusion. I'm updating the bug summary accordingly and resolving.