Closed Bug 744613 Opened 12 years ago Closed 11 years ago

Major Snippets Service Improvements

Categories

(Snippets :: Service, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 866963

People

(Reporter: osmose, Unassigned)

References

Details

The snippets service is one of our biggest communication channels, yet the service itself is rather difficult to use. We constantly run into issues with client match rules being out of date, snippets going to the wrong browsers, etc.

Truth is, Client Match Rules are hard. I rewrote half the code that runs them and I still don't get them half the time. Not only that, but localizing a snippet takes a custom script that is currently sitting on my laptop. And we still don't even have good solid stats on how much traffic the snippets server gets or how it's performing.

I'd like to propose some major improvements to the snippets service to address all of these:

1. Get rid of Client Match Rules and instead use a set of built-in rules. Most, if not all, of the functionality can be retained with a set of checkboxes, lists, and other inputs that make it clear which browsers will be receiving a snippet. In addition, we can use the product-details library to allow snippets to be set to go to the latest version of Firefox without requiring a manual update every release.

2. Get rid of locale rules. We currently get most of our snippet translations from .lang files in SVN. There shouldn't be anything stopping us from downloading these .lang files to the snippets server and doing the localization live. This would let additional locales sign up for a snippet and go live without any need to add a new snippet. It may even be possible to set up the service to automatically send strings back to localizers without having to file a bug and hope that the strings match up.

3. Better snippet addon support. A nice-to-have would be the ability to preview a single snippet without having to make a special client match rule for it. We could even enable this for disabled snippets, so that we can test snippets in isolation.

4. Statistics. We have statsd and graphite, which allow us to easily collect statistics on things like response time and the amount of hits we're actually getting with the service over time. We should be able to plug this in with little difficulty.

There's also a few bugs sitting around that I've marked as blockers for this that should be included, such as validating snippet code.

Thoughts?
Depends on: 807378
No longer blocks: 703408
Depends on: 703408
Big plus one to all of the above.  Some other things I have jotted down on my bucket list:

Adjust priority:  Show Snippet A 1% of the time and Snippet B 99% of the time.

Easy a/b testing tool 

Faster deployment of snippets
Engagement leads today said this project is a P2 and a high priority. They said with the traffic to snippets and conversion rates, it is the most valuable user channel that we have. They fully supported the service overhaul project.
This bug has been split into a tracking bug and a number of blocking bugs. I'm marking it as a duplicate of the tracker bug.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.