BGA Web Site style guide—URIs

The URIs of particular pages are part of the user interface of this web site and should be chosen carefully. Although many users will never manually type a URI, they may see them in the address bar of their web browser, they may copy and paste them into emails to friends, and they may see them in print in articles, for example in the Journal.

URIs should never change. Once a page has been published, it may get bookmarked, linked to from other sites, indexed by search engines, and so on. This means that it is important to get the URI right first time. If in any doubt, please consult with someone else (me, for example) for guidance. Having said that, if absolutely necessary, a page can be moved to a different URI, and things can be done to ensure that people trying to visit the old URI get redirected. Just ask me, and I will set this up.

Since getting URIs right first time is quite important, I was considering a policy that you must ask me every time before creating a new page. However, I rejected this as unnecessarily draconian. You may still want to ask me anyway, since I will need to work out where any new page should fit into the site’ structure, where it should be link from; and the indexer will need to be informed of the new page’ existence. It is not that I think that you are likely to make mistakes (at least no more likely than me). It is that correcting a mistake later is painful, and the more pairs of eyes that look at what is proposed before it is set in stone, the more chance there is of any mistakes coming to light when they can be fixed painlessly.

When choosing the URI for a new page, please consider:

  • People looking at the URI should have a reasonable idea what it points to.
  • URIs should be as short as possible (URIs longer than one line of a plain text email—about 72 characters—are particularly bad).
  • Only lower-case letters should be used in URIs. Upper-case letters are perfectly valid, but unusual, and users should not have to think about upper/lower case when they are entering a URI, so keep it all lower-case.
  • Similarly, avoid all punctuation other than ‘/’ and ‘.’.
  • When running two words together (don’t, unless you have do) be careful. ‘danpromotion’ is OK. Something like ‘fortypee’ would be ambiguous (forty pee, for type e, OK, you could probably make up a better example yourself), and should be avoided.
  • The URI should describe the contents of the page identified, and not the technology used to produce it. So avoid URIs like:

    • ‘/cgi-big/…’
    • ‘/tournaments/index.html’ (Keep the file as /tournaments/index.html on the server, but always refer to it as plain ‘/tournaments/’ in URIs)
    • ‘pagename.php’, ‘pagename.shtml’, and so on—the user is not interested in how the page they are viewing was generated. (Even ‘.html’ is arguably bad, however, HTML is the format of the information in the page, not how it was produced, so may convey some useful information. For example you could have pages ‘fred.txt’, ‘fred.html’, ‘fred.pdf’ which present the same information if different formats. And in URIs like ‘image.png’ and ‘image.jpeg’ the information about file format certainly is useful.)
  • Particular extensions:

    • Use ‘.html’, not ‘.htm’
    • Use ‘.jpg’, not ‘.jpeg’
    • I have now modified the setup so the rules about particular extensions are enforced. That is, if you attempt to go to the page something.htm, it will immediately redirect you to something.html.





Last updated Sun Jul 08 2007. If you have any comments, please email the webmaster.