<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 4/3/13 7:53 PM, Richard Newman
wrote:<br>
</div>
<blockquote
cite="mid:5240A640-2BE7-49C9-A76F-7CF06C7E1EE4@mozilla.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
Nice!
<div><br>
</div>
<div>Comments, some of which are kinda core semantics, so I'll
dive in despite the edge case caveat:
<div><br>
</div>
</div>
</blockquote>
Thanks for the feedback anyway :)<br>
<blockquote
cite="mid:5240A640-2BE7-49C9-A76F-7CF06C7E1EE4@mozilla.com"
type="cite">
<div>
<div> I'd say "on this page", rather than "on the page",
especially if this is a one-time deal. But both wordings are
in conflict with "Trust Site", so there needs to be some
clarification there: if I click "Trust Site", is every page on
<a moz-do-not-send="true" href="http://gaming.com">gaming.com</a>
allowed to run Flash, or just this page? In other words, is
"Trust Site" actually "Always allow this page to run Flash
plugins", or "Always allow <a moz-do-not-send="true"
href="http://gaming.com">gaming.com</a> pages to run Flash
plugins"?</div>
</div>
</blockquote>
What we'd like to happen is that the entire site (not just the page)
gets to run the plugin. Actually, for the one plugin case, my
message goes something like: "Allow gaming.com to run "Unity player"
", which removes ambiguity. I think for the multiple plugin case, I
added the "on the page" clause so that the user wouldn't allow
random plugins to run. But perhaps saying something like: "Allow
gaming.com to run these plugins:" is understandable enough.<br>
<blockquote
cite="mid:5240A640-2BE7-49C9-A76F-7CF06C7E1EE4@mozilla.com"
type="cite">
<div>
<div><br>
</div>
<div> There's a multiple-entry problem here. If I allow <a
moz-do-not-send="true" href="http://gaming.com">gaming.com</a>
to use Silverlight, and next time I visit it includes both a
Silverlight plugin and a Flash plugin, what happens? Do I see
the dialog again? Which boxes are checked if so? Perhaps we
need a "Previously allowed" annotation to stop users
accidentally undoing a previous election?</div>
</div>
</blockquote>
Yes, I've thought about this a little. It's a pretty hairy problem
:) <br>
<br>
Here's what I was thinking:<br>
* In most cases, we only ever show the doorhanger automatically
once. (the likely exception is when there's no in-content UI, though
I'm still thinking about this behavior)<br>
* If the user clicks on CTP'd in-content UI, the doorhanger is
displayed.<br>
* The state of the doorhanger reflects the current state of plugins
on the page.<br>
* The plugin from the in-content UI that the user has clicked is
*also* checked (because presumably, this is why the user has clicked
on that UI in the first place!).<br>
* Whichever action the user chooses (Trust vs. Allow Once) becomes
the state of all plugins on the page.<br>
* If the user clicks out of the doorhanger without selecting an
action, his current preferences are maintained.<br>
<br>
I know that this might perhaps lead to undoing the state of a
whitelisted plugin, but I'm working with a couple of assumptions:<br>
* most users will generally choose an action that they intend to
apply to all plugins. The advanced user can tweak to their delight
in the add-ons manager.<br>
* The UI is designed so that the user can easily change the setting
if he's made a mistake. He just has to click on the CTP icon again
and change his selection.<br>
<br>
I played around with having a dropdown menu for each plugin where
the user could specify behavior for each, but it was getting pretty
miserable, for not a lot of payout :) <br>
<br>
One thing that you didn't bring up that I'm trying to figure out:
What is the behavior when the user unchecks all of the plugins? <br>
In my wireframes, I said that the action buttons would both be
greyed out. But what triggers the change in the plugins' state then?
If it's by clicking out of the doorhanger, how to we distinguish
that action from an intent to keep the settings as is? Can we do it
so that once the user unchecks the plugin it is immediately blocked?
Or does that break the paradigm?<br>
<br>
This is one behavior I'd like help thinking about :)<br>
<blockquote
cite="mid:5240A640-2BE7-49C9-A76F-7CF06C7E1EE4@mozilla.com"
type="cite">
<div>
<div><br>
</div>
<div> For insecure plugins, should we perhaps change the
wording to be something like "Add a security exception",
rather than "Trust site"? Not only is this deliberately
discouraging, which I think is good here, but it also avoids
the cognitive blurring of <i>well, this site is insecure, but
Firefox is going to 'trust' it
</i>.</div>
<div><br>
</div>
</div>
</blockquote>
I like the reasoning, but I have to think of a shorter phrase than
"Add a security exception". "Add Exception" maybe?<br>
<br>
Just to give you context: this action allows the plugin to run long
term, but it doesn't permanently allow it. We're going to put in
place some expiration rules (i.e. if you don't visit the site for 90
days, the plugin is blocked once more). This is why I couldn't use
"Always" and had to go with something more abstract.<br>
<br>
<blockquote
cite="mid:5240A640-2BE7-49C9-A76F-7CF06C7E1EE4@mozilla.com"
type="cite">
<div>
<div> The doorhanger might benefit from a "You can change these
settings in
" or "You can get back to this by
" note, because
otherwise there's a terrifying finality to my choice,
particularly if the wording is "Allow Once" (AND ONCE ONLY,
PUNY HUMAN).</div>
</div>
</blockquote>
<br>
I'm advocating for the plugin icon to always remain in the Address
Bar so that the user can change their setting at any point in time.
It complicates the UI a little bit, but I think it's important to
allow the user to change their mind.<br>
<br>
</body>
</html>