You are reading an archived post from the first version of my blog. I've started fresh, and the new design and content is now at boxofchocolates.ca
A few days ago, I posted a list of code related items I want to explore in 2005. Now, I’m taking a different path and looking at things that I want to do in 2005 – some are truly personal goals, some are more like notes to myself, and some are business objectives I’ve laid out for this year.
For each new project I work on, I always try to push my own personal envelope, taking on at least one component in the project that requires me to do more than I’ve done before – to learn something new, and implement it on a site or application. I consider it professional growth, and about the only way I can keep up. Besides, it expands the range of tools I can implement in the future, so even though I am learning something new, or experimenting a little, it is easy to justify spending the extra time.
I’m currently reading a book by Kim Vicente called “The Human Factor” that a colleague of mine (an ergonomist) recommended to me.
I’ll post a more thorough review of it later, but I wanted to share some nuggets I found In the first chapter. This passage really resonated with the world of the web and what we, as web professionals, do:
Continue reading The Human Factor
Over this past week, Scrivs asked his readers “What do you do?” to learn about his readers. D. Keith Robinson, in a similar post asked his readers “What could you be? What would you most like to be?“. I’d like to look to the past to complete the picture and ask: “What did you used to be?”
Continue reading What I Used to be
One of the things that I’ve been interested in for quite some time is how ideas spread on the web. Many bloggers do this instinctively when they post interesting links with a via link, a hat tip, or a nod to let people know where they originally saw the link.
Matt writes about this in Link Thanks and Nick discusses this further in Giving Credit. Many seem to agree that the links are not only ethical, but also useful. Can we make them more useful?
Continue reading Tracking the Spread of Ideas
I was observing my own habits the other day and noticed that there are certain things I do without even thinking. I am definitely a keyboard user. I can’t remember the last time I used a “mouse” — my laptop has a built in touchpad, and I’ve used an external touchpad for my desktop system for close to 6 years.
First, I noticed a pattern; I operate in two different modes – active working mode and casual reading/browsing mode. Continue reading My Favourite FireFox Keystrokes
After a weekend of camping with my old high school rugby mates, I returned to civilization to find what may be a hidden gem in my feed aggregator (the Sage RSS/Atom aggregator extension to Firefox if you are wondering).
Via the Business Opportunites Weblog: Quickbooks Weblog (a pretty good resource itself actually), I found The Official Quickbooks Online Weblog. It launched last month, and so far I like what I see.
Continue reading A Blog for the Online Edition of Quickbooks
The Web Content Accessibility Guidelines, Checkpoint 3.4 suggests that we use relative units in our Cascading Style Sheets for sizing rather than absolute units for sizing items on our web sites. This applies to widths, heights, lengths, and text size.
Accordingly, accessibilty and standards advocates recommend sizing text with em units or percentages via CSS to maintain flexibility in text sizing. See Richard Rutter‘s How to size text using ems for an interesting CSS technique and the followup comments for other valuable pointers on sizing text.
Nonetheless, designers and developers have always found that pixels are the most consistent across platforms and browsers, and many still use pixels for sizing their text in their style declarations.
In almost all cases when these issues arise in a forum, on a discussion list, or in the comments on a blog, someone always points to the fact that pixels are relative units. They are, indeed, correct. The W3C tells us in the CSS Specification that relative length units include em, ex, and px.
Further, they may use this fact to suggest that IE is wrong for not allowing pixel based text to resize and that in using pixels they have done their part to meet Checkpoint 3.4.
Following the letter of the law for Checkpoint 3.4 would allow us to use pixels for text sizing. However, I don’t believe that it is pragmatic to treat pixels as a relative unit like % or em, despite the fact that it may technically be a relative unit.
The size of a pixel is most definitely relative to the resolution. On my 17″ monitor at 800 x 600, I have 800 dots across, and at 1024 x 768 I have 1024 dots across. Nothing could be more obvious – pixels are a relative unit. In my opinion, using pixel units for text sizing is neither in the spirit, nor supportive of Checkpoint 3.4.
Despite the fact that pixels are a relative length, on my display at 1024 x 768, a pixel is always the same size. In my every day activities I am not going to change my monitor resolution, and I doubt anyone would in the course of their normal usage.
With that in mind, here are a few questions:
Don’t get me wrong — I much prefer the behaviour of modern browsers like Firefox and Opera that allow text sized in pixels to be overridden, but I wouldn’t go so far as to say IE is flat out wrong. Can you resize a pixel without changing your monitor settings? If it does resize, isn’t it now some other number of pixels?
Pixels are a relative unit – relative to monitor resolution. % and em are relative to a browser setting, and it is the browser setting that matters for every day use, and I believe it is what matters for Checkpoint 3.4.
The other day I told the story of The Case of the Missing Defensive Design. It is a story of how some other site didn’t provide default error pages, which lead a confused user that was at a dead end to do a search for the error text, which landed them on one of my sites (WATS.ca) – specifically on our Resource page that lists HTTP error/status codes and what they mean.
While preparing that post, I was checking our referrer logs looking at requests for that page. Here’s what I found:
Continue reading These aren’t the pages you are looking for
Defensive Design encompasses a lot of key principles — one of which is rescuing users when errors occur. The guys at 37signals write:
Guideline 16:
Offer customized “Page not found” error pages
Great advice — Hopefully in the next edition, we can see it expand to include other error pages as well. Here’s why I hope so…
My web development and accessibility consultancy is FurtherAhead, based in Ottawa, Canada, with clients around the world. And I'm not just saying that.