A few thoughts:
1. True, ~1% of people on the regular (not mobile) web don't already have
Flash. BUT, of that 1%, have you stopped to consider what percentage of them
don't have flash because they've simply never been asked or have never cared
before now? I'd wager that almost all the 1% of people that don't have Flash,
don't have it for a *reason*, like their computer won't allow it, or their
sysadmin won't, etc. So, you're really not even targeting behavior for 1% of
the web, it's more like 0.1% or less. That's pretty niche.
Consider the mobile market too.... a large percentage of them don't have flash
(iOS), BUT they cannot get flash, no matter what you do. So, even trying to do
so for them is worse UX than handling it gracefully with your own "alternate
content".
Bottom line: I seriously doubt there's hardly anyone out there without flash,
who can (and will) install flash, simply because you are the first one to ask
them politely enough to do so. Those without flash probably have a reason,
which your site is unlikely/unable to trump.
Kinda the same as whining about IE6 these days. Those still with IE6 are those
who have to be, for some bigger reason, and complaining about it, or even
trying to be "cute" and prompt them to upgrade, is really often more annoying
to them, since they probably know the boat they're in, and you bugging them
about it is pointless.
2. Your "alternate content" in fact gives them the hard-stop that you're
looking for (if you design the site properly for that case). It says "flash is
missing" (because if flash is present and upgradable to your version check,
they still won't see that content). If the "flash is missing" message makes it
clear that Flash is indeed required, and that by not having Flash, they cannot
continue, then I think you've fulfilled that goal. And that's exactly how core
SWFObject is designed to work.
3. For the "make it as easy as possible to install" thing... most browsers are
de-emphasizing the idea of inline installing of extensions/plugins (security
reasons), so I think this type of behavior is definitely legacy at best. It
should be more than enough to provide a link to the download page. Odds are,
(as I said above) they probably can't download it anyway, so going to extra
effort to make it slightly more graceful is probably wasted effort. Why don't
you wait to see if you ever get even 1 single complaint about that, THEN figure
it out? Seems like this might be beyond due diligence and into premature
optimizations. Just some food for thought.
4. What you're asking for sounds more like the SWFObject static-embed
functionality than dynamic embed. Not sure which you're using, but with static
embedding, this should be fairly trivial to accomplish (with dynamic embedding,
you have to go through the ugly hoops that Aran described).
Static embedding works by you putting the <object> code (FYI: we no longer use
<embed>) into your page's HTML markup, and then calling SWFObject to tell it to
either replace that markup with alternate content (if the flash version is
insufficient) or to make sure that the embedding is correct and then let it
proceed.
If you were to include that content by itself, without swfobject.js included,
then you'd get exactly the behavior you mention, the broken puzzle piece icon
thing with inline prompting to download. If you include swfobject.js in your
page, but you don't call `registerObject()`, you get exactly the same behavior.
The problem is that once you call registerObject(), SWFObject will either let
the flash play if the plugin is there, or it will replace it with content --
not what you want.
However, you can conditionally call registerObject only if flash is present,
and if it's not present, then the markup will remain untouched by SWFObject,
giving you what you want in both cases.
So, combining the two approaches, the solution is trivial:
1. include the static embed markup (use the code generator) in your HTML
2. include swfobject.js
3. in your script code, say:
if (swfobject.hasPlayerVersion("0.0.0")) {
swfobject.registerObject(...);
}
If flash is installed and the version check passes, then swfobject will take
over the markup and do version testing for your ExpressInstall upgrade paths,
etc. If flash is not present, or the version check flat out fails (corrupt
plugin), then swfobject will not touch the markup, and the browser should take
over and do whatever it normally does with raw HTML markup for a flash object.
--Kyle
From: Aran Rhee
Sent: Thursday, June 16, 2011 3:35 PM
To: [email protected]
Subject: Re: [SWFObject] Re: Flash detection
Brad.
I'll mention your request to the team. Feel free to post a enhancement here:
http://code.google.com/p/swfobject/issues/list
I still feel SWFObject is the best library to use for embedding Flash (whether
you choose to use the degrading features or not).
Have a look at the API. I think you could use something like:
var playerVersion = swfobject.getFlashPlayerVersion(); // returns a JavaScript
object
var majorVersion = playerVersion.major; // access the major, minor and release
version numbers via their respective propertiesbased on the result of that, you
could then decide what you wanted to write to the page (embedSWF() call if they
have a version of Flash you support, otherwise write something to the page
which will invoke the standard browser download prompt process).
Cheers,
Aran
On Thu, Jun 16, 2011 at 3:22 PM, Brad Wood <[email protected]> wrote:
> So the question to your marketing guys is: what do you really want to
> achieve? Do you want to show content to your web visitors, or do you want
> them to be driven away to download something before they can view anything
> on your site?
Well, since our site has training videos and audios which are only
accessible via our Flash player (that people have paid us to have
access to), I think the answer is we want a hard stop that makes it
clear that our site will be useless without Flash. And secondly we
want it to be as easy as possible for them to know what to do to
remedy the situation. i.e. Showing a link that says 'click here to
download Flash' is a good start, but actually beginning the Flash
download right then and there is the best option. (for us anyway).
> Keep in mind that not all browsers can install a plugin seamlessly and users
> will have to download a file, close their browser, install the plugin and
> restart the browser.
Understood, but you have to break an egg to make an omelet. We
advertise that Flash is a requirement to use our site. If they are
going to have to install it, we might as well make it as easy and
automated as possible.
> As a possible solution, you could do a little bastardization and put in a
> standard object/embed in your alt content <div> (maybe a really small /
> invisible swf), which would invoke the browser download prompt... This way
> you could still show the user some useful content in the alt div, which
> invoking the download prompt as well.
Hmm, that's not a bad option.
So, I think I have my answer, and in short it is "no". I can
definitely understand the goal to degrade nicely and it does make a
great deal of sense especially if the Flash content has an alternative
method of being served or is not mandatory for the page to be
functional. I do think there would be usefulness to have a
configuration option in SWFObject where I could specify that the Flash
was required on the page, and I intended for the default behavior
(missing plugin prompt) to occur.
Of course, it's also entirely possible that I'm misusing SWFObject.
My intentions have little to do with degradation and more to do with a
cross-browser library which will guarantee my Flash content shows up
in as many places as possible, and if necessary enable the user to
procure Flash in the most pain-free way possible. If you have any
other suggestions for libraries which are more centered around getting
your users Flash, then degrading when they don't have it, then please
let me know.
Thanks!
~Brad
--
You received this message because you are subscribed to the Google Groups
"SWFObject" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/swfobject?hl=en.
--
You received this message because you are subscribed to the Google Groups
"SWFObject" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/swfobject?hl=en.
--
You received this message because you are subscribed to the Google Groups
"SWFObject" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/swfobject?hl=en.
