Developing a Website in the Arts and Humanities
Introduction
Because of the incredible power of the World Wide Web as a device for rapid communication, most academic institutions, departments and researchers have established websites to communicate their ideas. But as with the Web as a whole, there is a real disparity in the quality of the academic websites presented. Content is variable in quality, but above all, there is often bad design in terms of usability and presentation. Not only does this discourage potential users from exploring the ideas on websites and make them question their validity, but it can also be breaking the law. Recent legislation designed to make sure that websites are accessible to all, regardless of any disability, means that web developers have a legal responsibility to execute best practice in the designing of websites.
This AHDS Information Paper looks at the issues involved in building websites for those working in the arts and humanities. It shows the importance of defining and planning a website, the value of good design, the need for a standards-based approach and also covers some of the modest technical skills required for website creation. By continuing from the ideas expounded in this paper it is hoped that web developers in the arts and humanities will build websites that not only contain valuable ideas, information, and research and teaching material, but do so in a way that manages to successfully communicate this to the user.
Defining Use
Judging from current development of websites in the academic community, they are often considered as brochures, giving a little bit of background information about a project or department, a few staff contact details and photographs and little else. Such a narrow conception misses out on many of the capabilities of a website to provide relevant and detailed information for its visitors.
It is therefore vital for someone creating a website to define, at the outset, what audience the website is aimed at and what purpose the website will serve. Different user groups have different needs in terms of the language and content of a website as well as its organisation and design. Potential user groups for an academic website could include students, a particular set of researchers, arts and humanities scholars in general, the general public, or indeed a mix of these groups. And in terms of the website's function, it could help bring together and develop a particular research community; it could house a digitised resource; it could just be giving information on a project; or indeed it could have multiple aims.
Focussing at an early stage on the target and purpose of a website will help ensure that the content of the website is successfully tailored for its audience. For a more in-depth look at the issue of planning for users, readers are urged to look at Kilbride's (2004) more general Information Paper on defining usage in digitisation projects and a useful article on the web designers' website, A List Apart.
Good Design
While the content of any website is undoubtedly the most important factor, the significance of good design should not be underestimated. In most organisations of any size responsibility for web site creation and management will lie with a team of people. The visual design of the website will be overseen by an experienced graphic designer or art director. However for smaller projects, such as those funded through the AHRC, it will often be impractical to employ a designer, and responsibility for web site creation will often fall to someone who does not have much design experience. If that is the case, then it will help to follow some basic rules to ensure that the visual design of the website is as clear and as simple as possible.
The design of your site should be determined by the content and by how the information is structured. Once you have defined the purpose of your website, it is very useful to create a website map showing all the individual web pages (e.g. staff list, events page, links page, publications page ...) and associated files which make up the site and the potential relationships between them. Several WYSIWYG - 'What You See Is What You Get' - software tools (see below for more information) can help in automating this process. This site map should be included as a visual aid for users on the site, and it can also be very helpful to have a navigation bar on each web page showing a structure as a hierarchy, and how users can move between pages e.g. Jakob Nielsen describes how arrows (sometimes called 'breadcrumbs') can be used to indicate moving deeper and deeper into the site.
The importance of good homepage design has been well documented (Top Ten Guidelines for Homepage Usability and The Ten Most Violated Homepage Design Guidelines ) - this is the page that will be seen first by most people and so it is important to make the right impression. Most web users will scan from left to right and from top to bottom, so it is important that key information and navigational links appear in the top left of the screen, and that information is laid out on screen in a logical order. The Three-Click Rule of web design states that if users can't find what they're looking for within three clicks, they're likely to get frustrated and leave the site. Therefore it is vital to ensure that important information is not buried too deeply in your site.
Usability - making the website as user-friendly as possible - should be at the heart of what you do. Even the most insightful designer can only create a highly usable system through receiving feedback from people who actually use the system. Simple user testing is essential to ensure that users can easily get to the information that they want. Ideally, you should involve users throughout the design phase. Get four to five potential users to sit down by a computer (one at a time) and test your design while they think out loud about the actions they are taking. It takes almost no time to run such a study to get a list of the top ten (or more) changes that need to be made to the design. Jakob Neilsen's site provides a good introduction to these issues and suggestions for further reading, e.g. Usability 101: Introduction to Usability.
If in doubt keep it simple! Unless you are an experienced graphic designer it is wise to avoid over-using images (more on this below). Good design must react with fluidity to variation in browser brand and version, monitor settings, window dimensions and other user diversities e.g. the same web site can look very different when viewed at 800x600 resolution using Internet Explorer compared to 1024x768 resolution using Netscape Navigator - you must ensure that you have tested your site across different operating systems, different browsers, different screen resolutions, etc. The best way to ensure that your site will always look as you intended is through the use of web standards.
Use of Web Standards
In the early days of web design, HTML was used as much as a presentational tool as it was for its intended use as a way of structuring web pages. As a result, it was often very difficult to make changes to the look and feel of a web site without completely re-writing the underlying code. Now, by using Cascading Style Sheets (CSS) and XHTML it is possible to almost completely separate style from content information, thus ensuring that web content can be quickly and simply re-used, and that the visual design of any site can be changed relatively easily. CSS allows users the freedom to e.g. change font size to suit their own preferences, an essential feature of accessible design as discussed below. It is important to talk to the team responsible for web site management at your own institution - they will most likely have clear visual guidelines for the production of departmental/project web pages, and can offer advice on the use of pre-existing CSS styles and templates.
The case for standards compliant, structurally correct XHTML markup is simple: it makes use of the features of HTML as they were designed, it is efficient in what it does (describing the nature of various pieces of content that compose a document), and it is future-proof i.e. if need be, good but deprecated markup can be easily converted to a newer version. This final point is essential to the long term sustainability of any website. WYSIWYG editors such as Macromedia Dreamweaver will now easily allow you to specify that the web pages you create are XHTML compliant. Designing and building with these standards simplifies and lowers the cost of production, while delivering sites that are accessible to more people and more types of Internet devices. Sites developed along these lines will continue to function correctly as traditional desktop browsers evolve, and as new Internet devices come to market.
"The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect." -- Tim Berners-Lee, W3C Director and inventor of the World Wide Web
The World Wide Web Consortium (W3C) is the Internet governing body, and its commitment to lead the Web to its full potential includes promoting a high degree of usability for people with disabilities. The Web Accessibility Initiative (WAI), in coordination with organisations around the world, pursues accessibility of the Web through five primary areas of work: technology, guidelines, tools, education & outreach, and research & development. In the UK, the introduction of the Disability Discrimination Act (DDA) has meant that any service provider must ensure that their website is fully accessible to all users, regardless of disability. Section III of the DDA, which refers to accessible websites, came into force on 1st October 1999 and the Code of Practice for this section of the DDA was published on 27th May 2002. This means that the majority of websites which do not meet accessibility criteria are already in breach of the law and, although there have been no prosecution cases, the risk of legal action exists. A recent article in Digital Web Magazine by a W3C specialist outlines the importance of making accessible design an integral part of your project.
It's widely believed that if, or perhaps more appropriately when, a case makes it to court that the W3C accessibility guidelines will be used to assess a website's accessibility and ultimately decide the outcome of the case. The full list of Web Accessibility guidelines can be found on the WAI website. To further complicate matters, the W3C offers three different levels of compliance. Priority 1 guidelines, (which must be satisfied according to the W3C) will almost certainly have to be adhered to. Priority 2 guidelines (which should be satisfied and are the EU recommended level of compliance), or some part of, will probably need to be adhered to too. An example of a Priority 1 guideline is to 'provide a text equivalent for every non-text element on a web page e.g. by using "alt" tags for all images'. It is highly recommended that individuals creating web sites as part of research projects discuss these issues with members of their own institutional web teams at an early stage - they will be familiar with the potential pitfalls and can help to ensure that project web sites comply with the necessary WAI guidelines.
There are several useful online tools available from the W3C site for checking the validity of web code and Bobby is a good online tool for testing web content accessibility. The Web Standards Project provides another good starting point for exploration of the importance of designing using standards.
A note on the use of Macromedia Flash: the standard advice to those creating academic websites used to be 'avoid generic software such as Flash'. However, in the last 2 years Macromedia has included many more accessibility features in the underlying technology of tools like Flash, as well as standard GUI components so that users don't have to puzzle out the meaning of features like homemade scrollbars. These changes are a major triumph for usability and proof that big companies can be made to listen. That said, many designers are still not aware of these new accessibility features and continue to produce Flash websites which do not meet acceptable standards - unless you or your project team has lots of Flash design experience, then it is probably still wise to concentrate on a standard HTML based approach. Where you do include Flash elements in your website, it is a good idea to also offer a non-Flash alternative version; there are still many browsers that do not have the appropriate plug-in that support Flash features.
Other Issues
Page Size / Use of Graphics / Copyright
In the early days of the Web, it was vital to keep the file size of each webpage to a minimum. Limited bandwidth and the prevalence of modems meant that even average-sized pages (i.e. those around 50kb) could take many boring seconds to download, discouraging users from exploration. Smaller text-only pages were not so much of a problem, but any embedded graphics files (such as jpgs or gifs) needed to be compressed to ensure that they did not take too long to download. With the advent of broadband and the use of JANET (Joint Academic Network), which underpins Internet usage in higher and further education, the size of web pages is less of a problem - even large pages and files are downloaded quickly. However, website creators should still take time to reduce the file size of their html pages, and especially their jpg and gif graphics. Users outside the JANET network (e.g. those working from home, or international users) may still have difficulties in downloading larger pages, thus cutting them off as users.
There is another reason to be careful with the use of graphics, for without an experienced hand, web graphics can look crude and unpresentable. Website developers should be wary of planning visually rich websites if they do not have the skills to create the graphics in the first place.
Web editors often wish to add images to their site to add some visual focus. While this can be an effective technique, editors again need to be aware of not misusing images and damaging the visual appearance of their site. One also needs to aware of copyright issues. Using an image on the web is essentially a form of republication; thus editors must ensure that they have obtained the necessary permissions before displaying an image. Whilst it is common practice to import images from other websites, those working in a professional context need to remember that they are running the risk of legal action if they use an image for which suitable permission has not been obtained. See the AHDS Copyright Page for more information.
URI Naming and Stability
When it comes to associating web pages to a URI (Uniform Resource Indicator - the web address that you type in at the top of a browser), one needs to consider the two parts of the URI. The first part is the domain (for example http://ahds.ac.uk/ ) and the second part is the directory structure (e.g. creating/information-papers/website-construction/index.htm), devised by the website designer when inserting web pages into particular folders.
Website creators often assume that they have to accept the URI domain of the institution in which they are working. In many cases, this is the most convenient option. But one may want to contact a university web support team to discuss alternatives. In terms of identity and convenience for users, having your own domain name provides a more immediate link to the website, as well making it easier to forge your own identity. For example www.project.ac.uk is a more memorable URI than www.university.ac.uk/depts/humanities/staff/project
The second part of the URI is up to those who manage the website. Website creators, especially if there are to be multiple contributors to a website, should organise short policies to ensure that the directory structure remains consistent. In the first place, this involves devising methods to ensure web pages are logically ordered. For example, the AHDS site has sub-directories for those applying for AHRC funding (http://ahds.ac.uk/ahrc/), for those depositing resources (http://ahds.ac.uk/depositing/), or for news and events (http://ahds.ac.uk/news/). The policy should also decide on other naming conventions - for example the use of hyphens, abbreviations, suffixes etc. More information is available from Ariadne magazine.
Another factor to consider in developing URIs is their potential longevity. If other web editors start installing links from their websites to yours, and then your web pages move positions, users will often be unable to reach the location they require. Website developers should try and ensure that the URIs that their website utilises at the outset will continue to exist in the medium term at least. In some cases, institutional changes mean that it is inevitable that URIs will change; in this case, web editors should ensure that re-directs are in place, so that users visiting the old URIs are immediately transported to the new address.
Metadata / search engine optimisation
For some sites, it will be important to attract new, relevant visitors to the site. One method that can contribute to this is search-engine optimisation, i.e. the process of tailoring a website so that its ranking appears higher in the results of search engines such as Google, Yahoo or MSN. Search-engine optimisation encompasses many techniques. One is to ensure that there are plenty of incoming links to your site; some search engines take this as unofficial confirmation of the importance of your site and therefore place it higher in their rankings. Key pages on your website should also be updated frequently; not only does this mean users are more likely to return to your site to find new information, but it also gains favour in some search engine rankings. Web managers should also consider submitting details of their resource to Humbul, a catalogue developed specifically for those working in the arts and humanities, as well as the general search engines.
The final technique is to add metadata to actual html pages. Such metadata is usually hidden from the user, but visible to the automated search engine robots that do the cataloguing work for search engines. Metadata is simply cataloguing information that can accompany or be inserted into any digital object. For web pages, the generic metadata standard, Dublin Core, is recommended. Dublin Core consists of 15 elements which can define any webpage (or any other digital object). For websites, only four or five of these tend to be used and are integrated into a page of html using the <meta> tag. For example
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org" />
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1" />
<title>UKOLN</title>
<meta name="DC.title" content="UKOLN" />
<meta name="DC.subject"
content="national centre; digital information management;
cultural heritage; library; awareness; research;
information services; public library networking;
bibliographic management; distributed systems; metadata;
resource discovery; conferences; lectures; workshops" />
<meta name="DC.description"
content="UKOLN is a national focus of expertise in
digital information management.
It provides policy, research and awareness services to
the UK library, information and cultural heritage communities.
UKOLN is based at the University of Bath." />
<meta name="DC.creator"
content="Web-support Team, web-support@ukoln.ac.uk" />
More information can be found on the UKOLN website.
Adding metadata to a webpage also helps with basic administration. While larger websites may have other systems for recording such information, information such as Page Creator, Date Created, Date Modified can provide valuable information on the currency of the information on the web pages. On the AHDS site, the Date Modified metadata is also displayed at the bottom of the page. This reassures viewers as to the currency of the information displayed within the page.
Publishing a Website
Nearly all universities will be able to act as a host (commonly known as an ISP - Internet Service Provider) for (non-personal) pages developed by a member of staff. Most universities now have dedicated web teams (either at a general or faculty-based level), and it is to them that potential web editors should pay a call when planning a website.
Web policies in each university differ, and this may have an effect on how a project carries out the publication of its website. Larger universities run Content Management Systems (CMS) to control content and layout of their university sites. In effect, the system is a publication tool that mediates between the user entering content and the finished website. CMSs can have the advantage in that they can be easy to run, requiring little technical knowledge to update the website, but can restrict the way the webpage is presented, and subsumes the identity of the project within that of the institution. This can be important for projects that have particular digital collections that they want to disseminate online or for projects that have many institutions involved.
In some cases, universities may be happy to give (sometimes on payment of a fee) server space to a member of staff or team for them to use without the restrictions of a CMS (although there are usually some pieces of content which still fall under university web policies). In other cases, web developers may wish to look outside universities for private hosting, but this is liable to cost more and identifying a trustworthy ISP can be a time-consuming business.
Once server space has been organised, this can be populated with the pre-created web pages.
Editing and Managing the Website
Once the website is up and running, it requires maintenance for a variety of tasks. This includes fixing broken links, responding to emails, testing for standards validity and most importantly updating and inserting new content. If the quantity of content is high, then it may be necessary to have numerous web content providers who have the capability to publish. However, as each one of then needs to be aware of the design and accessibility issues outlined above, and it can cause less problems if publication is channelled through a web editor, rather than permitting multiple contributions.
Websites that are supported by projects with limited funding also need to consider what will happen to the website once there is no longer funding and staff to maintain it. Without suitable maintenance, links can become broken, content out-of-date and URIs claimed by other sources. If you are hoping to develop a website which you wish to remain a constant source of information, plans need to be in place to ensure this can happen. This can mean being on the lookout for extra funding or speaking with your institution so that they can provide basic support for the website's maintenance. It some cases it may be worth discussing the matter with the AHDS. While the AHDS does not currently preserve or host websites, the possibilities of adopting this role are currently being discussed.
Software
There are various software tools available for creating webpages. Whilst it takes time to learn them (either via courses provided by the institution or via the self-help tutorials within the programs themselves), this can make the process of website editing quicker in the long term. The two most noted are Adobe Go Live and Macromedia Dreamweaver, both examples of WYSIWYG software in that users do not have to deal with the html code itself, but allow them to layout the content on the screen as desired. However, such software is not normally on academic computers, and needs to be ordered - this takes time and money from department budgets. A free, open-source alternative is Nvu.
While this provides added convenience, the underlying code developed by such tools can occasionally clash with the web standards mentioned above. For this reason, web editors often prefer to code the html by hand using simple text editors. Common practice amongst web practitioners is to use both. Web editors will also need a FTP (File Transfer Protocol) program to transfer the files from their own computer to the university server. Often these are embedded in larger web creation programs, such as Dreamweaver. If not university web teams will have a standard application for staff to use.
Universities or individual departments may already possess licences for such software. If not, then web editors should ensure that they take advantage of educational discounts to purchase much cheaper versions. For large websites that are likely to be maintained for a long time, web editors may want to investigate their own Content Management System, of which there are countless types of on the market (try Ariadne for a slightly dated but useful introduction) These obviously cost more as they need to be purchased, but they can provide more control and cut out some of the repetitive tasks in editing a website.
Examples of good practice
AHRC Research Centre for Irish and Scottish Studies
AHRC Research Centre for Editing Lives and Letters
Further Reading
QA Focus - Briefing Papers on Website Access
Norm Carr, Tim Meehan (2005), "What's the Problem?", A List Apart, Issue No. 193
Jakob Neilsen (Tips from a usability expert)
Matt May, Accessibility From The Ground Up
The X(HTML) Files: Coding Standards Using XHTML
Checklist of Checkpoints for Web Content Accessibility Guidelines 1.0
W3C Quality Assurance Toolbox (Various tools for checking the validity of your pages)
Bobby (Tool for testing Web content accessibility)
The Web Standards Project
Adding metadata to your web pages
Paul Browning and Mike Lowndes (2001), "Content Management Systems: Who needs them?", Ariadne, Vol.30
Brian Kelly (2002) "Web Focus:Guidelines For URI Naming Policies", Ariadne, Vol.31