Why 'Eye for Information' was designed this way

On this page: The rationale for some of the design decisions I made when creating my site - it isn't an exhaustive catalogue, but picks out the more important features. Many of the points here will be familiar to seasoned web authors, but I hope some will shed new light on the subject. The process by which I arrived at these decisions is described in the main case study (see below).

The main principles I followed were that the site should be accessible to everyone, reasonably quick to load in the browser, and easy to navigate. If you think I have fallen down on any of these, please email me with the details and I'll do my best to put things right.


Until the most recent 2008 redesign, I made use of a fairly small set of images for branding the site - most of them with the purpose of allowing navigation between the main sections. I have been more lavish with images that add to the content of the site (for example on the virtual pasture geology page) - I think these are justified because they add to the meaning of the page rather than just decorating it.

All the photographs have been optimised so they are as small as possible whilst still being clear.

The branding images could have been made with a transparent background. Instead, they had a background the same as the designed page colour (white). This was done in accordance with one of the site aims of accessibility for all: if the image background was transparent and the user had set his/her browser to use a dark background for example, then the text labels would have disappeared. Anyway, on any background other than pastels, there would be an unsightly coloured fringe around the images.

As far as I know, all the non-decorative images have a descriptive alternate text, so:

  1. if you are using a text-only or talking browser, you will have some idea what the pictures are.
  2. if you are browsing with images switched off, you can decide whether you want to see them.

In accordance with link to external site guidelines from the RNIB, any empty images (for bullets etc.) used to have an asterisk as their alternate, but in the light of more recent discussions, the alt text was made empty. (See my article on alt texts for images for more information.)

Frames and new windows

At one time, frames were very fashionable, but by 2000, they weren't any more. This is partly because, if they are not implemented well (and they often aren't, in my experience) they can make a site very difficult to use. My original design worked like this: the page was initially unframed, but people who like them, and have the screen space, could opt to switch to a framed site in the home page, which gave them a summary site map at the left side. However, looking at the logs this feature was almost entirely unused, and I soon abandoned it.

The site is designed to be usable at all resolutions, though some horizontal scrolling will be necessary in pages with big images.

All links to other sites are clearly signposted, but do not open a new window. There are contradicting opinions on this one: the main rationale for opening a new window for a different site is to keep your site in view, but once your own window gets buried on the desktop and the back button stops working, users may well have lost you anyway. More importantly:

(Read more about these in my articles on the use of frames in web pages and article on opening new windows in the browser.)

Page widths

Accepted wisdom is that the line length should be restricted to a comfortable length for reading. I initially had page tables set to fit in the frameset at 800x600, and in the whole page at VGA resolution. However, I asked some colleagues with large monitors to look at the site, and they said they had large screens to use as they wanted, and could restrict the line length by resizing the browser window. I decided to leave it up to the user to choose the comfortable width (which, after all, depends on the font size they choose).

While this may be unconventional, if we are allowing users to decide on their font size (which requires some minimal knowledge of how the browser works), then surely we can allow them to decide on the line length (which only requires knowledge of how to resize a window). This site is designed so that most body text will appear in a slightly smaller than default size for your browser. If you think this is too big or too small, you can read more about the choice of font sizes on the accessibility page.

Update: with the advent of more browsers supporting CSS better, my current design uses the maximum width property to constrain the line length to a resonable number of characters, but this only works, for example, in newer versions of Mozilla and Opera. IE users will - for the time being at least - have to narrow the window if they have problems.


I stuck to black text on white for the main content to offer good contrast, though black on pastel is more comfortable for most people. However, now 256-colour monitors are a very small minority, I may think again, which will be a snap as it just means changing 3 or possibly 6 characters in my style sheet!

	background-color : #fff; <- this sets the white background
	color : #000;
	padding:1em 2em 1em 2em;

I experimented with links in shades of red to match my initial colour scheme, which looked nice, but in the end, I left them the default colours, since research has shown that users can be confused by different link colours used unnecessarily. (See my article on link appearance and usability for more information.)

The GIF files used for the original branding graphics were mainly browser-safe colours, so they looked about the same on most machines. With the decrease in numbers of 256-colour graphics cards around, I relaxed that for the second design in 2003, which had enough contrast to read at most colour depths. For 2008, most of the images disappeared.

Dynamic elements

This site uses some server-side scripting to generate pages (the virtual pasture and terracotta rabbit). Since the output of this is straight (X)HTML, it should not cause any problems with users' browsers. For the same reason, I have used server-side includes (SSIs) to generate the breadcrumb trail, page titles, and page footers in a consistent way.

Both techniques impose a small performance overhead on the pages where they are used. For the breadcrumbs and footers, the content of the included part is simple and shouldn't take long to process; for the virtual pasture diary pages, I felt it was the only sensible way to provide the information that I already had stored in a database.

I have mostly avoided using client-side scripting, because it's very difficult to be sure that a script will run in every browser, it can hinder accessibility, and a significant but small proportion of users do not use or allow them. (Personally, I am annoyed if I visit a site and get asked if I want to debug the current page because there's a script error on line x; even more so if the error was in a script to generate some trivial effect, or means I am looking at a page with no navigable content. Since there are usually many sites competing for my attention, the temptation is just to say "forget it", and move on elsewhere. I don't suppose I am alone.)