A[nother] brief argument against sIFR

In my previous rant about sIFR I discussed how regressive (and ironic?) I think it is that in an attempt to further rich type use on the web, designers are utilizing a technique which (in certain circumstances) destroys the very experience they are trying to enhance. Not only did I find other sources describing the same distaste for sIFR, but since it was published — almost three months ago — it has become the second most requested article of this blog, being found mostly through Google searches. Clearly my gripes with sIFR are not an isolated case.

Previously I wrote about how, for some reason which I have yet to pin down, when pages utilizing sIFR are viewed in Google’s Chrome browser the page will load properly, then after scolling an arbitrary distance will promptly cause the Adobe Flash plugin to crash — every time. I use Chrome as my primary browser, and because of this I've become accustomed to either skipping pages where I discover sIFR, or if I'm genuinely interested in the content, I will load the page in another browser (usually Safari) which is unaffected by this condition. It’s an unfortunate situation with an unfortunate remedy because, 1. I'm a savvy web surfer, and I believe most users will not go through the trouble I do, and 2. sIFR attracts a lot of great web designers who’s pages lose all of their luster when all of their rich type gets replaced by ugly black boxes with the 'broken plugin sad-face' graphic.

Google Chrome broken plugin 'sad puzzle piece' graphic

While browsing today I came across yet another situation in which sIFR broke my user experience. I'm a huge fan of the recent tabbed-browser trend because I like to open links in the document I'm reading inside new tabs, sometimes tens at a time, then visit those pages after I'm done with the initial document. In most browsers (and all common desktop operating systems) this can be done both by right-clicking a link and selecting "open in new tab" (or similar) in the pop-up menu, or by holding the Control key (or Option/Command, depending on OS) and clicking the link — a huge time saver.

sIFR context menu showing two options: 'Follow link' and 'Open link in new window'

Mike Davidson’s blog, showing sIFR context (right-click) menu.

sIFR attempts to emulate this functionality by providing a context menu which includes options for following a link (which could more easily be accomplished by simply clicking the sIFR block), and for opening the link in a new window. I don't want to open a bunch of new windows while I'm browsing, however. It defeats the purpose of having a browser with a streamlined tabbed interface. Technically, Chrome does have an option to open new windows in tabs instead (which I think is enabled by default), which makes this somewhat of a non-issue.

My real objection, however, is that control-clicking functionality (what I use 99% of the time) is broken by sIFR. Instead it follows the link in the current tab. Again, being an astute web surfer, I'm able to recognize and adapt to this, but I doubt the 'average' user is going to have any idea why his control-click didn't work properly, possibly leading to frustration, back-button use, retries, and further frustration.

I could nitpick the little things ad nauseum (it’s what I'm good at), but my opinion remains unchanged: sIFR (however cool and amazing it is) is bad for websites.

As a side note, Jason Santa Maria (an unfortunate target of my last gripe about sIFR) dropped scaleable Inman Flash Replacement on is website in favor of Typekit.

Leave a Reply

Common formatting HTML allowed (when in doubt use code, if it fails, I'll edit appropriately).
Always close tags.