UK Web Focus (Brian Kelly)

Innovation and best practices for the Web

Case Study: Managing the Closure of a Project Web Site

Posted by Brian Kelly on 3 Sep 2012

The Importance of Managing the Closure of Project Web Sites

The project has been successfully completed. It is therefore time to move on to new areas of work. However just as there is likely to be a need for the project paperwork to be completed after the project deliverables have been submitted, there will also be a need to manage the closure of the project web site. This can be tiresome, especially when there are interesting new projects which will need to be started. However a failure to manage the closure of a project web site can be counter-productive – remember that the project’s web site may be looked at when evaluators are marking bids for new projects and if the project web site fails to work or contains inaccurate or misleading content, the evaluators could potentially be influenced by such negative experiences.

Best Practices

Many of the best practices for closing a project blog will appear obvious – but that does not necessarily mean they are implemented! This post therefore summarises best practices and provides an example of a project web site which was closed 8 years ago in order to investigate some of the practices which may only become apparent over a period of time.

Best practices relevant to visitors

The following examples of best practices are intended to ensure that visitors accessing the project web site are aware of the status of the project and do not encounter misleading information. Implementation of these best practices should be regarded as essential.

Provide a summary of the status of the project and links to key resources: The visitor who arrives at the project web site via Google may well be unaware of the status of the project. You should project easily found information about the status of the project. Initially this may state when the project was completed although at a later date you may wish to add links to related follow-up work. You should also provide easily found links to the key resources related to the project which may include the final report and articles and papers related to the project’s activities.

Manage the content of the web site: As well as providing information about the work of the project, you should ensure that dated information or information which may become dated or misleading is edited or removed. This might include statements such as “Our workshop will be held next April” and “We will do xxx” – although such statements may legitimately continue to be provided in initial project planning documents. Dates should include years: for example the statement “Our workshop was held last April” may cause visitors to try to find workshop outputs if they are felt to be recent, but not if they are 10 years old!

Best practices relevant to technical staff

The following practices are intended to ensure that visitors accessing the project web site are aware of the status of the project and do not find misleading information. Implementation of these practices should be regarded as useful, especially if the project web site makes extensive use of server-side technologies or the site is likely to be reused elsewhere.

Audit the technologies used: Provide information which summarises the technologies used to deliver the project web site. For a simple web site, this might simply state that the web site is based on an Apache server which hosts HTML and CSS files, together with MS Word, MS PowerPoint and PDF files. A more complicated web site might be based on a CMS, such as Drupal, a blog platform such as WordPress, a database server such as MySQL, a search engine or a scripting environment, such as PHP.

Manage the technologies used on the web site: Once you have audited the technologies used on the project web site you may wish to switch off technologies which may require ongoing maintenance and support. You may wish to create a static web site of content managed by server-side technologies in order to simplify the technical infrastructure and minimise ongoing technical support requirements.

Audit third-party services used: Provide information which summarises third-party services used to deliver content or services. This might include Flickr badges, Twitter feeds, etc.

Manage the external services used to support the project web site: You may wish to switch off third-party services which are no longer needed, such as a dynamic Twitter feed. You should also ensure that the account details (username, password and email address used to authenticate changes) are also managed and aren’t owned solely by an individual (who may leave the organisation).

Verify the long-term persistency of the project Web site’s domain: If the project Web site is not hosted on the institution’s main Web site there will be a need to ensure that the project’s domain name persists and the service continues to be operational. If a domain name has been purchased it may be sensible to ensure that the domain is registered for an appropriate period of time. As described in a post entitled Link Checking For Old Web Sites it may be useful to set up an automated alert so that you receive notification if the Web site becomes unavailable.

Case Study: The QA Focus Web site

The JISC-funded QA Focus project ran from January 2002 to July 2004. The aim of the project was stated on the project home page:

QA Focus’s remit was to help ensure that project deliverables were interoperable and widely accessible. We sought to ensure that projects deployed appropriate standards and best practices. We did this by providing support materials which explained the recommended standards and best practices and carrying out a number of surveys which helped to share evolving practices across the projects.

We stopped developing the QA Focus project web site in 2004 and implemented some of the best practices given above. The project home page contained links to the project’s Final Report and the Impact Analysis statement, descriptions of the QA methodology developed by the project and accompanying briefing papers, case studies, papers and articles as well as names of the staff involved in the project delivery.

In some respects the freezing of the project web site was simple, as the project took place prior to the availability of many Web 2.0 services. However the project web site did make use of a database hosted on a Windows NT server which had to be discontinued. In addition as well as myself and my colleague Marieke Guy, the project was supported initially by staff at TASI (now JISC Digital Media) but for most of the life of the project by staff at the AHDS, an organisation which no longer exists, so it will not be easy to recollect memories of the technical decisions which may have been made.

In revisiting the QA Focus web site it was noticed that two third-party services had been used: the AvantGo service had been used to provide access to the web site on a PDA and SiteMeter had been used to provide usage statistics. According to Wikipedia the Avantgo service was discontinued in 2009. However the AvantGo page still provided a link to the service which could potentially be embarrassing. This link was removed. The embedded SiteMeter service had been removed previously.

The project web site contains a number of RSS feeds which provide access to the main project deliverables. Since this are simple static files and the content will not change, these files have been kept. However it was noticed that a link to an email service which informed subscribers of newly published documents was still available. Since no new documents will be published, and the status of the RSS to email service is unknown, this link was removed.

Although the links to the database server had been removed it was realised that the web site search engine appeared to provide the one remaining example of a server-side technology used to support the project web site. The search link on the web site’s navigation bar provides access to two search facilities: the UKOLN web site’s SWISH-E service and a Google search of the project web site. It is felt that this will provide a useful service and the duplication will minimise problems if either of the search facilities stops working.

Audits of the technical robustness of the project web site, covering link checking and HTML conformance, had been carried out in 2004, while the project was still live. These audits were repeated recently in order to ensure that no errors had been introduced over the previous 8 years. Following this work a page (which is illustrated) providing information on the technical architecture and links to the automated surveys, together with a summary of the main content areas and file types was provided in order that a public record is available. Links to the page have been added to the project home page. In addition an “Archived site” watermark was added to key pages on the project web site.

The Xenu link checker also provided a report on the file formats found on the web site. This provided a useful way of complementing the knowledge I have about the web site. It should be noted, however, that the video/unknown files listed in the table actually refer to WMF (Windows Metafile format) images which were produced in conversion of Microsoft PowerPoint files to HTML format. The table, which has been included on the QA Focus web site, is reproduced below.

MIME type count % count Σ size Σ size (KB) % size min size max size Ø size Ø size (KB) Ø time
text/html 662 URLs 48.71% 7277902 Bytes (7107 KB) 11.38% 543 Bytes 684983 Bytes 10993 Bytes (10 KB) 0.026
text/xml 6 URLs 0.44% 7600 Bytes (7 KB) 0.01% 503 Bytes 2731 Bytes 1266 Bytes (1 KB)
application/xml 94 URLs 6.92% 535671 Bytes (523 KB) 0.84% 1682 Bytes 53907 Bytes 5698 Bytes (5 KB)
text/css 13 URLs 0.96% 32101 Bytes (31 KB) 0.05% 180 Bytes 12144 Bytes 2469 Bytes (2 KB)
image/gif 81 URLs 5.96% 1811489 Bytes (1769 KB) 2.83% 50 Bytes 120552 Bytes 22364 Bytes (21 KB)
image/png 148 URLs 10.89% 12472014 Bytes (12179 KB) 19.50% 2998 Bytes 379755 Bytes 84270 Bytes (82 KB)
application/msword 263 URLs 19.35% 29181952 Bytes (28498 KB) 45.64% 34304 Bytes 1861120 Bytes 110957 Bytes (108 KB)
application/pdf 4 URLs 0.29% 931936 Bytes (910 KB) 1.46% 131571 Bytes 318749 Bytes 232984 Bytes (227 KB)
image/jpeg 6 URLs 0.44% 103860 Bytes (101 KB) 0.16% 3284 Bytes 34689 Bytes 17310 Bytes (16 KB)
application/ 38 URLs 2.80% 10736640 Bytes (10485 KB) 16.79% 61952 Bytes 1052160 Bytes 282543 Bytes (275 KB)
text/plain 8 URLs 0.59% 98528 Bytes (96 KB) 0.15% 308 Bytes 57382 Bytes 12316 Bytes (12 KB)
video/unknown 35 URLs 2.58% 733306 Bytes (716 KB) 1.15% 9486 Bytes 21400 Bytes 20951 Bytes (20 KB)
application/ 1 URLs 0.07% 22016 Bytes (21 KB) 0.03% 22016 Bytes 22016 Bytes 22016 Bytes (21 KB)
Total 1359 URLs 100.00% 63945015 Bytes (62446 KB) 100.00%

Following the audit and appropriate updates to the content of the project Web site the Web site was submitted to the British Library’s UK Web Archive service.


This case study intentionally aims to provide a simple example of a project web site hosted on the main institutional web site with limited use of server-side or client-side technologies and little use of third-party services. However even in this case study it was felt useful to document the technical architecture of the site and summarise the main content areas, especially since this work only took a couple of hours (which included writing this post).

Would it be reasonable to expect projects to provide a similar summary to the one provided for the QA Focus web site as part of the official closing of a project? I’d welcome your thoughts.

Twitter conversation from Topsy: [View]

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: