In short: pad your
a elements liberally
A quick tip to improve the usability of your pagination: give your
a elements a decent amount of padding.
We know clickability is an issue for seniors, but when it comes to the set of barely-separated-small-fonted numbers that so often comprise a website’s pagination, the increased click target area improves usability for everyone.
Continue reading “Improve your pagination’s usability”
Having been a Mac user for slightly more than a year, and working on several different monitors with quite different specs has opened my eyes to the absolute necessity to test your design on a variety of monitors before rolling it out (leaving aside the challenges posed by designing for mobile web devices).
I’ve lost track of the number of times I’ve been on a website that I can tell instantly was not field-tested in this way, a problem that manifests itself most obviously (and annoyingly) in the prevalence of unreadable font/background-color combinations. I may be (barely) able to read that #f7f7f7 font on #ffffff background on my Mac laptop, but there’s no way I’m seeing anything on the 25-inch CRT + Windows XP + non-ideal lighting conditions I’m using at my day job.
Moreover, I find generally that anything that looks like just the right size on the Mac laptop will probably look just a bit too big on most PC monitors. And that light-green background for the sidebar? Chances are that if it’s going to look anything like green on my work monitor, it’s going to more closely resemble a gray-green on my Mac, unless I get the screen at just the right viewing angle
The way I generally try to overcome this is to use a similar approach as I do with web development: develop in the best-possible-world scenario, and test extensively in the real-world-scenario. For my web development, this means developing with Firefox and/or Opera and testing with IE6 and 7 (include Safari somewhere in there).
For design, this means developing with a 19-inch LCD screen intended for PC use plugged into my Mac (with obligatory DVI adapter). You get a rough and ready idea of how your design is going to look on two different and fairly common types of monitors. Then, of course, test again under less-ideal conditions (older CRT monitors with some bad office lighting).
I’m sure there are much more rigorous approaches to this sort of testing, but this is a good baseline that my years of web browsing suggest is not nearly as common as it should be. Strangely, the worst offenders are usually design-oriented websites by people who should know better. I’ve never understood why “looking cool” is more of a design priority than “being usable”.
Working on a design brief for a radical makeover of the website at work, and have been doing a bit of digging around into how people specify web standards in their project specs. Came across this post from quite a while ago, and ended up using it as sort of a template, with some modifications:
Usability, accessibility and standards
- The website will conform to the following standards:
- Validation to either the W3C XHTML 1.0 transitional or strict document type
- Validation to the W3C’s CSS 2.1 or 1.0
- Will meet all WCAG Priority 1 Guidelines, except No. 1
- The website will render correctly in IE6+ and Firefox 2+
- All multimedia files will be available for download, and video will be provided via Flash
- Alternative stylesheets will be developed for printers and mobile devices
- Character encoding will be UTF-8
This is still not solidified, and I may decide to put HTML 4 in along with XHTML, though my preference is for the latter (for more on developing with XHTMl, see Jeffrey Zeldman’s “Better living Through XHTML” at A List Apart). Continue reading “Incorporating web standards into your design brief or RFP”