Extensible CSS Interface IV: Testing for Extensibility
~ 01 April 2008 ~
This is the fourth and final article in the four-part series, “The Highly Extensible CSS Interface”. Markup and images for this article:
Finally, we’ve arrived. This concluding article provides the full demo, as well as a bookmarkable site that gives you quick access to all resources mentioned throughout the series.
Additionally, what follows below are 8 benchmarks to measure the extensibility of your site or app. I certainly don’t advocate that every site or app must comply with all of these benchmarks, but I do recommend trying to comply as best as possible with each of these when applicable to your project.
When I sat down to author this article, translation of all things was the first to come to mind. I suppose that’s because it’s been on my mind not only at work but increasingly as I realize just how global our economy is becoming.
Perhaps the easiest way to test for translation is to send your prototype through Google Translate. Here’s what the demo looks like translated to Chinese (Simplified). Fortunately, a fringe benefit of bulletproofing is that elements containing text are inherently capable of accommodating changes to the length of the text that occur as a result of translation.
However, bulletproofing alone isn’t always enough, as we must make smart choices about what will be image text and will not be as we design the layout. In the demo, only one phrase in the entire interface is image text — the logo. The rest is HTML text. This was done specifically to make translation as easy possible, sparing ourselves from having to create a set of graphics with translated image text for every language our fictitious app may be translated into.
In the end, you’ll have to decide on image text vs. HTML text based on the translation needs of your site or app, on how much typographic control needs to be retained through imagery and how much can be relegated to browser rendering, and so forth.
2. Text Resizing
This benchmark is fairly straightforward: Make it work for low-vision users, whose default text size may be different than yours. A general recommendation is to accommodate up to two sizes larger. You can also accommodate text sizes smaller than the default, but my opinion is that if a user chooses to go smaller than default, he or she accepts that things may not be legible anyway.
Testing for text resizing is pretty easy: Command/Ctrl + (in most browsers), and then analyze how elements containing text accommodate changes in text size. And if you’d like to explore an interesting technique for having the entire interface resize (not just text elements), check out Jon Tan’s Em & Elastic Layouts with CSS.
3. Resolution Dependence
I’ve talked about resolution dependence extensively throughout the series, so I won’t elaborate further other than to suggest you check out Richard Rutter’s list of resolution dependence techniques, which he refers to as variable fixed width layout.
4. Images Disabled
This one’s an easy step to overlook. Be sure to test how your layout renders in the absence of images, not only for reasons of accessibility but also to be sure background images have a supporting background color. In the example above, the Featured Member section is created with dark background images and white text. If I’d forgotten to add a dark background color, even though it’s not visible when background images are present, I’d leave users with white text on white background when images are disabled.
5. Styling & Scripts Disabled
Disabling styling and scripts tells us if we’ve separated presentation and structure properly, which yields a variety of benefits, not the least of which are accessibility and alternate device rendering (e.g. mobile).
Two Firefox plugins for not only easily disabling images, styles, and scripts but also for inspecting and manipulating markup on the fly are the Web Developer Toolbar and Firebug. I recommend you install both. Additionally, there’s the IE Developer Toolbar (IE 6 and 7) and Safari Web Inspector.
6. Color Contrast
When you consider roughly 8% of the male population is color blind, you quickly realize a significant chunk of your user audience may have difficulty using your site if color contrast isn’t properly tested. (As an interesting aside, I’ve had at least one color-blind designer on my team for nearly the entire length of my career.)
The utility I prefer to use for quickly assessing how color-blind users will see my interface is Color Oracle. It’s free, very lightweight, and allows you to test color blindness in any software or window on your machine. Also give Pabini Gabriel-Petit’s thorough article a read: Ensuring Accessibility for People With Color-Deficient Vision.
Those of you who develop software that is licensed to other companies who in turn rebrand your software as their own will know what I’m talking about here. Inherent in the practice of web standards — and the practice of extensibility — is the ability to “reskin” an interface fairly easily.
To see what I mean, uncomment the following line of code in the demo to see a simple rebranding of the interface:
<link rel="stylesheet" href="css/branding.css" type="text/css" />
Again, this rebranding is rather minimal, but the point here is that by properly separating structure and presentation, changing the skin of an interface is relatively easy. Of course, you can really reskin the same markup by changing the CSS rather wildly, as demonstrated by the css Zen Garden project. My example pales in comparison, but hopefully you get the point.
Lastly, I’d be remiss to skip mobile when speaking of extensibility. Regrettably, this demo is not a stellar example of mobile extensibility, as I’ve not had time to create a mobile-friendly version of the interface. I got lucky with iPhone (picture above) only because of the resolution dependence built into the interface, which works surprisingly well on iPhone. But if I had the time, I’d explore options for mobile adaptation, context, and all the other stuff you can read about in my book.
And so the series comes to a close. Before leaving, it’s worth stating these benchmarks are not all-inclusive. There exist other benchmarks that may be considered, but the ones I’ve presented here I feel summarize extensibility fairly well.
Thanks for participating in the series, either as innocent bystander or active participant. This is your last chance to call me out on anything that’s wonky or misleading, so please do so. Otherwise, happy extensibilitying.
Stock photography, type, and killer tees. Genuinely recommended by Authentic Boredom.
Authentic Boredom is the platitudinous web home of Cameron Moll, designer, author, and speaker. More…
Full-time and freelance job opportunities. Post a job...
A selection of fine reading, available for a limited time only: