The other day, I decided to give sIFR a try. In case you didn’t know, sIFR allows you to embed fonts on web page, letting you choose fonts of your choice, for rich headlines in blogs or websites.
Unfortunately, sIFR isn’t all good.
Having used it for a couple of days now, I have summed up my experiences with the system.
It is quite clear that sIFR has been through a lot of development. Great effort has been put into making it work as consistently as possible, and be as easy to work with as possible.
And it is easy, and it does work great. Once in place, one simply specifies which headline to replace (in my case,
#main h1), and sIFR works its magic. This magic includes detecting Flash, analyzing headlines (including headline links), and replacing with properly sized and padded Flash headlines.
It should be mentioned, that this article is mainly evaluating in this article sIFR 2.0rc1. Thus, while it works great, it is not yet final, and some bugs / issues may be fixed or changed in the final version. Update: sIFR RC2 has been released.
I mentioned the installation process was fairly simple. This is not entirely accurate, as sIFR requires a fair bit of knowledge of CSS and semantic XHTML. When you download the current sIFR pack, you get a Flash movie called
sifr.fla, a few script files, some pre-made “fonts” and an example page (which is also viewable online). The example will work fine if you run it—the somewhat tricky part is separating out from that example, only that which you need, to apply sIFR to your page.
- Simplify the example page
- Separate sIFR CSS into an external stylesheet
- Rename “sifr.fla” to, for instance, “sifr-font-template.fla”
- Include more international characters in the default template
Currently, it looks great, but is simply too complex for basic usage. It tries to show everything that sIFR can do (which is cool), but most people will only be confused by this. If necessary, create a separate documentation for sIFR, instead of keeping this inside the code. Here, more advanced examples can be provided.
This is easy to do yourself, but everyone will do it, so why not have it this way by default?
It’s a detail, but why not speed up deployment by doing a simple rename? Few will know, by heart, what it is “sifr.fla” does, but most will identify it directly with a better filename.
I had the need for special characters such as
? ? ? ? ?, but these weren’t shown “out-of-the-box”. I had to re-do my font movie, with these characters embedded in the textfield.
Bugs and Limitations
As mentioned, the sIFR system is not all fun and games. Introducing the system to your site, will also introduce a few usability problems and inconsistencies. Most are related to sIFR relying on Flash, which has inherent usability problems. Some of these issues were also mentioned in my previous article about sIFR, but I thought I’d repeat them here in their final form.
- Dynamic (on the fly) font scaling breaks
- No visual feedback on text selection
- In some instances, links can?t be copied
- Firefox users can?t middle-click
- Rollover status bar link target disappears
- Firefox seems to have trouble with links
- Hover effects are not reset when releasing outside
If you adjust the font size using your browser, headlines won?t scale along with the rest of the text until after you reload the page.
Since each headline becomes an embedded Flash movie, text selection won’t be visually indicated by sIFR replaced headers. You will, however, still be able to copy/paste the text, including the headline.
If your header links somewhere (as in my case, to permanent archive locations), you will only be able to right-click/copy target links if you do not use an sIFR hover color.
Since the interaction behavior of Flash movies is dictated by the Macromedia Flash Player plug in, and not the end browser, Firefox users won’t be able to use their beloved “middle-click /open link in new tab” feature.
Once again, related to the headlines being Flash—rolling over links usually reveal their targets in the status bar. Not the case here.
This is most likely a Firefox bug, related to embedded Flash movies. Nonetheless, Firefox seems to show erratic behavior as to when sIFR links work. Sometimes, links require two clicks, sometimes a rollover won’t work, and won’t show a “hand cursor”. Update: sIFR RC2 fixes this problem.
A common Flash button mistake. If clicking a link, and releasing outside, the button hover state won’t be reset. This can simply be fixed using
on (release, releaseOutside).
Pros and Cons
- + Truly choosing your own fonts is great, and it looks great
- + Once it is deployed, it works flawlessly
- + It degrades very gracefully
- + It is transparent (literally) to search engines
- + Compared to other rich headline techniques, such as FIR, sIFR provides much lower file sizes
- – sIFR introduces various usability problems. See above, in “Bugs and Limitations”
- – Since sIFR is Flash, it has nonstandard interaction behavior
- – If too many headlines use sIFR, it may affect scrolling and system performance
- – If used improperly, it will significantly lower website usability (see conclusion)
I truly think sIFR is the one of the best uses of Macromedia Flash the web has seen yet. It gives power to the designer, and asks very little in return.
But it is not for all websites. The usability problems introduced by sIFR are grave, especially when used improperly. As mentioned, Flash has usability issues, including a non-standard interaction behavior. For example, copying links, selecting text and plainly right-clicking, works as defined by Macromedia, not by the browser. This is bad, and should seriously be considered before you jump on the sIFR train.
As such, consider your website audience, and how you will use sIFR, before you even consider it part of your design. Will the end users notice how much better your website looks? Will they care? Will it even make your website look better, or could you simply have chosen a Helvetica or Georgia? Also give serious thought to where you will apply sIFR. After all, it is your choice what headlines to “enrich”. As I see it, the worst usability problems lie in the link aspects of sIFR. If your site relies on people clicking on headlines to get to the content, you should seriously reconsider making those headlines sIFR. After all, you’re breaking not one but several usability rules by doing so.
I have a gut feeling many issues with Flash usability will be addreassed in Flash 8, but no-one can really know for sure. Until then, consider whether the (possible) improvements in design are worth the hassles and usability problems.
In my case, I’m loving sIFR, and I’ll definately be keeping it.