<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi, Gavin. Sorry if this is coming
across as hostile; I'm not trying to pick on you.<br>
<br>
It's my long-held belief that if there are problems in a software
organization, they're systemic; individuals are doing the best
they can.<br>
<br>
On 08/16/2013 08:20 AM, Gavin Sharp wrote:<br>
</div>
<blockquote
cite="mid:CAHBT5m0J6Za9-3P21HHquEEFYgaREYgxiKSodeM7xQZay8wgLQ@mail.gmail.com"
type="cite">
<pre wrap="">On Fri, Aug 16, 2013 at 3:15 AM, William Pietri <a class="moz-txt-link-rfc2396E" href="mailto:william@scissor.com"><william@scissor.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Ok. So it is fair to say that no data was used in estimating the impact of
removing this feature?
</pre>
</blockquote>
<pre wrap="">
No, I don't think that's a fair characterization, though it depends
somewhat on what kind of "data" you mean. Experience shipping
software, insight from user research (see e.g.
<a class="moz-txt-link-freetext" href="https://blog.mozilla.org/ux/2012/12/distributed-qualitative-analysis-for-the-firefox-behavioral-segmentation-study/">https://blog.mozilla.org/ux/2012/12/distributed-qualitative-analysis-for-the-firefox-behavioral-segmentation-study/</a>),
and expertise combined with anecdotal data can often be surprisingly
sufficient for making the right decisions. But these things are very
frequently discounted entirely, because they always involve some
degree of subjectivity. They can also be subject to bias, but probably
not more so than "hard" data (or our interpretation of it).</pre>
</blockquote>
<br>
I agree that when intuition is what you've got, that's what you
should go with. But in this case, by "data" I mean what is
traditionally meant by the word: reliable numbers.<br>
<br>
So in this case, it sounds like there was no data available to you,
so you made an expert judgment call. Is that fair to say?<br>
<br>
<br>
<blockquote
cite="mid:CAHBT5m0J6Za9-3P21HHquEEFYgaREYgxiKSodeM7xQZay8wgLQ@mail.gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">Also, as to the approximate number of users affected, it sounds like you
estimated it in the range of "a lot of people", but that could be anywhere
from thousands to millions? Could it be tens of millions?
</pre>
</blockquote>
<pre wrap="">
It seems unlikely that you'll trust my judgement here, so I won't try
to convince you, but I think it quite unlikely that this had a
negative impact on millions of users. We do not know for sure, of
course.</pre>
</blockquote>
<br>
Well, it's nothing personal against your judgment; I'm sure it's
quite good, especially working from no real data on this. I'm just
trying to put error bars on the number of affected users.<br>
<br>
One way to work at this is to work backwards from impact. So if you
work this equation:<br>
<br>
<blockquote># of users who use this feature *<br>
% of users who have upgraded to FF23 *<br>
% of upgraders who consciously recognize the breakage *<br>
% of recognizers who bother to search *<br>
% of searchers who find what happened *<br>
% of those people who find the add-on *<br>
% of people who bother to install the add-on =<br>
538<br>
</blockquote>
You can try your own percentages, and they'll probably be more
correct than mine, but when I play with this I get pretty large
numbers.<br>
<br>
So from that, it seems fair to say that the number of affected users
is thousands to millions, but tens of millions is out of bounds,
yes?<br>
<br>
<blockquote
cite="mid:CAHBT5m0J6Za9-3P21HHquEEFYgaREYgxiKSodeM7xQZay8wgLQ@mail.gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">But I'm puzzled by what you write. I thought the theory of this feature was
that people with hijacked url bar search needed to control that so much that
it was worth killing a feature. But if most people can't discover the search
bar dropdown, how is this solving the problem?
</pre>
</blockquote>
<pre wrap="">
The feature was beneficial in two ways:
- it consolidated search settings and removed the use of a preference
(keyword.URL) that we have evidence was being widely abused. This is
the primary source of hijacking-protection.
- because the search settings were consolidated and are all controlled
by user-visible UI (the search bar), in any remaining cases where a
third party changes your search settings non-maliciously, users now
have the ability to easily revert it without having to resort to tools
like <a class="moz-txt-link-freetext" href="https://addons.mozilla.org/en-US/firefox/addon/searchreset/">https://addons.mozilla.org/en-US/firefox/addon/searchreset/</a>
Lack of discoverability of the search bar dropdown only negatively
impacts that second benefit, and while it might mitigate it somewhat,
overall the impact was still positive (some users do know how to use
the dropdown).
</pre>
</blockquote>
<br>
Could you help me understand how the first benefit is different than
the second? I'm not seeing any lasting user benefit to point 1 on
its own; hijackers will presumably quickly retarget.<br>
<br>
William<br>
</body>
</html>