November 2004 Archives

<pre> Is Not Presentational!

"You shouldn't really use the pre tag because it's presentational. You should use the CSS statement white-space: pre instead."

NO!

You use pre when the spacing in between characters is just as important and meaningful as the characters themselves.

I just needed to get that out of my system...

Saturday 27 November, 2004 ( 4:41 PM GMT) | Comments (20) / Permanent Link

London Training

Through Vivabit Ltd, I'll be giving a few public training courses in a swanky central London training centre in January.

If you've ever wanted to learn the ins and outs of best-practices, the real nitty-gritty detail of web standards and accessibility and you (or more likely your company) want to invest a little bit of cash in some bloody good, mind-expanding training from a web professional who really knows what he's talking about and how to talk about it, then this is the training you've been looking for, my friend.

On 18th January, I'll be teaching the "XHTML and CSS" course which is for those who already have some HTML experience and covers how best to put together a web page - structuring it with (X)HTML and presenting it with CSS, ranging from the basics of text and links through to table-free design and accommodating multi-media.

The next week, on the 25th January, I'll be teaching the "Accessibility" course, which goes through the practical problems faced by disabled web users, industry (WAI) and legal (DDA) guidelines and then goes on to explain how you can build web pages so that they are accessible to all.

The courses last for one day, cost £395 per person per course (or £695 for both courses) and are limited to a mere handful of trainees to ensure everyone gets adequate attention. So if you want it, I suggest you get in there fast.

If you're not convinced, there's more detail of the courses on the Vivabit website and if you're still not convinced, just drop me a line for more info.

Tuesday 16 November, 2004 (12:52 PM GMT) | Comments (suspended) / Permanent Link

Alexa Is Nuts

How the hell does Alexa work? How does it figure out which site is more popular than another site?

Day to day it certainly doesn't correlate to the HTML Dog stats. One day it's ranked 40,000, the next 400,000! Now, my reliable information tells me that there's not much difference between those two days, so I can only assume that suddenly 360,000 websites became incredibly popular all of a sudden. But they must only be flash-in-the-pan successes because the next day HTML Dog'll be back up to 60,000 or something.

Nuts I tell you.

The bigger problem actually lies elsewhere. Okay, okay, actually, I do know how Alexa works - the statistics are collected from those who download and use the Alexa toolbar (which doesn't explain the mentioned phenomenon - that's all just nuts). Being an Internet Explorer-only application, it instantly excludes traffic generated by Mac users and Firefox/Opera/etc. users, which, as one example, will adversely affect the results of (and therefore misrepresent) sites such as web design blogs who tend to have a disproportionate number of readers who don't use IE.

So until Alexa manages to collect data from all types of web users, these rankings, especially those in the lower echelons, are hardly accurate. Which is a shame. I love this statistics stuff.

Wednesday 10 November, 2004 (12:23 PM GMT) | Comments (20) / Permanent Link

Image Replacement Considered Evil

In another great "10 Questions" interview over at the Web Standards Group, Jon Allsopp of WestCiv fame gets a grilling.

The answer that was of particular interest to me (in a general web design kinda way) was to the question "what do you think about the various image replacement methods?".

Out of all of the web designers I know, read about and see the work of, I can safely say that my point of view is closer to Johns than most - graphical text is used far too much in web design. But although I do agree with the general gist, I feel the need to pick up a few points. Maybe just to play devil's advocate...

To kick off, I would disagree that image replacement breaks the concept of separating content and presentation. Of course, in visual terms, it doesn't matter if the image is replacing any functional text or not and the image will effectively be conveying the information to those that can see it, but if it can be said to be offering an alternative presentation to any given content then it can safely be defined as presentation. Just because it's made up from a load of pixels rather than a scalable font, what's the difference? - these are both ways of visually presenting content.

John goes on to point out the practical drawbacks of image replacement...

His first point is that IR techniques are not accessible. I wouldn't say that they are not accessible (full stop), but they have severe accessibility problems.

It is a very good (although quite obvious, but so often neglected) point that John makes when he says that accessibility isn't all about accommodating those who are blind and use screen readers - there are other disabilities to consider, such as impaired vision - those who suffer from which will quite possibly have a harder time reading graphical text, which can not be scaled up.

Like biology and "vertebrate bias", web accessibility seems to suffer from screen-reader bias.

Although not ideal, accessibility-wise, if we are forced to use image replacement (and we often are, which I'll come to in a moment), we can make sure that it is as accessible as possible by making sure that text is as large as possible in the first place and that there is alternative content that can be read by screen readers, for example.

His next point is that image-replaced text is ugly, which is very much one mans opinion and something that most designers would most certainly disagree with.

Linked to the accessibility point, he does however say that "due to the different default screen resolutions, and to user control by font zooming, while with CSS and text you can maintain font proportionality using say ems, IR based designs won't scale." which is something that all too often seems to be overlooked in web design. It isn't unusual to find a design based on pixel sizes that breaks down when the text size is changed.

He also says "IR techniques make reusing, updating, restyling content much more difficult" because graphics need to be changed rather than quick text edits. Unfortunately, this is kind of tough luck and it's not something that would stop a designer applying a certain style to any other aspect of a page design.

Image replacement is not going anywhere anytime soon. With so few safe fonts at a designer's disposal (and the fact that they're not anti-aliased by default on older operating systems), graphic designers and clients demand images to be used for text to the extent that IR has become a necessary technique in modern web design.

Sometimes it isn't even a case of one web maker trying to convince one client that functional text is the better option (which is difficult enough) - many organisations have a number of people in control of the design and a number of people in control of the code. And let's not even mention the project managers and the inevitable design by committee. Oops. Too late.

All we can do is our best. When we use image replacement we can apply it in the best possible way to wring out as much accessibility and flexibility out of what is left over.

Monday 8 November, 2004 ( 5:46 PM GMT) | Comments (12) / Permanent Link

Usable Form Labels

When we label the elements of a form, what are the best terms to use?

Most of the pages on HTML Dog (except those on the Dog Blog) carry a contact form with four fields, simply labelled "Name", "Email", "URL" and "Message".

Absolutely none of these are required (although nothing will be sent if there is nothing in the "Message" text area) because I want people to get on and do what they like with the minimum of fuss. If someone wants to remain anonymous or make a comment that doesn't require a reply (and therefore their email address), I want to give people that option. I'm weird like that, I know - most web sites have some kind of requirements and validation. But whether you agree with this approach or not, it has thrown up some interesting issues regarding the usability of form labels.

The first problem arises with the "URL" field. This is a technical term and some people don't know what it means, which I gather from collecting instances of "?", "URL??" and "I don't know what this means" as the input for that field. URL is not a good term to use - a less technical and more generally understood term such as "Web address" would probably cause less confusion, methinks.

But even this might not be enough - some people type the web page that they are on, which I don't need to know because the form-to-email processing script puts that in the email for me anyway. Maybe "Your web address" might be better?

The bigger problem I have comes from the "Email" field. In a surprisingly large number of messages, people will not leave their email address, even when they require a response.

I have even had a few irate repeat messages along the lines of "I HAVE ASKED YOU THIS MANY TIMES, WHY WON'T YOU ANSWER ME?".

Erm, because I can't - I don't know your email address.

I'm sure that a large number are going to be from those who have simply overlooked or forgotten to fill in the field. But here's a completely unsubstantiated theory - what if there are web users who believe that their email address is automatically sent when a form is submitted? I think most people realise that web browsing and email are two different things and that there is no way of telling someone's email address from a sent form without the sender explicitly stating it. But it seems perfectly logical to me that relative newcomers may believe that their browser and their email programme are in someway intertwined in a single, universal, internet system. Just a thought.

This isn't really a question about whether you should gear up your forms to require one piece of information or another, validate it and alert the user if they have not filled it in (although I bet there'll be a comment or two about that). It's about what you should use as labels and how to make them easier to understand. Even if you validate it, you'll be doing yourself a favour by making things easier for users in the first place. The thing to keep in mind is that, as technically proficient web makers, there are many technical things that we take for granted.