Tag: accessibility

Great Walls of Fire

If your website is ‘international’, you’ve probably already run into this. If you’ve ever worked for cooperate America, you’ve seen this happen. If you’re on an out of date browser, you’ve definitely seen it.

It’s that horrible day when your site looks like absolute crap because something critical to your site isn’t loading because it cannot be accessed from where you are.

Let’s step back.

Using Google’s Open Sans doesn’t work in China because Google is, generally speaking, blocked in China. What does this mean for people there? Well their WordPress dashboard is going to load slowly, in fact for many it’s so slow as to be unusable. This is because WP 3.8 uses Google fonts on the back-end. Now, you can disable it with the Disable Google Fonts plugin, but many people feel that’s a poor user experience.

I want to take a moment to note that while I, personally, dislike using Google for required fonts on WordPress, there was a discussion on bundling vs linking that took place in November 2013. At that time, everyone agreed bundling (that is including the fonts with WP) would be best, however how to do that was more complicated. In order to provide a good experience for all users and all languages, it got messy and large really fast. You can read up on the history on make/core: Open Sans, bundling vs. linking.

That being said, by remotely calling Google, there are two main issues: privacy (which I’m not getting into) and accessibility (that’s what I want to poke at).

We know that calling Google remotely, for everyone in a country with good internet speeds, is great as it speeds up your site! That’s the premise behind Use Google Libraries after all. If someone’s already downloaded the files in their cache for JS (or fonts), then the next site they visit will load faster if it uses the same ones! It’s a sound, and accurate, theory.

But are you making your site inaccessible with your need for speed?

What happens when someone can’t load Google? In the case of the Use Google Libraries plugin, it falls back to using WP’s standard, which is good, but that initially connection has to fail first! The same happens for WordPress’s back end, which means the time it takes to load your site is longer for those users.

I tell this to people a lot, and generally they reply “Well I don’t have users in China.” or “This doesn’t affect my visitors.” Really? REALLY? Sorry, but that is one of the most shortsighted views I’ve ever heard in the history of ever, and one I tell people “Yeah, that’s an incorrect and rather arrogant conceit.”

Let me tell you a story. I went to Japan for 12 days to hike O’Henro with my Buddhist brother and our agnostic father. We made the “A Jew, a Buddhist, and an Agnostic walk into a temple…” jokes. While there, I checked in on my websites and on my regular sites I visited, only to find out that some were blocked because we were using a net connection that went through a country those sites blocked. Why? Because “no one” who would ever visit their site was from there.

I no longer use those services, I no longer support those sites. My father goes to China regularly (he does risk assessment on the disused weapons caches in China). I turn off Google Fonts on his website in order that he, and his customers, can see the site as intended. You can tell me all you want that ‘no one’ visits from those places, and you’re just wrong, and arrogant, and yes, I strongly disagree with WordPress having made Open Sans via Google a requirement like that.

My personal dislike of Google aside, it’s a reality I look at more than I wish I had to that people and places block third parties. This is why I get on the case of plugin developers who use third-party services when they don’t have to. They’ve created an unnecessary dependency on this other service, which will crazy to debug when someone says their code doesn’t work.

Your code should be as self-sufficient as humanly possible. Offloading for ‘speed’ doesn’t work for all situations, and instead can make things slower by causing more external resources to load. Have you ever looked at those scan reports where they say your site calls too many sites for JS or CSS? This is what you’re doing. Even though it increases the odds that people who can get to these sources will already have the files cached, people who can never access them have a worse time. And then loading them locally will make your site heavier and load slower, unless you use proxy-caching (like Pagespeed or Varnish).

It’s not a perfect solution for everyone. This is why websites are hard.

7 March, 2014
Font Size Matters
I’ve been complaining about this for years.

I wear glasses. Thick, coke-bottle, I have an astigmatism so bad any time I get a new eye-doctor, they tend to boggle that my eyes are as healthy as they are being as crap as they are. No, I’m not legally blind, but I am wearing glasses any time of the day I want to see.

Amusing anecdote time. I did acting as a kid, and I used to not wear my glasses for it. My mother was always terrified I’d fall off stage not being able to see it, but I actually can make out some things. The color on the edge of the stage was enough, and I also counted my steps. I’m great with walking around at night, no glasses, to go to the bathroom. But the point is if you find pictures of me above the age of three, I’m wearing glasses. Before that I could see ‘enough’ that I didn’t want to wear them, but afterwards, I gave up and only took them off for official pictures. Now I argue “No one will know me without my glasses” (something I proved in High School when I wore contacts and a dress to a fancy party and my boyfriend didn’t recognize me).

So I have bad vision. And for years I would CMD++ to make the WordPress admin readable. It was just too small for me. I’d complain to people, I’d make my own admin skins, and I’d beg UX/UI people to put it on their radar. When MP6 came out, I rushed to install it because the subtle font increase and style change made everything readable for me.

Here’s an example from Pippins Plugins. Now, Pippin’s my friend and co-plugin-reviewer. I love his work. His site is just a wee bit too small for me:

Pippin’s Normal Size

Pippin’s +1

Pippin’s +2

Generally I’d like a +1.5 view for his site, and bless his heart, the whole site scales wonderfully when I do increase the size. But I find his default font size (13px) is just a smidge too small for me, and a 14px is so much easier to read long term. The same thing happens for me on WordPress.org’s support forums

For reasons of this ilk, I use a Chrome add-on called Stylish to force font sizes (and layouts) where applicable.
```
#subscription_checkbox {
display: none;
}

#pagebody {
font-size: 14px;
}
```
The first one is to hide that blasted subscription checkbox (which I never want to check), and the second makes the page body size 14. Suddenly it’s all legible for me! And yet, on the occasions where I’ve point out that the font’s a bit small, the masses all tell me “Oh but I can read it fine!” I know as the age of developers creeps up and more and more people end up having less than perfect vision, things will skew up somewhat.

Except the odds really are they won’t. As we get older, we bring in younger, and the cycle will remain. And this makes me wonder if there will ever be a point at which we have a medium where the folks with great eyes and the ones with poor ones are both happy.

I’ve heard tell that 16 pixels is the best but really the perfect thing is 100% easy to readability. And that’s where I think that we’re still failing our readers.

Font sizes really are still too small for a lot of people, and the WordPress dashboard is certainly not innocent. If it was, I wouldn’t have had to write an mu-plugin that does this:
```
/* Dashboard */
.postbox .inside,
.stuffbox .inside,
#the-comment-list .comment-item h4,
p, .wp_attachment_details label[for=&quot;content&quot;],
#dash-right-now .sub p,
.wp-editor-area {
	font-size: 14px;
}
```
Yes, that’s what I have to do to make the dashboard readable. And no, I don’t think ’14’ is too large. It scales nicely on my iPad and my iPhone, and my desktop. But I know I won’t win this fight for a long time, so I’m going to take what I can and celebrate than MP6 is making WordPress at least a little easier to read for me.
17 January, 2014
Simply Complicated

I’ve been playing around with Tumblr a lot, mostly to help a friend get set up on it, but also because they didn’t publicize they had a way to ‘black out’ your site for SOPA day until the last minute, and I wanted to help my friends join in.

Tumblr pitches itself as sort of a blog version of Twitter.

Tumblr lets you effortlessly share anything. Post text, photos, quotes, links, music, and videos, from your browser, phone, desktop, email, or wherever you happen to be. You can customize everything, from colors, to your theme’s HTML.

At it’s heart, it sounds really wonderful. You can share anything, as long or as short as you want, with anyone. They can retumbl it and share it, adding on their commentary, and so on and so forth. But when you compare it to either Twitter or a blog, the analogy collapses and Tumblr becomes insanely complex. By trying to be both, it’s effectively neither.

The tl;dr for this post is that I don’t like Tumblr, and find it a clunky, poorly supported psudeo-blog and you should use something else.

I should say that there are things I think Tumblr gets right. They make it very easy to publish your content with a few clicks. Uploading media is simple, and ‘reblogging’ content is a simple click. However that’s only true if the content comes from Tumblr to begin with, or if the external source has coded in a ‘tumble’ button (similar to the tweet/facebook buttons I have here). Tumblr can make a decent ‘community,’ however allowing multiple people to manage a Tumblr site is cryptic.

Logging In

When you go to tumblr.com, you’re presented with a signup screen:

That’s it. A very simple and direct screen, much more like Twitter.com than something like LiveJournal or WordPress.com. You’re told ‘Sign up.’ But what if you’ve already signed up? Unlike LJ or WP, there’s no bar at the top of the page to let you sign in anywhere.

On Tumblr, tucked way off to the upper right, is a little Log in button. Points for not making the word ‘login’ (though that is a valid use), but it’s not where people generally look first. Jakob Nielsen has been touting the F-shaped reading pattern since 2006. That is most of the weight of a reader’s attention is to the left, though the top right corner is a good place to use too. At the same time, horizontal attention still leans left. So while the location is decent, the button’s efficacy strikes me as diluted.

The Dashboard

Once you’ve logged in, you go to the Dashboard. This is pretty standard stuff. If you log in to WordPress, Blogger or even LiveJournal, you go to the back end. On the other hand, if you log in to Twitter, you see your Twitter stream. In keeping with Tumblr’s dichotomy, you get both:

The green icon is ‘me’ and right away I see that someone’s started following me, and two people I follow (CBS Television Studios and a friend) have posted something. Above that is a list of ‘types’ of posts I can make, and on my right is basic information about me. I follow people, I’ve liked posts, I can explore, and here’s a random photo we like.

It’s not terrible, and the implication is ‘Just start posting!’ At this point, any time I go back to tumblr.com, I will be sent to my dashboard. Period. And there’s no obvious link to show me what my site looks like. As it happens, I have to click my ‘icon’ (the green box) to see my site. The row on the very top has ‘Dashboard’ and then ‘My blog name’ (which I fuzzed out) and ‘My second blog name’ (ditto), is followed by four icons. The plus sign makes a new blog, the question mark is for help, the grommet is for settings and the power button is to log out. I don’t know why they have ‘make a new blog!’ so prominent.

Posting

I’m not going to get into how you post in detail. This is pretty straight forward and my only real complaint is tags, but it’s a big complaint.

I can’t see my commonly used tags, and that actually bothers me a lot. On WordPress, I can see my regularly used tags (and my categories) right away. With this simple screen, I get a blank area to add in my tags, which is nice, but I like to use some of the same tags over and over. It’s at the point where I’ve stopped tagging things because it’s a hassle. That’s a problem because other people can search for ‘tagged Ipstenu’ and find anything tagged that way. I’m devaluing the search because the functionality as a content create is onerous. Compare this to WordPress, where I can click on ‘Recently used tags’ and there the ones I use are, and I can click on them to add them. Done. Categories are easy to find and now I’ve created a robust multi-level way to search for content on my site!

Furthermore, if I reblog something, I lose all their tags and have to start over.

The Other Dashboard

Well, now here’s where it’s a mess.

My blog names were listed on that top row, so when I click on one, I get another dashboard. This one is very similar to the first, only now I see all my reblogs and all comments.

Oh, wait. No. I don’t see any comments. That’s because Tumblr doesn’t have an easy way for my visitors to leave comments on my site!

What’s going on here? It’s Tumblr’s dichotomy. It’s both a social site, like Facebook and Twitter, and a blog, except right here, in this one moment, it’s magically neither. Facebook lets you leave comments, Twitter lets you leave @-replies. WordPress (and LiveJournal) live and die by the comments. Comments are how you connect, interact, and grow your audience.

And you can’t do it (easily) on Tumblr. Oh, sure, I figured it out in about an hour, with a tweet to a friend and some reading about Disqus, but that’s not the point. You cannot be a blogging system without a comment system. That may be a strong statement, but there it is.

You’ve heard people say that if you’re not paying for something, then you’re the product? That’s never more true than with Tumblr. On this site, my content is generated by me, and the additional UGC (User Generated Content) comes in the form of comments. I can see my ‘value’ based on retweets, +1s and likes, but it’s in communicating with you commenters (and I try to talk to everyone) that I find out what’s engaging in my posts, what’s important, and what I get wrong. Oh yes, I get things wrong.

It’s talking with people that help me grow as a writer, a technologist and a thinker. So while some themes on Tumblr have Disqus built in, I’ve found more that don’t and more that don’t explain it. And worse? If you google ‘Tumblr comments’ the first hit is not a ‘How to turn on comments on Tumblr!’ from Tumblr, but a how to from Disqus.

There’s nothing wrong with Disqus, I like it and use it on some sites. But. There’s something wrong when your communication platform relies on third party vendors for communication. Sharing? No problem. Communicating? You better be a techie.

Where are those settings at?

And now we’re at the crux of why Tumblr is so cumbersome.

Where the hell are my settings!? If you go click on that gear icon, which is logically at https://www.tumblr.com/preferences, you may notice everything’s about you. It’s your user preferences. Okay, so that’s acceptable. And they even put a nice link to customize your blog. But … have you looked at their options?

This is where I wanted to get a screenshot of the clunky ‘pick a theme’ interface (though they get small props for being able to select ‘free only’), or how you have to know how to edit HTML/CSS to customize and add ‘pages’ to your site, or how you don’t see how your content will look, only their sample. I tried to get a screenshot, but it was too complicated to even begin to explain.

And that’s the problem right there. Tumblr’s too hard to customize for the novice. It’s not too hard for me, I have no problem with it. But my partner (a non-tech) and my friends (non-tech) all appealed to me for help around SOPA day to make their sites go black. It took me 10 minutes to sort out how to make a WP.com site go black by adding a widget. It took me 10 minutes to find a plugin I liked for self hosted, fork it to what I wanted, and implement it. I was able to logic out how to apply my wp.com change to Blogger (via a ‘widget’) and Tumblr, but the minute I told the Tumblr’s “You need to edit the site’s HTML…” they balked.

So what’s really the problem here?

The problem is Tumblr’s attempt to be the best of both worlds, a blog and a social networking site, means they offer up more customization then that of a traditional blog, but less that running your own site. Twitter has very little customization you can do, but really it’s like saying you can’t design your email. Few people I know actually go look at your Twitter page. We use apps, or aggregate you onto own own streams. It doesn’t need it, and wisely leave it alone. WordPress.com (I’m harping on them because I know them best) lets you use themes that allow customization, but you have to pay for CSS or a custom domain. Tumblr lets you do these things for free.

Now, to be fair, Tumblr doesn’t claim to be a blog. And they’re right, they’re not a blog. What they are is a way to make a share things. Easily. And you know, to that end, they succeed. It’s very easy to share. What is not easy is to stand out from the crowd, use Tumblr in a new and amazing way. What’s not easy is to be unique.

I’ve seen memes, photoblogs, Q&As, and mostly just people sharing posts. I’ve seen amazingly creative designs. What I haven’t see is something that changed the entire way I’ve thought of publishing. And I haven’t seen it in a way that let me grow, adapt, and spin off it as far as I want. I don’t want to get this confused with beautiful sites like capitolcouture.pn, which is just lovely. But it looks … like a webpage. I can think of ways to do that on any platform. In this case, though, they picked Tumblr I would guess because of the ease of re-sharing content. They exist with a massive amount of user generated content, by copying the posts to their own site (with a link back of course). That’s cool, but it’s not a game changer. In it’s own way, it’s just the best designed meme I’ve ever seen.

Have you seen a site on Tumblr that made you re-think everything about a website?

7 February, 2012
Community Driven Design

WordPress 3.3 is on the horizon, and already there’s a minor kerfluffle over the flyout menus. Regardless of if you agree with the change or not (I do, Otto does not, for example), it brings to mind the reality that every time there’s a new change to the Admin UI, someone demands to know ‘Who’ requested the change. One time, the answer was ‘Matt.’

While WP is open source, and that means it’s community driven, that’s only to a degree. Remember, at the end of the day the folks with commit access are the ones who decide what they want to support and have in their app. Theirs. WordPress isn’t a Democracy, it’s at best a parlimented monarchy, but really more of a benevolent dictatorship. This is neither good nor bad, when you put it in perspective, and I’m afraid that with products, especially free and/or open-source products, we as a user base consistently lack that perspective.

The company I work for recently switched to Office 2007. Yes, I want you all to take a moment to reflect on the fact that we didn’t move to Office 2007 until it was 2010 (and didn’t finish until summer 2011), it’s important. The reason we didn’t switch sooner wasn’t for anything technical. In fact, we really wanted to switch so we could upgrade SharePoint and have functional integration. No, there were no app conflicts or weird database issues preventing the upgrade. It ran on our operating systems without issues. But why didn’t we upgrade? Because some of the people in “very important positions” had trouble with it, and we were concerned that the UI change, which was rather dramatic, would overwhelm our help desk.

To put this in perspective even more, there are about 20k employees at my company (give or take, I’m not counting consultants here, or non-computer-using people). Of those, about an eighth are what I’d call techies. That is, maybe 2500 of us are really nerdy people who use foam swords or even know who Stallman is. Another 2500 of us are technically inclined, and capable of trouble shooting the basics. Another 2500 are smart enough to know how to explain their problem to the techs. That means over half the company are ‘real users,’ you know, the ones we make fun of for deleting DLLs that are taking up space, or who reboot their monitor. Every time we make a change to software used across the entire company, we have to put that 50% clear in our minds. How will this affect them? What training to we need to provide? We’ve pretty much accepted that no change will be universally accepted, and at a certain point we have to agree that this is ‘good enough’ for people, and deal with the fall out.

Coming back to Open Source, when a project like WordPress or Drupal makes a major change someone’s going to hate it. This is just the way of the world, and even if you love the change, you need to work to make sure your replies to these people aren’t ‘haters gonna hate!’ or ‘you suck!’ Neither of these are productive. Part of the problem here is that people get passionate and sulky, like a nine year old who viscerally dislikes something, but lacks the language to fully explain it. This is not to say people are incapable of explaining themselves, but that part of their problem is the ephemeral ‘feeling.’ The other major part of the problem is that no two people hold a hammer the exact same way. And of course that people who are complaining at the ‘beta’ stage of the product are in too late.

Understanding how these designs get made goes a long way into making people accept changes they don’t agree with. It doesn’t make them like the changes, but understanding how and why they happened can get you to the ‘agree to disagree’ point. John O’Nolan (who currently is living on the road by choice) wrote an amazingly informative post about how he got involved in WordPress UI back in the 3.0 days. He lays out how you can get involved more, if you’re inclined. There’s a great Make WordPress UI P2 blog, and of course WordPress Development blog that you can follow along to see what’s going on and there’s always looking at the tickets in Trac flagged for Needs User Experience/UI Feedback, but I’ve found the first way you should get involved is to start using WordPress trunk: the live latest and greatest, but not ready for prime time players, version.

That seems like a departure from theme, but it’s not. We all start out as basic WordPress users. We use the product, we know how to add/edit/remove posts, we move on to using plugins, and eventually we hit a wall. Either we start to adapt and become power users, who understand how to tweak things in wp-config.php, play with SSH/FTP, and make a quick child theme, or we resign ourselves to using WordPress as it is presented. Neither use-case is better or worse than the other. If you’re a ‘hard core’ WordPress user, though, you will find yourself wishing for small fixes, and you’ll make a plugin for yourself. Then you share it, and then you start to suggest things in the forums, or report bugs in trac. Now we’re cooking with fire, and it’s not long before you start tossing out code or css ideas for trac.

The point of this is that if you start ‘testing’ the new versions of WordPress at the beta or release candidate iteration, you are too late in the game to make a UI comment. The Beta and RC releases aren’t for making drastic changes, but for making the changes that are in there work correctly. Like how the ‘close’ button on the admin bar pointed isn’t working on IE 7 or 8. That’s a bug. But not liking the admin sidebar menu flyout and disagreeing with it entirely isn’t a bug. Did you know the head of the UI team didn’t like the Admin Bar back when it came about?

You don’t have to like everything about a product to use it, and sometimes changes mean you need to rethink how you use it. Also, WordPress has a policy similar to Apple and Amazon: Release, then iterate. That’s why in the last three releases of WordPress, we’ve had one major change and two noticeable tweaks to the whole admin UI. The 3.0 release was a huge overhaul, and in both 3.1 and 3.2 (and now 3.3) we’ve had significant variations on a theme. They feel big, but compare it to the 2.9 to 3.0 jump and it’s really pretty small.

If you want to guide WordPress’s UI, get in on it earlier than beta. If you want to iron out bugs, join at Beta, but take the time to learn the difference between ‘I don’t like…’ and ‘this is broken….’ If you want to get new features early, join at RC. If you want to wait till we’re ready to go, wait for the final release. If you just use WordPress and trust that most everything will work, use the final releases. If you’re annoyed that little bugs get missed, use RC. If you know you’re using a fringe case, or setup that uses normal WordPress but on an obscure server or configuration, RC or Beta is where we need you. Remember, not everything can be tested, but you can help test more. However. If WordPress is your life, if you live and die by WordPress and support people who use it or need to be testing it in your corporate environment, then you need to step up and start using SVN. Make a second install and set up a job to update every few hours, pay attention to release dates, and don’t treat this like ‘traditional’ software and wait for a release to be notified as to what’s going on.

But that is another post all together.

Perhaps the best thing about a cooperative design, like in an open source app, is that if you don’t like the changes, most of the time you can find someone else who doesn’t, and who wrote a plugin/extension to change it. When you compare that to, say, Microsoft Word, and remember that you, as a user, have very little say in things unless you luck into their market studies or beta tests, and even then, the locked down systems don’t always permit changes, well, you’ve actually got a lot of freedom. And if you’re not a techie, well, make friends with one or hire one. I hear a lot of them like beer.

26 October, 2011
Lion: Switching F4 to run Launchpad

How about a (mostly) pluginless solution?

I don’t use the Dashboard on my Mac, I’ve never really gotten the hang of the widgets and I just don’t like ’em. If you happen to use FunctionFlip to turn that off, you get ‘Application Window’ instead, which boggled me even more. What good was this? But I do like LaunchPad because I can sort through my apps really fast. Like many of you, I saw the fixes using Function Flip and Quicksilver, and hated the idea of running multiple apps to do something.

You don’t need any!

This is a two step process that requires you to go into System Preferences > Keyboard > Keyboard Shortcuts.

Click on Mission Control

Double Click on the F4 to the right of Application Windows and the field will become editable. I changed my to Apple-F4:

Then go to to Launchpad and Dock

Check the box by Show Launchpad and that will make the option editable. Press F4 and you’re done!

31 July, 2011
Website Viewability

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.

16 May, 2011

Tag: accessibility

Great Walls of Fire

Font Size Matters

Simply Complicated

Community Driven Design

Lion: Switching F4 to run Launchpad

Website Viewability