<p dir="ltr">I don't think we need a different enable/disable mechanism, necessarily, but we do need a way to communicate with users that they're in uncharted territory.  Pref naming is an easy, concrete first step, but it's not enough (and we can't do it retroactively for the prefs already out there).</p>
<p dir="ltr">What I'd propose in addition is that we should create two lists of prefs, one for deprecated prefs that may be removed in the future, and one for prefs that have been removed. If there's a user-set (read: non-default) value recorded for one of the prefs, we can pop a notification bar (bottom of the screen) to communicate with users.</p>
<p dir="ltr">[ Your current Firefox set-up may change in a future release of Firefox. [Learn More] (x) ]</p>
<p dir="ltr">[ Your Firefox set-up has changed.  Some unofficial options have been removed in this release of Firefox.[Learn More] (x) ]</p>
<p dir="ltr">In both cases Learn More goes to a useful link of some sort, ideally passing through the specific match(es) to the page to filter down to the right answer(s).</p>
<p dir="ltr">In the former case, we'd give people a heads up.  Maybe they convince us the alternative is better before we make the change. More likely they at least don't get blindsided.</p>
<p dir="ltr">In the latter case, we get to be proactive and tell that small subset of users that things have changed, and give them alternatives (i.e. point them to any add-ons that restore the functionality).  Rather than the wholly negative reaction we tend to accept as inevitable ("they took my thing away") we can at least get them to a neutral reaction ("they took a thing away, and gave me a viable explanation/alternative").  Maybe even something more positive, because we gave them a solution before they realized they had a problem.</p>
<p dir="ltr">This is a relatively easy feature to write code-wise, the burden would be on the writers and translators.  That said, it's an opportunity to do something that could help us move faster with less backlash.</p>
<p dir="ltr">-- Mike</p>
<div class="gmail_quot<blockquote class=" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Other hidden prefs don't have the same downsides but can have other downsides that users may be unaware of, even severe ones. I still don't think I see the case for inventing something new here.<br>
<br>
+1 for using clearer names, though.<br>
<br>
Dao<br>
<br>
Marco Bonardo schrieb am 22. Dez 2015 17:18:<br>
<br>
> Other hidden prefs don't have the same downsides as feature enabling<br>
> prefs,<br>
> they often don't involve primary UI changes, they don't often have a<br>
> defined expiration date. They are more often non-ui-visible tweaks.<br>
> What I'd like to prevent is the bad feeling we give to users when whole<br>
> features are being forced on them twice.<br>
> I just don't believe anymore hidden prefs are the right toggle for<br>
> features<br>
> enabling/disabling.<br>
><br>
> On Tue, Dec 22, 2015 at 5:09 PM, Dao Gottwald <<a href="mailto:dao@design-noir.de">dao@design-noir.de</a>> wrote:<br>
><br>
>> Points 1 and 3 are true for all hidden prefs, there's always a risk that<br>
>> users don't know what they're doing. By that logic we should ban all<br>
>> hidden<br>
>> prefs...<br>
>><br>
>> Dao<br>
>><br>
>> Marco Bonardo schrieb am 22. Dez 2015 15:17:<br>
>><br>
>> > Naming the pref "temporary" would solve a part of the problem, but I<br>
>> think<br>
>> > it still has some downsides:<br>
>> > 1. non-tech could just keep following the tutorials and really not care<br>
>> > about the pref name<br>
>> > 2. temporary could also be interpreted as if the feature is enabled<br>
>> > temporarily, while we are trying to enforce the opposite<br>
>> > 3. non-english users could not understand what temporary means in this<br>
>> > context<br>
>> ><br>
>> > I was thinking something more similar to what Gijs suggested, so a code<br>
>> > flag, not yet sure in which form though.<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>
>><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>
_______________________________________________<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>
</div>