What makes a ‘webmaster’?

In my job at the moment, I’m considering what it means to have responsibility for a website – what does this entail? A term that is often used in this respect is ‘webmaster’, but what does this mean? It’s a pretty vague term, but it’s used an awful lot – it’s often seen as text at the bottom of a website page, usually with some sort of contact email address hyperlink.

I’ll try and define what I think a webmaster is – it’s more often than not someone whose real job title is ‘software engineer’, ‘software developer’, ‘systems administrator’ or even ‘computing officer’ – and who is seen by people with a stake in the succesful operation of a website as the person to go to about all technical matters relating to that website.

What a webmaster does not do, in terms of initially developing a website or maintaining it, are things like establishing the business case for the website, or gathering user requirements. These are often presented to the webmaster as faits accomplis. It’s my belief also that a webmaster is not generally responsible for authoring the content of a website.

It’s left to the webmaster to do the ‘techie’ stuff to make the website appear on the internet and to do all the things the website is supposed to do in user’s browsers. And what are these ‘techie’ things? I think they divide into two distinct areas:

• Interface graphic design incorporating usability and HCI issues
• Software development incorporating server administration, business logic & data modelling and coding

These can be thought of as the ‘front-end’ of a website and the ‘back-end’, respectively. The work involved in developing and maintaining a website can be categorised easily by these two concepts. They are quite separate, and require different skills (although I believe that a good web graphic designer should have an in-depth knowledge of digital image formats, HTML and CSS). Many people believe that they are in some ways mutually incompatible – the first requires a more artistic mindset and the second more of an engineering mindset.

In a perfect world this would mean that they should be done by two different people or teams of people (although of course strong communication and cooperation is required between the two). It is very rare that a single person is skilled in both areas – and hence a ‘webmaster’ should never really be a single person.

It quite often is a single person though – and this explains those websites that look great but don’t actually do anything or have any content, and also those websites that have loads of exciting functionality and content but look awful and in which it’s impossible to find anything. The goal here is to identify which side of the divide your strengths and weaknesses lie, and plan accordingly (I’m very much an engineer rather than an artist).

There are however, some aspects of being responsible for a website that a webmaster has to think about all the time, and that cut across this divide:

• Security (e.g. password discipline, form input validation)
• Conformance to standards (e.g. W3C WAI, XHTML)
• Cost restrictions (e.g. use of GPL software)
• Maintainability (e.g. versioning, updating & editing mechanisms)
• Integration with existing infrastructure (e.g. help desk support, shared database servers, firewalls)
• Webserver performance (e.g. backups, uptime guarantees)
• Context on the Internet (e.g. SEO, domain name registrations)
• Usage statistics generation (e.g. Analog or customised applications)

Being a webmaster is not as cool as it once was and the term has become associated with the worst excesses of the dot-com bubble of the late 90s – Nathan Barley being a good example. So perhaps it’s best if we all quietly drop the term?