December 2003 Archives

Styling Columns

I've updated the Mastering Tables page in the HTML Advanced Guide to take on board the fact that you can only apply limited styles to table columns.

Originally, the page read (in relation to the col and colgroup tags): "In a peculiar twist, Internet Explorer leads the field in the implementation of these standard tags, whereas Mozilla, for example, won't take any notice". But, as Ian Hixon pointed out recently, the only reason IE takes notice when others don't is because it's a bit crazy. The more sensible, logical browsers like Mozilla actually do what they're supposed to and abide by the standards and the standards dictate that you can only apply borders, backgrounds, width and visibility properties to columns.

Friday 26 December, 2003 ( 9:23 PM GMT) | Comments (4) / Permanent Link

Usability Gaffes. Ho Ho Ho.

It's that joyous time of the year when a jolly, portly fellow spreads good will across the land.

Jakob Nielsen has popped a gift down the chimneys of all well-behaved web designer boys and girls in the form of the Top 10 Web Design Mistakes of 2003. The points get more specific every year, but this is hopefully due to the worldwide web becoming a more usable place.

Father Usability knows what he's talking about. If you're a good user-friendly boy or girl your rewards will be all the greater.

Tuesday 23 December, 2003 ( 8:08 PM GMT) | Comments (2) / Permanent Link

HTML Tag Reference

Dog collar and tag Adding another 70-odd pages to HTML Dog, an HTML tag reference is the latest addition to the site. Call it a Christmas present.

I have attempted to put together a tag reference that is slightly different to others out there - an accurate reference focussed on strict web standards.
I have made the kind of reference I would like to use and I hope that this will result in a reference that other standards-focussed web designers will also want to use.

In keeping with the rest of HTML Dog, the reference covers the tags and attributes that belong to strict XHTML. Actually, much of the information has been pulled out of the modules that make up XHTML 1.1 modules, so there are very minor differences from XHTML 1.0 Strict such as the lack of border and lang attributes.

I have tried to be as accurate as possible (I have come across some surprising mistakes in other similar references), gathering information from W3C resources and have hopefully produced something easier to read than the notoriously confusing W3C documentation.

At the last minute I begrudgingly added a page to briefly cover b, i, tt, big, small, sub, sup and hr tags because although I don't think they should be used, they are a part of strict W3C XHTML and in such a way are 'valid' tags. At least the reference can point out that there are better alternatives to those less aware.

It has been a long, gruelling and not too exciting project, but it is one that I think is necessary for a site such as this. Future updates may include links to the relevant W3C documentation and valid content, but I'm going to take a break from it at the moment. There are other things to be done - a CSS property reference will hopefully be along sometime soon.

Thursday 18 December, 2003 ( 6:07 PM GMT) | Comments (28) / Permanent Link

Image Maps Anyone?

The map and area tags are bizarre little creatures.

I used to think that image maps - images with various clickable links mapped to areas on it - were for people who didn't know how to make web sites properly, that is, with the mentality of shoving a big image on a page and then slapping links all over it.

I'm not as dismissive as that any more, not quite, but I can't say that I've come across that many good uses for image maps and I've certainly not implemented one in years (although there was one big commercial website I was working on recently that employed an image map containing several graphical text links in a remarkably insane fashion).

The tags certainly seem completely unnecessary, especially when there are much better ways to go about doing such things.

Wednesday 17 December, 2003 ( 4:40 PM GMT) | Comments (4) / Permanent Link

Fixed vs. Fluid

Following on from a brief look at elastic layouts, here's my contribution to the debate surrounding the rivalry between it's elder cousins, the fixed layout and the fluid layout that has reared its head again recently.

The contenders weigh up something like this:
Fluid layouts, where content flows to fit the width of the window (such as in HTML Dog) takes advantage of 'screen real estate' and the capabilities of a users computer, cuts down on scrolling and presents more information above the fold.
Fixed layouts, where the content area has a fixed width can be used to narrow the column in which content is presented, which is easier to read, just like columns in newspapers.

When I started out in web design, my preference was for fixed width pages. I figured they looked better that way. Over the years, as my understanding of usability increased, I was gradually convinced that fluid layouts were the way to go. The way I saw it was that cutting down on the amount of work the user has to do (ie. scrolling) makes a web page more usable.

This debate is all about usability. The thing is, there are usability benefits and flaws in both methods. Fluid layouts fill the screen and so present more content above the fold, minimizing the amount of vertical scrolling, but text spanning across a wide distance is possibly more difficult to read. The possibility of horizontal scrolling (that could occur on small screens, such as those on mobile devices) is also minimized. Fixed layouts however, offer a format that is initially easier to read but presents the problems of the increased likelihood of scrolling.

Most of the recent argument (from Mike Golding and Paul Scrivens for example) has been in favour of fixed-width layouts. The main reason I see for this is that designers prefer it. There is no evidence that such a method is more usable - it may at first seem that a narrow column is easier to read, just like a newspaper, but as I commented on Mike Golding's article:

...it simply isn't possible to directly relate the issues of print media to electronic media. Thinner columns may indeed be easier to read, but a newspaper reader has the whole page in front of them - they do not need to scroll anything and they may well be a tad miffed if one side of every page of the newspaper was completely blank!

I don't think the argument that that many top-name designers prefer fixed layouts proves anything. As much as I like an attractive design, I am more interested in function over form. I want to exploit design to achieve the best response from the user - to optimise usability and ultimately optimise functionality, not to make it something that is more pleasing on my eye. The day usability experts employ fixed widths is the day I will really take any notice of such an argument.

Scrolling (particularly vertical scrolling) and the importance of placing information 'above the fold' (that is, in the upper-area of a web page that is displayed in the window before scrolling) are certainly not as important as they once were. Nowadays most users are perfectly comfortable with scrolling and realise that content will also be present below the fold. However, I still think that these issues, although less important, remain important nonetheless.

I have spoken mainly of the benefits of fluid layouts over fixed layouts because the high-profile arguments elsewhere that I have highlighted have extolled the virtues of fixed layouts, presenting some very good points but missing much of the argument in favour of fluid layouts.

I'm playing devil's advocate. I really don't see any completely preferable way - there are advantages and disadvantages to both methods.
Before this debate ignited again recently and some very intelligent comments were made in favour of fixed-width layouts, I was very much in favour of the fluid layout. Now I would have to say that I am sitting on the fence - I have begun to lean further towards fixed-widths but I am not yet convinced.

I think this is one of the most important and interesting debates surrounding web design and I would love to see the results of some real hardcore usability testing on the issue.

Monday 15 December, 2003 ( 1:30 PM GMT) | Comments (19) / Permanent Link

Elastic Zen Garden

Screenshot of The Elastic Lawn design in the CSS Zen Garden website The Elastic Lawn is a new addition to the great CSS Zen Garden designed by yours truly.

The design is built using ems as units rather than pixels to define not only the size of text, but also the dimensions of the layout. The result is an elastic design that will expand and contract depending on the user's text-size setting.

This 'elastic' approach is one that I have used for some time. The argument that text-sizes should be relative (ie. ems rather than pixels) for increased accessibility can be said to extend to the dimensions of the area in which the text is contained. It does kind of make sense to me that there are benefits to layouts that grow proportionally with the text - I mean, if a visually impaired user finds it easier to view larger text, won't they also find that text more manageable if the space between content blocks is also larger? It also avoids increased text sizes pushing out and possibly breaking an intended design (try enlarging the text in some of the other Zen Garden designs for example). The elastic issue is one I will go into in more detail at a later date.

The Elastic Lawn is meant to be more of an interesting demonstration of a concept rather than an accessibility/usability demonstration however. This isn't my usual approach to design - some things such as graphical sub-headings, foregrounds that could have higher-contrasting backgrounds and text on patterned backgrounds can decrease usability but the point of the Zen Garden is to demonstrate the graphical design capabilities of CSS. This particular design hopefully demonstrates that ems are a viable option, even for elaborate designs.

You can find out a bit more about how certain aspects of the design work by taking a look at the annotated CSS file.

Sunday 7 December, 2003 ( 4:38 PM GMT) | Comments (10) / Permanent Link

Displaying Time

The issue of representing dates on the web has recently been raised by D. Keith Robinson and followed up by Simon Willison. But how would you represent a specific time?

The problem is that when you show the time, it's only going to be correct for one time zone, so it would actually be inaccurate in the other 23. This is, of course, due to the international nature of the web. If I make a comment on a web log at 5pm my time (that's in the London), it will actually be 12 noon in New York and 4am the next day in Sydney!

There is 'Coordinated Univeral Time' (UTC), which is based pretty much on Greenwich Mean Time, the time at zero-degrees longitude. But this time means pretty much nothing to most people outside of the UK, Portugal, The Gambia and other countries in that time zone. Just as Eastern Standard Time doesn't mean too much to people who don't share a time zone with the east of the USA. The times on the discussion forums in A List Apart, as one popular example don't make much sense on their own.

Most things we do in life are quite national so internationalisation is perhaps an easy thing to overlook. If you are going to display a time though, you should at least state from whose point of view that time is with a description such as 'GMT' or 'EST'.

Here's an idea - if you dynamically work out how long ago a certain event took place (like Simon Willison does on his web site) then you could minus that from the time on the clock of the users computer, which would give the correct time of that event from their point of view.

Thursday 4 December, 2003 ( 3:03 PM GMT) | Comments (2) / Permanent Link

Bad Tags

The font tag 'Bad Tags' is a new addition to the HTML Intermediate Guide, which covers some of the "Bad, nasty, downright ugly little things that belong to outdated HTML standards, random proprietary nonsense that only half-work in one sub-version of one browser or tags that have simply been superseded by newer tags".

The reason I decided that there was a need for this page was because, as Ian Lloyd correctly predicted, I have had feedback along the lines of "I put together this web page using HTML Dog... I couldn't quite figure out how to do x so I used the y tag that I found at some random place on the web". The 'y tag' being a tag that has a better, more efficient and reliable alternative.

The 'Bad Tags' page will hopefully serve as a lighthouse, warning authors of rocks that could damage their web pages.

Monday 1 December, 2003 ( 6:00 PM GMT) | Comments (61) / Permanent Link