The goal to make your site look cool, be easy for people to use, and be available for all, is a holy grail trifecta that is rarely achieved. Many times, you have to sacrifice one leg of the tripod in order to achieve your goals.
The advent of Typekit has led to a lot of websites using cool custom fonts in a way that is supposed to solve that age old problem of what happens when you design your site with a font the end-user doesn’t have. For a very long time I couldn’t understand what the big deal was, since I often read these sites from work, and their fonts were all jaggedy and ugly. Then I fired up a site from home and was astounded at the difference.
This is what I normally see when I go to TypeKit:
This is what you’re supposed to see:
I know it doesn’t look too bad, but basically what I don’t get are the nice, smooth, edges on fonts, so when I read a whole page like that, it’s hard on the eyes. TypeKit works by javascript, so arguably, it should work on all browsers with JS enabled (which is to say all modern browsers). I’m using Chrome (latest and greatest) and I get crap.
That’s from Ed Jeavons’ Beyond web-safe fonts with Typekit, which is a great article. But the whole thing is unreadable to me because of that.
So where is the break down here? TypeKit’s goal is to make their fonts work on every site, regardless of if you have the font installed on your server. Jeavons says “Typekit degrades gracefully so that anyone without JavaScript, or with a browser that doesn’t support the necessary features, will simply revert to your standard CSS rules.” If that was the case, shouldn’t I be seeing a better site?
According to TypeKit, the problem is that the sites I’m seeing didn’t make good standard CSS rules. My anecdotal evidence suggests otherwise. After all, every site I go to has the exact same problem. So I turned off javascript and went back to the site:
Now that looks like you’d expect graceful degradation! At this point, my answer is that something TypeKit does is unwelcome on my office computer. Or more likely, my office firewall. That’s a whole new kettle of fish. I can’t reasonably expect everyone to go find an office behind a firewall made of adamantium and test their site. But clearly this is not the fault of the individual site. Is it reasonable to expect TypeKit to look into this? I went on a search and found they have a cool little checker too typecheck which says I’m fine:
There’s nothing in their FAQ or help desk that mentions Firewalls having this issue, so I decided to check out Google Web Fonts. Lo and behold, I get the same problem. Some more digging and I found someone who ‘fixed’ the problem using css. My Twitter friend @cgrymala suggested I also try ClearType, since I’m on Windows XP at work. That actually helped a lot (seriously, I cannot tell you how much nicer things look) but the main problem is still there.
Where’s my problem? My problem is that TypeKit and Google Web Fonts, while they purports to be a one-size-fits-all/degrades-nicely app, are not. If you’re not on the forefront of technology, if you’re behind a firewall, if you’re on a weird setup, these things are not going to work. This is not really TypeKit’s or Google’s fault. They’ve done an amazing job setting things up so it works most of the time. At best, they could have their javascript detect browser and OS (yes, you can do these things) and if it’s IE 6 or Windows XP (for example), revert to the javascriptless version of the site.
It’s nigh impossible to solve the firewall problem. You can’t detect the firewall easily, and part of the point of them is they obfuscate who and what they are. And if the problem is a combination of OS, browser and firewall, then the best you might be able to do is somehow detect if any one of those three are on the known ‘possible’ trouble list, and shunt them off to a non-js version. And now you’ve added a lot more load to your server.
The best you can do is to avoid using these cool systems and features until they’re more supported, which is where the whole concept of sacrifice comes in. If it’s more important for you to have your site look cool than to work for everyone, you have to find a way to degrade better. For a long time I had an alert bar on my site to tell you that if you were using IE 6, you needed to upgrade. Going back further, we used to regularly make sites that said ‘Best viewed in Netscape Navigator.’ Thankfully sanity struck, web standards started to stick, and we began to design sites that looked good in most browsers.
I cannot advocate a return to ‘Best viewed in…’, but I can suggest that if you’re relying heavily on cool, cutting edge, features, you also have a printer-friendly version of your site that runs without any of the bells and whistles.
Comments
2 responses to “Website Viewability”
Hee! I had to poke your website with different user agent strings. It likes IE 2.0, Seamonkey, Iphone3, but hates Lynx. What a bigot. 🙂
Yeah, I told it Lynx was of the devil 😉 (I don’t code for it anymore. I suck!)