Wednesday 5 August 2009

A domain driven design for the University Web

I wasn't at IWMW2009 last week, but I've been reviewing the conference thanks to a colleagues writeup and slideshare. The highlight for me was How the BBC makes websites (also in a more accessible text version BBC Radio Labs - how we make websites).

In the words of Michael Smethurst, "there's very little original thinking in here. For those familiar with the concept of one web, the importance of persistent URIs, REST, Domain Driven Design and Linked Open Data it'll probably be old news."

Michael is being modest. Personally I was familiar with some but not all of those. Even the most basic concept - having a single, unchangeable URI for an item - is rarely implemented. Bringing them all together makes the BBC Programmes site a powerful demonstration of how to do the web properly. More importantly it is a pleasure to use.

We are currently rethinking the University's web strategy and CMS requirements. To do this step back and think not about the web but about the activities the university undertakes.

What do universities do? They teach and they research. I'll use real-world data in two examples to show what I mean.

First teaching. Here's a course hierarchy:
(this would be clearer as a table or diagram but I'm limited by the tools in this blog)
  • Course Family: LLB Law
  • LLB Courses: LLB Law (UCAS course code M100), LLB Law with Study Abroad, LLB Law with Chemistry, LLB Law and French, LLB Law & German
  • year started the course: 95, 96, 97, 98, etc
  • Programmes of Study: 1st year, 2nd year, 3rd year
  • Year One Units: Law of Contract (Unit Code LAWD10008), Law of Tort, Law and State, Constitutional Rights, Criminal Law, Law of Property
  • Law of Contract Lectures: lectures 1 though 6
  • Lecture 1: introduction to contract law
The URI for that lecture would be http://www.bristol.ac.uk/courses/law/m100/1999/year1/lawd10008/lecture1

Every level in the hierarchy has a web page with a permanent URI. So every course family, course, year, unit, and lecture has a webpage with a single, permanent URI. Ideally we would have a recording of the lecture but as a minimum each lecture must have a presence, at least a placeholder.

Now look at research. Think about web pages for each of the following (again real world examples)

Department of Computer Science
Computer Science Research Groups: Computer Vision, Cryptography, HARE, Intelligent Systems, Interaction & Graphics
Research Group: Cryptography
Cryptography Staff: Elisabeth Oswald, Dan Page, Nigel Smart, Bogdan Warinschi
Person: Dan Page
Dan Page: list of all publications
Publication: Manuel Barbosa, Andrew Moss, Dan Page, Constructive and Destructive Use of Compilers in Elliptic Curve Cryptography . Journal of Cryptology, 22(2), pp. 259?281. April 2009

URIs for the above would be

http://www.bristol.ac.uk/compsci
http://www.bristol.ac.uk/compsci/groups
http://www.bristol.ac.uk/groups/cryptography
http://www.bristol.ac.uk/groups/cryptography/people
http://www.bristol.ac.uk/people/dan_page
http://www.bristol.ac.uk/publications/dan_page
http://www.bristol.ac.uk/publications/2009/constructive-and-destructive-use-of-compliers

So every department, research group, person, and published paper has a webpage with a single, permanent URL. Even if the paper itself isn't available electronically it must still have a presence.

Note that in this case the urls do not follow a strict hierarchy as they did in the teaching context. Why? Hierarchies change. Right now the faculty of engineering is merging its departments into larger schools. The URIs for the research groups, people and papers should not change. Our internal organisational structure is completely unimportant in the web context. Breaking a web link pushes us lower in search engines, hides our research and damages our reputation. It should be avoided at all costs!

Each webpage should be about an obvious, real-world thing. If it isn't about an obvious thing, split the page up into smaller pages, until the subject of the page is now clearly one thing. Then give each thing a single URI, and make sure it never changes.

Simple really. Now how do we do it?

No comments: