The Web Editor: Institutional Troubleshooter

Maintenance problems signal a painful truth for Web Editors (or those occupying similar roles). They need to change the institutions within which they work.

As I learn more about the institution within which I work I frequently encounter a recurring truism: those with the most to offer in terms of content are often the least able to publish it via the web. Instead, they are skilled at managing a digital to print workflow i.e., from word-processor to printer; from printer to photocopier; from photocopier to manilla. They are rarely skilled for digital to web. When the need or desire arises for content to be published to the web, they are typically faced with three options: treat HTML as a one of the file formats offered by their word-processor; acquire the skills and/ or start using a web authoring program; delegate the task to somebody else. Not only are these short-term solutions to institutional problems, they are the source of so many problems troubling web editors.

Each of these approaches produces web-sites whose parts are unreliable (is the content there or isn’t it?), inaccessible (where is it?), invalid (this is old, isn’t it?) and of low quality (why does the background keep changing?). These variables cannot be controlled when the providers of content are faced with barriers to the provision of content. The struggle to maintain all four soon gives way to simply ‘getting it out there’. On paper this might result in letters with the wrong margin or occasional pagination problems. With web-sites, the effect is often more serious - pages without navigational links, pages that skew the institutional template, pages that get uploaded but forgotten, pages that aren’t linked to the rest of the site. In short, a lack of cohesion. Multi-author environments don’t offer cohesion for free.

An institution’s web-presence (whether one or more sites; freely accessible or restricted) needs cohesion between its parts. Meaningful connections between these parts underlies the distinction between a web-site and an ftp-site. The connections between the parts are fine-grained and context sensitive, presenting parts that are greater than the sum of their parts. An audience looking to satisfy a need must a least benefit from the knowledge that their need cannot be satisfied - the minimum a web-site can offer. A web-site needs to be structured with more than its content in mind to achieve this.

Cohesion extends to presentation. The high standards set by print are often lost. Why is speling punctuation typographyspacingattention to detail indexing so important - especially in an academic environment? They’re important because they support or even enable the relationship between the reader and the content. That they’re hard to maintain reflects, in part, the quality of the institution providing the content. This is as true for the web as it is for print.

Cohesion extends beyond the institutional web-site - the site is part of the larger web and integration isn’t a given. Forming connections with external content reflects a substantial part of what is often referred to a ‘Web Marketing’. In fact we could take cohesion into many spheres, including legal.

Producing print documents (from an office printer) is [now] straightforward - send the document to the printer. The challenge is to offer the same simplicity for digital to web. This is what content providers expect. For the skilled, digital to web is still taxing. But this skill-set needs to be constantly updated. Either web publishing is work or hobby but for most content providers it is neither. Web publishing is never whole; rather a hole.

For content providers, structure is frequently defined by presentation - rarely through some received hierarchy. The logical structure of a document is defined visually, typically through a hierarchy of headings (headings of different sizes or weights). Others will use numbered headings to capture sub-divisions - even to the level of organisation common to legal documents. But even here, the structure is for the reader’s eye and not the machine’s ‘finger’. As printing allows documents to be paginated - the unit is the page - organisation is often simple and linear. If the linear order is lost it can be re-established using meta information on the page such as page numbers, chapter headings, author details, etc. When this same document is instead published to the web, it requires translation - a person [still] needs to map the document’s structure onto a series of web-pages by learning the structure from the presentation. The key here is that the hardwork is not just in translating the content but also in translating its structure. Authoring tools are still poor when it comes to translating content; hopeless at translating structure. This will continue until structure is encoded during authoring.

Fitting documents into a web-site presents further difficulties. Often this relies on the judgement of the Web Editor or local ‘web person’. Again, the content will need to be interpreted to enable an appropriate position to be selected and then the connections both to and from the pages need to be manually inserted - the patch needs to be threaded into the quilt.

Expectations dictate that an institution’s web-site should provide a wealth of content; that needs unrecognised by its architects must be satisfied, and often without its architects’ knowledge. If the need for content can be met by the institution then it should be met by its web-site - at least in part. But satisfying these needs - a copy of the postgraduate prospectus, a list of staff members in a department, knowledge of a peer’s research activities - is not the role of the web editor. It is the role of the institution employing the web editor. The web editor’s role is to provide a framework within which this can occur, through the medium of the web. This doesn’t exclude the web editor from participation: bravo those replies to requests for content not found; for web-pages written from knowledge gleaned.

The web editor is faced with a daily dilemma - how to populate the web-site with content whilst having few resources to call upon. This creates a constant battle between ‘do it yourself’ and marketing web strategies internally (you can’t just sell strategies to senior management; you have to sell them to departments as well). The ‘wearing of several hats’ is not a description of the role but a comment on the singularity of resource. The hats are destined for team members still to be employed/ obtained - sharing the same space and pursuing common objectives. Building the framework is the greatest challenge facing web editors. Doing so alone or through some institutional norm of reciprocity is going to be more than hard work. Of the three main resources - people, time and money - we all know which one expands.

The heart of the matter is that institutional web-sites need to be multi-author. Typically each author works on specific, often minority, content (though still important). Much institutional copy is produced by multiple authors on the other hand. The web editor’s priority will inevitably be geared toward institutional content and its cohesiveness with the content produced by other authors. Ultimately this results in being torn between the institution and its parts. With content providers adopting the short-term strategies noted earlier, the web editor’s role moves closer to support of individuals to ensure cohesion rather than maintaining the big picture. Getting content on-line often starts with a struggle to identify and enable the source - the content provider. Inevitably the web editor is drawn into issues of support and spending increasing amounts of time managing logistics. Provision of content is dependent upon workflows outside of their control.

The winning strategy is one that allows anyone in the institution the ability to publish to the web as simply as to print but in such a way as to ensure that cohesion between contributed content is guaranteed. The web editor must therefore be concerned with the flow of content from source (e.g., the content provider’s desktop) and not just with translation of existing or received copy. The content needs to pass through a recognisable workflow that offers minimal barriers to contribution (and automates presentation) but constraints upon destination: can it go on-line? who has authority for release? where will it be positioned? when does it need to be reviewed / updated?

Achieving this strategy is dependent upon content being authored in a format that either structures it at source (and that presentation follows on from this) or encapsulates the content. XML (including RDF) and tools that use it promise a way to structure content at source - to enable structure to be embedded as part of the authoring process and even to happen as a result of the authoring process. PDF offers a solution to encapsulating content. It is clear to me that a great deal can be done now to address cohesion using these two technologies. PDF may not be ideal for web delivery but it at least enters the content into the workflow with minimal barriers, and therefore establishes the workflow. If the tools mature, we may see content entering the workflow without the need for encapsulation.

As Philip Ward (Technical Support Operations, Ford of Europe) pointed out at the SGML, XML, and Databases meeting in October 1998, solutions to information (or content) management require the institution adopting them to change. The workflow needs to adapt. I believe this is as true for educational institutions as it for commercial institutions. This is difficult to accept when one takes in the breadth of the institution’s focus - teaching and/or research. But isn’t this CAL? And why are we dealing with it?

Further Reading

• At the Event: SGML, XML, and Databases, Ariadne, issue 18
  <URL: http://www.ariadne.ac.uk/issue18/emmott-sgml/>
• Content Management Tools, XML.COM
  <URL: http://www.xml.com/xml/pub/pt/Content_Management>
• Extensible Markup Language, W3C
  <URL: http://www.w3.org/XML/>
• Information Architecture for the World Wide Web, O’Reilly
  <URL: http://www.oreilly.com/catalog/infotecture/>
• PDF / Acrobat , Adobe
  <URL: http://www.adobe.com/prodindex/acrobat/main.html>

Author Details

Stephen Emmott, Web Editor
Press & Public Relations Office
Room 4.14, Waterloo Bridge House
57 Waterloo Road, London SE1 8WA

Website: http://www.kcl.ac.uk/
Email: stephen.emmott@kcl.ac.uk
Tel: +44 (0) 171 872 3342; Fax: +44 (0) 171 872 0214

Stephen Emmott is the Web Editor at King’s College London. He is a founder member of .gamut - a forum for web editors in London.

Are you a web site editor? Would you like to write an article for Ariadne giving your views? If so, please send email to ariadne@ukoln.ac.uk