Computer Laboratory

Policies related to Computer Laboratory web pages

Top-level web pages

Course-related web pages

Other web pages

  • Definition
    These are all other web pages accessible through the server
  • Management
    Someone must be responsible for each page. It should be obvious from the page who that person is. This will ensure that errors and updates can be reported and implemented
  • Standard style
    The Laboratory imposes no standard style on web pages below the top level. People who wish to use the standard style for official pages are welcome to use the ucampas tool. Authors should attempt to make their pages attractive, correct, and should strive to ensure that pages will work with a wide range of browser software.
  • Content
    No page should have on it content which would bring into disrepute the Computer Laboratory or the University of Cambridge. All text should be proof-read for both spelling and sense.
  • File space
    All official Laboratory pages should be on the same file server as the top-level pages. This prevents the webmaster from being inundated with queries when the web file server is up but your file server is down. Appropriate directories can be created by the webmaster. Official pages include lecture notes and research group pages. They do not include personal pages.

Research group pages

  • Style
    Each research group should strive to have a consistent look and feel to its set of web pages and is invited to use the ucampas tool that formats the top-level web pages.
  • File space
    Each research group's web pages should be located in an appropriate directory on the main web page file server. The webmaster can set up an appropriate directory under for you. Where desired, Subversion-based collaborative page management similar to that used for the top-level pages can be arranged, using a dedicated repository. (Ask pagemaster for detailed advice.)
  • Management
    Each research group should nominate a member in charge of its main web pages and the contact details of this person should be clear from the pages. New group webmasters are most welcome to contact pagemaster for a brief training session of locally available page management tools.

Personal pages

  • How to make your own pages
    Information can be found elsewhere on how to install your personal pages on the Laboratory's web site.
  • Style
    Personal pages which are in the Laboratory's standard style should ideally contain only work-related material. Material of a more personal nature should not be on pages which have the Laboratory's standard style, to emphasize the fact that they are not related to the Laboratory's business.

Hyperlinks should have the form of a noun phrase that best describes the content of the target (e.g., the title of a document). In particular, avoid using the word "here" as the text of a hyperlink. This helps both human readers and search engines.

URLs and filenames

Externally visible URL components (i.e. directories and filenames) should preferably

  • only contain characters from the set [a-z0-9.-],
  • be the single, short English noun (or word or commonly used acronym) that best describes the page content,
  • not repeat (without good reason) information that is apparent from the parent's name,
  • lead to a meaningful sorting order (e.g. dates should be big-endian all-numeric – ISO 8601).

Limiting the character set and keeping URLs short makes it easier to communicate them verbally and enter them on mobile devices.

If an HTML file refers to images or sub pages that are not shared by any other pages (or is likely to do so in future), it should be called index.html and sit in a directory of its own, such that its URL ends in a slash.

URLs of interactive web services should preferably follow these principles (RESTful API):

  • Each object that might be worth referencing has its own canonical URL.
  • Operations on an object are requested by a URL that contains the object's URL as a prefix.
  • The URLs of container objects are prefixes of the URLs of their content.
  • URLs should be usable independent of preceding requests, i.e. not carry session state.
  • URL syntax should allow the client to chose between human- and machine-oriented representations of data.
  • URLs should hide the current implementation mechanism (i.e., no ?& CGI syntax, no .php extension); use Apache's rewrite mechanism

These principles aim to encourage neat, meaningful, quoteable URLs and web interfaces that can also serve as APIs.


Images, if used, should be of reasonable quality; a grotty photo does nothing for our overall image (pun intended). Images that appear on web pages often later attract interest for possible reuse in in print publications. Therefore, low-resolution images should be links to high-resolution versions of the same (possibly uncropped) image.

The use of JPEG files should be limited to photographs; for icons, logos, line drawings, screenshots, and other non-photographic content, the PNG format is usually better suited, ideally (where practical) with a link to a resolution-independent vector-graphics format (such as PDF).

Ideally, provide metadata and in particular copyright and licensing information. These can also be embedded into image files, e.g.

exiftool \
-Creator="Markus Kuhn" \
-Source="Markus Kuhn" \
-Description="Front view of the William Gates Building, October 2011" \
-Rights="This work is licensed to the public under the "\
"Creative Commons Attribution license "\
" verify at "\
"" \
-License="" \
-AttributionName="Markus Kuhn" \
-AttributionURL="" \


Video (and long audio) content usually involves huge files and is best hosted outside the regular web directories. On the departmental filer /anfs/www-video exists for this purpose and files there can be refered to via symbolic links from the web space. With widespread support of the HTML5 <video> element, the H.264 format, and HTTP-based byte-range streaming, videos can now be embedded into web pages almost as easily as images. If maximum compatibility with older technologies is desired or substantial non-CUDN traffic is expected, they can also be hosted on a dedicated video server that takes care of streaming, format conversion, and archiving, such as the Computing Service's Streaming Media Service.