Click to play, the next big problem for many smaller companies

Richard Bateman richard at batemansr.us
Tue Aug 27 21:43:39 UTC 2013


Greetings,

First, the tl;dr section; please read on for my reasing, background, and
probably a tiny bit of venting frustrations.:

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.

Users of our website will see this when they go to scan an exam with the
plugin: http://cl.ly/image/0h343L0t221D

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.

Read on for my background and why I'm so frustrated with this.

-------

Full version:

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.

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.

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.

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.

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.

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:

http://cl.ly/image/0h343L0t221D

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.

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.

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.

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.


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:

1) Plugins that are just noise, that aren't important to the use of a page,
that can be safely blocked

2) Plugins that are critical to the use of a page.

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.

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.

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
https://downloads.gradecam.com 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.

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.

I beg you, please consider one of the following paths:

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.

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.

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.

- Richard Bateman
FireBreath Development Team
GradeCam Development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20130827/1871ff38/attachment.html>


More information about the firefox-dev mailing list