<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Bsmedberg and I have been talking about some of the Java CtP design
ideas I put forth in:
<a class="moz-txt-link-freetext" href="http://people.mozilla.com/~lco/CtP/130318%20CtP%20concepts.pdf">http://people.mozilla.com/~lco/CtP/130318%20CtP%20concepts.pdf</a> and
we thought it would be valuable to move the conversation over to
this list. <br>
<br>
Comments from Ben about the design document, and my comments inline.<br>
<blockquote type="cite">How much of the pictures on that PDF are
"visuals" and how much are just interaction designs? i.e. can we
make the iconography for insecure plugins even "scarier"? Since we
are requiring a second click, should we still have the play
triangle on the in-page icon?
<br>
</blockquote>
The images on the PDF are just wireframes, and not representative of
the final visual design.<br>
<br>
For insecure plugins, I think we wanted something close to what
Shorlander currently has, with a striped background:
<a class="moz-txt-link-freetext" href="https://blog.mozilla.org/security/files/2012/10/ctp-in-action1.png">https://blog.mozilla.org/security/files/2012/10/ctp-in-action1.png</a>,
but we can certainly work on making it "scarier" and visually
indicate that it requires two clicks to activate.<br>
<br>
<blockquote type="cite"> I'm not sure we need the automatic
doorhanger in section 1.5. What problem does it solve? Because
clicking on the plugin always shows the doorhanger <b
class="moz-txt-star"><span class="moz-txt-tag">*</span>anyway<span
class="moz-txt-tag">*</span></b>, users aren't going to miss
the "Trust Site" button like they might if a single click just
played the plugin.
<br>
</blockquote>
The main reason I added that interaction was to save the user a
click if he visits the site frequently :) Basically, he wouldn't
have to click once on the in-content message and then click a second
time to enable it; he can just click on the doorhanger. We can
assume that he wants to enable a plugin on the page based on his
past behavior without making that decision for him (since he hasn't
indicated the desire to trust the site). <br>
<br>
This is probably icing on the cake anyway, and the two clicks will
be at least tolerable for users (my guess) even if we don't
implement it.<br>
<br>
<blockquote type="cite">
<br>
I'm also a little worried about the localization of the doorhanger
text: it's going to be pretty difficult to get consistent
translation of "an insecure Java plugin" because we're using Java
as an adjective instead of a noun, which almost no other language
will allow.
<br>
</blockquote>
Ok, good to know. Who should I talk to to get some sense of best
practices for localization?<br>
<br>
<blockquote type="cite">
<br>
Finally, I keep thinking about the behavior for unknown plugins,
and I've been wondering about something like this:
<a class="moz-txt-link-freetext" href="http://cl.ly/image/0G0u1G0u0S0h">http://cl.ly/image/0G0u1G0u0S0h</a></blockquote>
<blockquote type="cite"> By default, we'll interrupt users per-site
with a doorhanger which doesn't self-dismiss, and the default
option will be to allow the plugin per-site. Even if the user
dismisses the doorhanger, clicking on a plugin will not play the
plugin, but instead will show the same doorhanger. Only if the
user chooses "I will click to play" will we switch over to the
current click-to-play UI. Users can choose these same states
(always/ask-per-site/click-to-play/disabled) in the addons
manager.
<br>
</blockquote>
Nice wireframe hack :) Just to be clear, when you say "Unknown
Plugins", do you mean plugins besides the major ones (Java, Flash,
Silverlight?) i.e. the "long tail" of plugins?<br>
<br>
Also, I'm presuming we want these plugins to look different from the
"vulnerable plugin" case?<br>
<br>
From what I can see, your design has the following UX consequences:<br>
* The user is interrupted once about the plugin, and never again for
the site (unless they change the default)<br>
* The design reduces the chance that the user will unwittingly allow
harmful plugins because they have to explicitly allow it.<br>
* Worst case scenario: a new Firefox user might be interrupted
multiple times during a session to enable plugins on different sites
(might not be a big risk, and if it is, we can find some mitigating
strategies)<br>
<br>
In general, I like where this is going. I think some of the
interactions are a little bit confusing, but I can iterate on those.
For example, I think users will have a hard time understanding the
"I will click to play" interaction because it requires them to
intuit that they need to click on the particular in-content plugin
in order to enable it. It would be better if they could enable
plugins from the doorhanger directly since we're displaying it
automatically anyway. <br>
<br>
I'd also consider whether "allow for a long period of time" should
replace "allow always"-- this could provide additional mitigation
against clicking-through. <br>
<br>
Also, I like the phrasing of the arrow panel string because it makes
it clear to the user that he's allowing a specific kind of plugin on
just this site (I do have a couple of tweaks to streamline the
language though).<br>
<br>
Larissa<br>
<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>