| By
Ashok Argent-Katwala <ashok@future-i.com> |
| Status: Current |
This is centred on how to deliver decent services to various clients on the World Wide Web. A fair amount of it also applies to internal sites running on web technologies - but the demands there are often different. That aspect is dealt with in Intranets and standards.
This plainly is just a quick brain dump, it may get more polish over time. In particular the style of language is still far too informal. I intend to be taken personally, and have a go, but this is also a professional thing - so it'll get fixed. In the end some of the more offensive stuff will move to a personal site.
Fast ones to get right:
mod_validator to make this easy for you).
For the foreseeable future, people are still going to be searching for text. Make sure you've got plenty of compelling words, that will include what people are looking for.
You may be tempted to just have pretty pictures with your text in but this is bad for two reasons. Not only is it rude (and in any civilised country, against the law) to poke blind people in the eye, but it will also hurt you when it comes to search results, since Google will see as much text as the blind person.
Where you have text, write text and style it using CSS. You can make it as pretty (or ugly, at your choice) as you like, for people who will see those things, but leave the basic structure there for people browsing from mobile phones or PDAs or using screen readers. It will look even prettier for people with decent monitors as they will have their text-size set bigger whereas you will be hard pushed to make text scalable in an image. (See later rant on Flash).
Where you have images, give them a decent description in the page. Remember that there are still lots of different sized screens out there, so for pictures illustrating a longer piece of text consider putting thumbnails in with the text with captions explaining what they are and linking to a larger picture. Use the alt attribute for every image. alt is for alternative, what is the functional purpose of the image; if it is fluffy decoration then set alt="" so that people with no images don't get assaulted by the filename, or something uglier. Don't tell people in the alt text to turn images on - that's flat out rude. Don't expect the alt to come up as a tooltip, that's not what it is for. Use longdesc to provide a longer description of what the image is about. Especially for charts and graphs, where a summary is most useful.
URLs, URIs, 'Web Addresses', or whatever you care to call them are the names of your individual pages.
The ones you have today are the ones you'll have tomorrow. People will (hopefully) bookmark them, mail them to friends, link to them from their own pages. If you break those links later you won't be making any friends. Mailing them is less likely to work smoothly if they are more than 70-odd characters long. If the line in the address bar doesn't bring someone back to the same content then it'll cause trouble.
Think about how committed you are to the URIs you present today. It may even be worth saying on the page what you mean, or linking to a doc about linking to that doc (if that is genuinely useful, not to tell people how to tie their shoelaces).
Include' in.The key to being useful on the Web is to stay available. What use is it to link to a resource that keeps breaking the links? After you have thought through your URLs, this shouldn't be so tricky. There are extra difficulties, though. You need to be very carful if you let content authors or editors delete things. Do you really mean that, or are you shifting things around for some internal purpose?
Where you really do want to make something go away - serve a
410 Gone to suggest you know what you are doing, rather
than 404 Not Found, which suggests that you've just kind
of misplaced it (or perhaps it never existed in the first place).
More broadly, use the most appropriate code for other responses
too. Your errors should be errors, but I see more and more fancy
back-end templating systems that serve their errors as 200
OK. If you are using a front-end to hide this sort of
complexity from you, try and choose a good one, and ask an appropriate
Web-geek to have a bit of a poke. Together you can likely identify the
worst culprits pretty quickly.
Keep it simple, and everyone will be able to read what you have to say.
If you read anything which talks about 'cross-browser support' or making it work in 'both browsers', then take it with a pinch of salt. There are more browsers in heaven and earth than are dreamt... (&c.)
There are going to be browsers which don't do JavaScript, or frames, or graphics or Flash or whatever fancy technology emerges next. There are a slew of reasons. If you're going to only allow Netscape and Internet Explorer, and even those only configured a certain way to view your public information then that's up to you but please ...
Don't use some fancy new technology to poorly imitate something that can be done simply using basic standards. Javascript-redirects are a prime example. You should use standard redirects instead, and not break people's back buttons.
Don't do this (from www.mckinsey.co.uk's front page). Basically they're writing out the HTML page in Javascript, unless you look a bit like Netscape, in which case they'll boink you through to the next page automatically.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>McKinsey</title>
<script language="javascript" type="text/javascript">
if (navigator.appName == "Netscape") {
document.location.href="index2.htm"
} else {
document.write ("</head>")
document.write ("<body bgcolor='#000000'>")
document.write ("<table cellpadding=0 cellspacing=0 border=0 width='100%' height='100%'>")
document.write("<tr>")
document.write("<td valign='middle' align='center'><iframe src='index2.htm' name='quiz' border='0' width='705' height='450'>Your user agent does not support frames or is currently configured not to display frames.</iframe></td>")
document.write("</tr>")
document.write("</table>")
document.write("</body>")
}
</script>
</html>
Or this (from http://www.forager.co.uk/). Without Javascript they won't show you anything but a blank page, but it's terribly important that the background is white!
<html>
<head>
<title>Applied Psychology Research Limited</title>
<SCRIPT LANGUAGE="JavaScript">
<!--
self.location = "apr/fset.htm"
//-->
</SCRIPT>
</head>
<body bgcolor=#ffffff>
</body>
</html>
Both of these examples were taken on 23rd August 2001, so may have changed by now. However, my beef isn't with these organisations specifically but with doing things in this manner. Both of them also succeed in breaking the back button, because boinking things through like this, rather than using sane and standard redirects means it you get the intermediate page when you go back too - joy!
Update McKinsey now proffer cookies on the .co.uk before sending you to the .com for more cookies. Ho-hum.
Just visiting the site in a text browser like lynx is a good start.
Don't use Javascript which the visitor needs to have. If you can't think of another way you'll have to either exclude people or rethink what you're doing. Using Javascript to enhance a user's experience has its place, but very often sites screw up their usability because of this. For goodness sake don't have forms which can only be submitted using Javascript, or navigation buttons which don't say what they do until you hover your pointer over them. For starters it sucks, and secondly there is a better way. Where you do use Javascript don't put it in <a href="javascript:...">, but instead make the href point somewhere sensible and then override it in the onclick event.
'Designed for 800x600' et al. Don't be daft. What of people with big screens, little screens, portrait screens, no screens? Not everyone browses with their window maximised. Pay attention!
OK, have a sensible minimum width where a graphical visitor can still see everything. But how hard is it to use the screen real estate properly. While the site is fantastic in so many respects the BBC News site fails annoyingly on big screens with large fonts. Of course you can fall back to the low-bandwidth version, which is much more flexible, but aren't the folk with twenty-something inch monitors more likely to be the ones with big fat network connections too?
If you want to do the whole accessibility thing (and I realise that this isn't quite a given - to my dismay) then think & try hard before you go for doing an 'alternate text version' or some such.
The W3 have an excellent Web Accessibility Initiative, which spells out how you can make your pages useful to people generally. Bobby is a good application of the guidelines, which helps to look over a site and evaluate it.
If you have been paying attention up to this point you have something which works in everybody's browser, some more prettily than others. This is good. Now finish it properly. Instead of jumping to offering a 'printable version' use the features of CSS to ensure that the version you serve to everyone is already sane and printable. Do even better by offering extra CSS suggestions as to which blocks of navigation can reasonably be omitted in the printed version. You may want to make further tweaks to the look on the printed page. That's simple enough - here's a quick howto (-link- to be written).
You know when you sit there, waiting for the rest of a page to appear. Having a </table> at the bottom of the page, which opens near the top is kind of evil. Minimising the volume of text in between helps, but only if there isn't an expensive database (or similar) operation going on and you have height and width tags on all the images (and objects, I suppose).
This is especially important if you have very much to say - if you have a thousand words or so on a page, then it could be genuinely painful to wait for them all to arrive over a slow modem. I presume you want people to read what you have to say - and not just leave.
Explain terms that don't make sense. There's a slew of things that should be said about how to write - some of which change when you're writing for the Web, but not many. The trouble is I'm no writer, I just believe passionately in a bunch of things, so I'm driven to type them up. There are other folk with good style guides for writing, I'll list some eventually. Once general page comments are in, and related links on pages here you will be able to add your own suggestions.
Never use 'click here' for links. It's amateurish and somewhat rude. Just use the link in a sentence. The W3 have better instructions, and a little more reasoning.
For the time being, given the state of browsers, we are better off serving compliant text/html to end clients. Where possible we make this Strict, but we'll use Transitional where we must.
It's wrong to serve XHTML as text/html as it causes semantic inconsistencies and general headaches.
Whether all your pages are dynamically generated, or just one or two, there are some extra concerns:
More involved things to worry about:
WHERE clause, Luke