It’s true. The “www.” part of a web address can be considered deprecated and unnecessary. There is no technical or logical reason for websites to have the “www.” in front of the address. So, why do we do it?
It turns out that Lincoln are actually quite forward thinking in this regard. Our website is perfectly accessible through “http://lincoln.ac.uk” and “http://www.lincoln.ac.uk”.
Some slightly more elaborate universities still fail this basic test though. As a result, we’ll be recommending that the “www.” part of addresses is deprecated in the Linking You framework as unnecessary, pointless, and a waste of four perfectly good bytes.
During the course of Linking You we’ve spent a lot of time looking at URI structures and how they could be improved to variously be faster to type, easier to guess and clearer to understand. We’ve have a peek at hierarchical structures and flat structures, and we’ve debated if people need to know what “socs” means, and if it’s better or worse than “computing”. The thing which amazed me most, however, was when we sat down with a few people and had a discussion about how a new URI structure could click with a proposed redevelopment. One line of conversation stood out for me:
Are addresses even important? Surely we’ll just tell everyone to go to lincoln.ac.uk and click from there.
This concerned me enough that I felt the need to write a quick post about it.
A URI can technically be used purely as a ‘click to’ point on the internet. There’s nothing stopping us putting a page on courses in the School of Computing at lincoln.ac.uk/bcwi83b. You plug it into a link, people click the link and off you go. Technically this is sound, but only in the same sense that you can technically address a letter to something like “10, SW1A 2AA” ((If you’re not up to speed on your postcodes, it’s 10 Downing Street)). Yes it’s compact and yes it works, but it conveys absolutely nothing in terms of context. It’s also a real pain to remember, and requires you to use additional bits of your brain if you’re ever writing it down for later reference or typing it into a browser address bar.
Imagine for a second that we send out a prospectus with the following:
Find out more about Computing at http://lincoln.ac.uk/bcwi83b
And then compare it with a ‘human’ address:
Find out more about Computing at http://lincoln.ac.uk/school/computing
Now, try to remember the first one without looking at it.
One thing that has come out of our looking at URI structures thus far is that they tend to be heavily hierarchical, based around historical organisation attempts. This means that initially we get vaguely sensible URIs such as /mht/computing, but once we start getting down into the depths of course information it falls apart. Some things exist in multiple hierarchical ‘nodes’, making for an exciting experience when you need to decide which ‘node’ is the primary one, and should therefore have the content under it. Does a module on audio technology belong in mht/computing/audio, or mht/media/audio?
When it comes to navigating the internet this isn’t really a problem since we can link to wherever we feel like; there’s nothing inherently wrong with mht/computing and mht/media both having a link to mht/media/audio. However, this does then create a strange disconnect between computing and media – anybody who looks at the address bar is going to wonder “hang on, why am I now in the land of Media?”. Similarly on printed documentation (such as course notes) you’re going to have a load of computing students wondering why they’re being told to go to a media URI.
The problem with course-content is less apparent. Initially it looks like a lot of the content can be tidily nested, such as fees/international or accommodation/moving-in. Unfortunately it doesn’t take a lot of thought to break this model either; why should fees/international not be international/fees?
My favourite solution for this is a radical one which (in effect) totally breaks the existing model of our web content. Remove all nested content, except where there’s a clear ‘type/identifier’ model which can be followed. This leads to URIs like the following:
faculty/mht
school/computing
school/media
unit/audio
international-fees
moving-in
I’m curious to know what problems people can see with adopting this model, other than the fact that it will almost certainly require to be database/CMS backed.
One of the key aspects of the Linking You project is to come up with the ‘right’ way of organising an institution’s URI structure, mapping a virtual collection of spaces in a way which makes sense. For this blog post I’m going to tackle the University’s corporate web site, that is the public-facing, shiny clean, ‘sell the University’ website which is only ever looked at by prospective students, parents of students, prospective staff and marketing/PR folks. A full-blown dissection of the University’s ideal subdomain structure for online services is a whole other blog post.
This is a clean-slate approach with no preconceptions of how things work or are currently arranged, just an attempt to draw up a logical way of breaking down content. In this I’m also going to be shockingly ruthless in getting rid of what I think is irrelevant to the University’s website, which means an awful lot of people are going to be upset when they realise that their 26-paragraph essay on how their department has recently invested £4,000 in new doors has been cast into the pit of internet oblivion (apologies if anybody has really put an essay on their department’s new doors on the corporate site, but it wouldn’t surprise me). Before I get going, I’m going to reference a popular online comic called XKCD. Look at this image, understand it, and all will become clear.
I considered a wide variety of ways to organise my thoughts and tackle the problem of sifting through content before finally opting – in true computing student style – that it would be easiest to try visualise what we were doing in an algorithmic manner. I’d put the ideal user flow into a graphing tool and see what came out, since if there were any clear groups or flow paths then they would be sensible places to start organising things. Out came Graphviz and I began to build an ideal user flow, based mostly on my own experience of trying to find information.
10 minutes in, and it doesn’t look pretty. I’d not even finished putting things in and it was already looking like a scribble of epic proportions.
Just a small part of an idealised web user flow.
It looks like we may need to abandon the notion of ‘nested’ URIs ((Uniform Resource Indicators, otherwise known as ‘addresses’)) as much as possible, and instead opt for a simple “type/identifier” method. In line with the principles of REST ((REpresentional State Transfer, a type of machine interface methodology for exchange of data)), these URIs should also be happy with appended actions to make life easier for those trying to get data. So, let’s get started with a few key types of information.
