<div dir="ltr">Greetings,<div><br></div><div>First, the tl;dr section; please read on for my reasing, background, and probably a tiny bit of venting frustrations.:</div><div><br></div><div>Hi.  I'm new.  Click to play makes sense, but the (lack of) user interface for letting users know that a plugin has been blocked when the plugin starts hidden lacks anything resembling discoverability and is likely to cost us a lot of money in terms of time to come up with *hacks* to detect what is happening and attempt to explain it to our users -- as well as the users of our partners who also use our plugin.</div>

<div><br></div><div>Users of our website will see this when they go to scan an exam with the plugin: <a href="http://cl.ly/image/0h343L0t221D">http://cl.ly/image/0h343L0t221D</a></div><div><br></div><div>There is no discoverability at all because the plugin was instantiated while it was hidden; further, some functionality of the plugin is often used when the plugin is hidden, so even if you fixed what I consider to be a bug in click to play that keeps it from noticing that the object tag is now visible and show the "activate" icon it only helps and doesn't fully solve the problem.</div>

<div><br></div><div>Read on for my background and why I'm so frustrated with this.</div><div><br></div><div>-------</div><div><br></div><div>Full version:</div><div><br></div><div>I normally avoid jumping onto a mailing list and just starting a thread without waiting to get a feel for it, but I just tried out the latest FireFox 26 and the click to play is going to have a serious negative impact on our business and I don't think that I'm alone.</div>

<div><br></div><div>First a quick introduction for those of you who don't know me; I've spoken with some of you in the past.  I am the primary author of the firebreath plugin framework; hopefully that doesn't bias too many of you against me =] I know better than most what kinds of problems can be caused by plugins that are poorly written or downright malicious.</div>

<div><br></div><div>Because I use plugins, I haven't been very excited about Click to Play since I learned about it, but because I understand the dangers I accept the need.  I haven't been too concerned because I was given to understand that it would still have a clear UI that allowed users to choose (hopefully only once) whether or not to use the plugin on a given website, and I figured that once they clicked "allow always" or whatever things would continue on; might generate some support calls, and not at all excited about the inevitable bunch of users who couldn't figure out how to click a button, but no big deal.</div>

<div><br></div><div>Unfortunately, I just downloaded Firefox 26 nightly, and I'm trying very, very hard not to overreact in response to the initial terror that filled me when I first tried our website on it. </div><div>

<br></div><div>The company I work for is GradeCam -- our plugin provides an interface that reads multiple choice bubble answer sheets with a camera as well as interfacing with many gradebooks to allow exporting of data directly into them for the convenience of those teachers.  We estimate around 50,000 teachers in the US are using our plugin and that number is growing very rapidly. We are partnered with most of the major providers of online teacher resources such as gradebooks and assessments and we have a lot more partnerships in the process; in short, while it may not seem like a lot in the global scale, there are a *lot* of people in the education industry that are using our plugin, and most of them are not power users.</div>

<div><br></div><div>The problem we have with Click to Play is not just that it blocks our plugin -- as long as it's easy to unblock, that's something we can work with.  Unfortunately, it *isn't* easy to unblock.  Or rather, it might be, but I would bet a months pay that 90% of our users would never find the button you have to click in order to enable the plugin.  Let me show you what they'll see when they go to scan an exam:</div>

<div><br></div><div><a href="http://cl.ly/image/0h343L0t221D">http://cl.ly/image/0h343L0t221D</a><br></div><div><br></div><div>Note that in order to provide a fast user experience we instantiate our plugin essentially hidden and show it when it's needed.  Thus the black box with no click to play UI in it.  This could be *helped* if click to play would detect that the plugin moved and put the UI back in, but some of our functionality (the gradebook transfer) is used while the plugin is invisible, and this would still have the same problem.</div>

<div><br></div><div>I completely understand the reasoning behind click to play; I understand why you want to have it block plugins by default (though it still ticks me off that there are exceptions for flash but not for anyone else).  What I don't understand is why there is *no visually noticeable or discoverable way* to see that the plugins are blocked or know how to turn it on.</div>

<div><br></div><div>I don't consider myself to be bad at learning new UIs, but even when I was looking for a way to turn the plugin back on it took me quite awhile to find it. Our users will *never* see that little blue lego icon; even if they did, they wouldn't know what to do with it. That means that we now get the exciting "opportunity" to try to educate not just all of our users but all of our partners' users as well.  </div>

<div><br></div><div>Yes, we can probably figure out using javascript that the plugin is being blocked (or failed to load for some other unknown reason, which will doubtlessly cause more fun issues to track down on some user's computers).  My point is that it doesn't make any sense that we should need to, and that doing so in a way that is clear to the users will require a lot of work and maintenance, particularly since firefox (like all applications) has a tendency to change its UI so pictures become outdated quickly and are operating system dependent anyway.</div>

<div><br></div><div><br></div><div>The thing that baffles me is that the whole issue could be rather easily solved by just having a more visible indication pop up *at least* the first time that a plugin is encountered on a page; maybe a popup, a top bar, or something.  In my experience, all plugins will fall into one of two categories:</div>

<div><br></div><div>1) Plugins that are just noise, that aren't important to the use of a page, that can be safely blocked</div><div><br></div><div>2) Plugins that are critical to the use of a page.</div><div><br></div>

<div>Why are we assuming that all plugins fall into category 1? As a user, I would much rather occasionally have a bar pop up that says "hey, this plugin wants to run, allow or block?" and maybe a "don't ask again" option.  Heck, I don't care what it looks like, but there needs to be *some way* that the browser indicates to a user that something happened.  Most users won't even realize that the icon is there -- it looks like part of the SSL information icon, and I think we can all guess how often anyone pays attention to that. </div>

<div><br></div><div>Do you realize that you're showing more information when a popup is blocked than you do when a plugin is blocked?  I realize that you aren't all big on plugins, and I know that you'd love to make them go away -- the problem is, there is no way to do the things that we need to do without a plugin.  Even if javascript were fast enough for the image analysis we do, firefox can't access some of the cameras we have to support and our gradebook export wouldn't work. Plugins will always be needed whenever interfacing with something new or non-standard is needed -- they aren't going away.</div>

<div><br></div><div>Finally, the fact that the well-hidden option to unblock a plugin only works on a per-site basis means that this whole thing is twice as big of a problem as it already because we do all of our installs on <a href="https://downloads.gradecam.com">https://downloads.gradecam.com</a> and then redirect the user back to the partner site that is using it.  First of all we'll have to somehow deal with walking the user through enabling the plugin, but then we're also going to have to have them do it again once they leave the sphere of our control and return to the calling site. I guess we could try to "talk" them through unblocking it through the add-on manager; that might be the only good option.</div>

<div><br></div><div>If you go ahead and deploy this without any changes it is going to cost us money; the first thing we'll have to do is recommend that schools just don't use Firefox, since doing so will increase both our support costs and theirs as well. Even when you explain it to them most teachers will not find the interface as it is, it simply isn't discoverable.</div>

<div><br></div><div>I beg you, please consider one of the following paths:</div><div><br></div><div>1) My preferred solution would be to allow some way that we can submit a plugin to be whitelisted like flash is.  I realize that we're not as big as adobe and don't have as much money; I'm afraid I can't bribe, threaten, or cajole you into it, but this would be the most even-handed way of doing it.</div>

<div><br></div><div>2) If you won't consider that, then *please* at least add some discoverability to the UI when a plugin is blocked.  Consider doing it the same way you show when a popup is blocked.  Also, fix the bug so that if the object tag moves and/or becomes visible it will show the "Activate" UI.</div>

<div><br></div><div>It may seem like I'm making a big deal over nothing, but the issues we are having only underscore the issues that hundreds of companies who use firebreath are no doubt going to be having as well.  Thank you for your consideration.</div>

<div><br></div><div>- Richard Bateman</div><div>FireBreath Development Team</div><div>GradeCam Development</div></div>