The joys of designing web sites

Creating a new service, or indeed even just changing the visuals for an old service, is never a simple task.

Firstly you have to come up with a coherent design: one that compliments the contents of the site; one that works across all pages within the site; one that is visually appealing; and one that all the parties involved are happy with… Not my forte: I get a designer to do that.

Next you need to modify this design so that it can be created as a validating, accessible, cross-platform base.

What I like to do is then mock-up a few pages, maybe half a dozen, as proper xhtml pages – so that people can poke and prod them, be happy that they render across all browers and platforms, that they scale with font sizes, and that they look fine on different monitor/window sizes.

I’ve done all that, I’ve created the 100+ web pages… and now I’m going through the laborious task of verifying each one actually validates, and actually renders correctly under a range of browsers.

… and who said writing web pages was easy? <chuckle />

Web Accessibility in the public sector

Now, as you may have gathered, I work in academia…. which means the public sector.
When I build a web service, I have two sets of customers:

1. I have the people who are funding the service, my organisation, and the people who define the service guidelines: they expect a certain level of functionality; a certain level of reliability; and that the service enhances their reputation(s) with it’s good looks and slick behaviour
2. I also have the people who will be using the service, mainly staff & students of HE and FE organisations. JISCs new policies are also rolling out services to the schools sector, and some services (depending on the funding streams) are even open to the general public to use

This presents an interesting challenge:
If my customer base is “anybody”, I cannot discriminate against anybody – which means that the basic functionality of the service needs to be universally available (given the restrictions of the web protocols)

• Nothing core must be reliant on JavaScript, graphics, or colour
• The core interface must work irrespective of platform, browser, or ability of the user (within reason)

I have no problems with additional features being available to visual browsers, in a point-and-click interface… heck, if you want to have a Virtual Reality interface, with 3D rendering and swooping’n'flying – go right ahead SO LONG AS THE BASIC FUNCTIONALITY IS AVAILABLE WITHOUT IT

If you want to write, and maintain, two interfaces – go right ahead SO LONG AS THE BASIC FUNCTIONALITY IS AVAILABLE IN ONE

I’m sorry – but unless I have a service that works for “anybody”, I’m discriminating.

Accessibility is not about getting what you want looking good for you. Accessibility is about making it available for “anybody”.

(rant over)

Database rebuilds…

…. you gotta love them!

I’m rebuilding a multi-million record database, as the supplier has switched data formats.
Each step is trivial: simple to do; well documented; and a complete step in their own right… but when your processing 35 years worth of data in 64 files into 24 sub-databases, this takes time.

… and then one goes wrong!
Somewhere in 10-million-odd lines of sgml is something throwing a perl script… possible a spurious Unicode character.

You don’t know it yet, but…..

There are plans afoot for a three-day developer-focused conference (four days, if you count the plans for a pre-event “Alpha Developer Day”: aka code-monkey workshops).

“The primary activity of the event will NOT be the typical conference with scheduled presentations. Rather, the focus should be upon providing a venue where collaborative learning and participation can take place in an open forum.”

I admit a certain fondness for these sorts of events: I go to too many where the managers & senior staff sit around and promise blue skies and clear sailing…. without any consideration to the cold hard realities of working at the pointy end of the code-face.

I’ve already been in touch with the organisers and seen the draft plan for the event… it’s looking good. I’m guessing London for the location, given the committee

I’ll see you there

The joys of web design.

I’ve a full and rich job: I write code; I deal with databases; I ponder the improbable; and I stick my oar (no, not my ORE!) in at various levels of discussion; and I create web pages…. which is todays wee rant.

Web page design is hard…. damn hard.

If you are designing a poster, or a building, or a car, or a box for biscuits, then the medium you are designing for is immutable: It has known dimensions; everything can be precisely placed relative to everything else; and there is a quantifiable margin of error in your measurements.

When designing for the web, NOTHING is fixed: You do not know the size of the canvas your design is rendered on; you don’t know the colour-range available; you don’t know the fonts available; and you don’t know what platform your customer is going to use to render your design

You need to balance the visual asthetics, structural integrity, cross-platform-compatibilty, and graceful degradation. Working in the public sector I cannot, ethically as well as quasi-legally, discriminate against people through bad design.

Cross-platform compatibility

This is what I (at the time of writing) test under:

Linux

Firefox 2 & 3; Konqueror; Opera; Lynx

Windows Vista

Firefox 2 & 3; IE 7; Opera

Windows XP

Firefox 2 & 3; IE 6 & 7; Opera

Mac OSX

Firefox 2 & 3; Safari; Opera

Graceful Degradation

• What does the site look like with images turned off?
• What does the site look like with css turned off?
• What does the site look like if the user chooses to use a different font?
• What does the site look like if the user chooses to use a larger font size?
• Does the site work if the user chooses not to have their browser full-screen?
• FF3 & some other browsers now scale up images as well as text sizes: does the layout still work?
• Are you using colour to convey specific information?

Structural Integrity

This is things like:

• Does each form input have a matching label?
• Does each “set” of form inputs have a fieldset around them, and a legend for that set?
• Do you have an h1 before an h2, and an h2 before an h3?
• Are your menus lists, ‘cos that’s what they are, structurally speaking
• Is all your text text, not graphics?
• Does your (x)html pass validation?
• Does your css pass validation?

I LIKE validation: If I write a page with is technically correct (the (x)html and css both validate cleanly) and renders as the designer desires across all the major browsers, then when a user comes in with a “it’s broken for me” problem, the web design is not going to be the problem.

Some other tricks I use for accessibility:

• I have a hidden h1, at the top of the page, which states where the page is from and provides a general context.
• I have a hidden link, to jump straight to the main content of the page.
• I have hidden h2s at the top of the page header, the various menus, and the footer – which help define the context for the following text.
• I have all my menus as list items, styled as tabs or bars or blocks, or whatever the designer wants.

Almost perfect?

A mock-up page

Well, maybe not.

I’m sure that, given another few days to work on it I could improve some aspects of this page: The curved edge of the menu would be better aligned with the logo (but this has implications when font-sizes are changed); the text in the three large images across the bottom is graphic, and I believe text should be text; and the rounded corners on the submit button are too big.

But I’m pretty proud if it, anyway.

It may not be an exampler page, but it’s damn close

Repository Junction, a new world

I have, as many people know, written a small piece of code called Repository Junction.

The function was needed because we are running an ePrint repository called the Depot. The purpose of the Depot is to accept deposits on behalf of Institutions that don’t yet have repositories, with the intent to pass them on once said Institution sets up a repository. We do NOT want to take deposits that should be lodged somewhere else, we don’t want to be seen hogging the landscape.

With this in mind, I wanted to direct people to The Right Place^[tm], hence the need for Repository Junction.

Currently, RJ is integrated piece of code, with the lookup functions built into the code-base directly. I want to extract them, and re-write the whole thing so that the core Junction functionality becomes a simple API (maybe multiple APIs, with common/consistent parameters) which anyone can call, anyone can use.

(But after the current three jobs on my list)