<div dir="ltr">I just wanted to add a different type of suggestion: Staged rollouts<div><br></div><div>The Firefox for Android team has landed some code that does A/B testing and staged rollouts, called SwitchBoard [1]. We are modifying it quite a bit to fit our needs. It allows us to not only do A/B testing of new features, it supports staging new features to controlled subsets of our uses based on channel and/or locale. We can changes the subset from 0% to 100% of the user base, dynamically from a server without shipping new code. We are still in the early stages of using the system, but several new features will be landing soon, using staged rollout instead of NIGHTLY_BUILD flags to control the deployment.</div><div><br></div><div>Might be an approach to consider for Desktop too.</div><div><br></div><div>[1] <a href="https://mail.mozilla.org/pipermail/mobile-firefox-dev/2015-September/001463.html">https://mail.mozilla.org/pipermail/mobile-firefox-dev/2015-September/001463.html</a></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 22, 2015 at 7:17 AM, Marco Bonardo <span dir="ltr"><<a href="mailto:mbonardo@mozilla.com" target="_blank">mbonardo@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>I just wanted to start a brief discussion about our use of prefs to quickly enable/disable new features.<br><br></div>The problem I'm seeing happened multiple times, some recent examples are one-off searchbar UI and unified complete, but I can definitely find more examples in the past.<br></div>Basically when we use prefs to enable new features, we leave a UI access to the user to disable it. It's true that it's hidden in about:config, but that's not really enough.<br><br></div>What usually happens is that someone looks for the pref, posts the "solution" on forums/reddit/articles on the web. Anyone that is surprised by the change goes can easily find that "solution" on the Web and can apply it easily (usually it's a brief 4 steps).<br></div>When we remove the pref cause the feature is stabilized enough and has hit at least one release, all those users hit again the change they didn't understand first, and get angry for the second time.<br></div><div>Moreover users won't file enhancement requests to fulfill their needs, cause they can easily revert to something we are about to remove.<br><br></div><div>Very often the are other better alternative solutions (add-ons or userchrome hacks) but at this point the user is angry to us, cause to him looks like we forced the same change twice, plus we removed the option he was using. It's easy to lose a user when you disappoint him thrice in a row.<br><br></div><div>I was wondering if we could evaluate alternatives that are not easily flippable through the UI. This is not about removing customization or user options, rather to avoid disappointing users multiple times for no good reasons.<br><br></div><div>Cheers,<br></div><div>Marco<br></div></div>
<br>_______________________________________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/firefox-dev</a><br>
<br></blockquote></div><br></div>