QA Focus Briefing Documents: Print All - Web
[ Home Page - Surveys - Documents - Presentations - Search ]
This page is for printing out briefing papers on web. The briefing papers are given in numerical order. Note that some of the internal links may not work.
Compliance with HTML standards is needed for a number of reasons:
The World Wide Web Consortium, W3C, recommend use of the XHTML 1.0 (or higher) standard. This has the advantage of being an XML application (allowing use of XML tools) and can be rendered by most browsers. However authoring tools in use may not yet produce XHTML. Therefore HTML 4.0 may be used.
Cascading style sheets (CSS) should be used in conjunction with XHTML/HTML to describe the appearance of Web resources.
Web resources may be created in a number of ways. Often HTML authoring tools such as DreamWeaver, FrontPage, etc. are used, although experienced HTML authors may prefer to use a simple editing tool. Another approach is to make use of a Content Management System. An alternative approach is to convert proprietary file formats (e.g. MS Word or PowerPoint). In addition sometimes proprietary formats are not converted but are stored in their native format.
A number of approaches may be taken to monitoring compliance with HTML standards. For example you can make use of validation features provided by modern HTML authoring tools, use desktop compliance tools or Web-based compliance tools.
The different types of tools can be used in different ways. Tools which are integrated with a HTML authoring tool should be used by the page author. It is important that the author is trained to use such tools on a regular basis. It should be noted that it may be difficult to address systematic errors (e.g. all files missing the DOCTYPE declaration) with this approach.
A popular approach is to make use of SSIs (server-side includes) to retrieve common features (such as headers, footers, navigation bars, etc.). This can be useful for storing HTML elements (such as the DOCTYPE declaration) in a manageable form. However this may cause validation problems if the SSI is not processed.
Another approach is to make use of a Content Management System (CMS) or similar server-side technique, such as retrieving resources from a database. In this case it is essential that the template used by the CMS complies with standards.
It may be felt necessary to separate the compliance process from the page authoring. In such cases use of a dedicated HTML checker may be needed. Such tools are often used in batch, to validate multiple files. In many cases voluminous warnings and error messages may be provided. This information may provide indications of systematic errors which should be addressed in workflow processes.
An alternative approach is to use Web-based checking services. An advantage with this approach is that the service may be used in a number of ways: the service may be used directly by entering the URL of a resource to be validated or live access to the checking service may be provided by including a link from a validation icon as used at <http://www.ukoln.ac.uk/qa-focus/> as shown in Figure 1 (this approach could be combined with use of cookies or other techniques so that the icon is only displayed to an administrator).
Another approach is to configure your Web server so that users can access the validation service by appending an option to the URL. For further information on this technique see the QA Focus briefing document A URI Interface To Web Testing Tools> at <http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-59/>. This technique can be deployed with a simple option on your Web server's configuration file.
Although it is desirable to make use of open standards such as HTML when providing access to resources on Web sites there may be occasions when it is felt necessary to use proprietary formats. For example:
If it is necessary to provide access to a proprietary file format you should not cite the URL of the proprietary file format directly. Instead you should give the URL of a native Web resource, typically a HTML page. The HTML page can provide additional information about the proprietary format, such as the format type, version details, file size, etc. If the resource is made available in an open format at a later date, the HTML page can be updated to provide access to the open format - this would not be possible if the URL of the proprietary file was used.
An example of this approach is illustrated. In this case access to MS PowerPoint slides are available from a HTML page. The link to the file contains information on the PowerPoint version details.
Various tools may be available to convert resources from a proprietary format to HTML. Many authoring tools nowadays will enable resources to be exported to HTML format. However the HTML may not comply with HTML standards or use CSS and it may not be possible to control the look-and-feel of the generated resource.
Another approach is to use a specialist conversion tool which may provide greater control over the appearance of the output, ensure compliance with HTML standards, make use of CSS, etc.
If you use a tool to convert a resource to HTML it is advisable to store the generated resource in its own directory in order to be able to manage the master resource and its surrogate separately.
You should also note that some conversion tools can be used dynamically, allowing a proprietary format to be converted to HTML on-the-fly.
MS Word files can be saved as HTML from within MS Word itself. However the HTML that is created is of poor quality, often including proprietary or deprecated HTML elements and using CSS in a form which is difficult to reuse.
MS PowerPoint files can be saved as HTML from within MS PowerPoint itself. However the Save As option provides little control over the output. The recommended approach is to use the Save As Web Page option and then to chose the Publish button. You should then ensure that the HTML can be read by all browsers (and not just IE 4.0 or later). You should also ensure that the file has a meaningful title and the output is stored in its own directory.
In some circumstances it may be possible to provide a link to an online conversion service. Use of Adobe's online conversion service for converting files from PDF is illustrated.
It should be noted that this approach may result in a loss of quality from the original resource and is dependent on the availability of the remote service. However in certain circumstances it may be useful.
When the funding for a project finishes it is normally expected that the project's Web site will continue to be available in order to ensure that information about the project, the project's findings, reports, deliverables, etc. are still available.
This document provides advice on "mothballing" a project Web site.
The entry point for the project Web site should make it clear that the project has finished and that there is no guarantee that the Web site will be maintained.
You should seek to ensure that dates on the Web site include the year - avoid content which says, for example, "The next project meeting will be held on 22 May".
You may also find it useful to make use of cascading style sheets (CSS) which could be used to, say, provide a watermark on all resources which indicate that the Web site is no longer being maintained.
Although software is not subject to deterioration due to aging, overuse, etc. software products can cease to work over time. Operating systems upgrades, upgrades to software libraries, conflicts with newly installed software, etc. can all result in software products used on a project Web site to cease working.
It is advisable to adopt a defensive approach to software used on a Web site.
There are a number of areas to be aware of:
We have outlined a number of areas in which a project Web site may degrade in quality once the project Web site has been "mothballed".
In order to minimise the likelihood of this happening and to ensure that problems can be addressed with the minimum of effort it can be useful to adopt a systematic set of procedures when mothballing a Web site.
It can be helpful to run a link checker across your Web site. You should seek to ensure that all internal links (links to resources on your own Web site) work correctly. Ideally links to external resources will also work, but it is recognised that this may be difficult to achieve. It may be useful to provide a link to a report of the link check on your Web site.
It would be helpful to provide documentation on the technical architecture of your Web site, which describes the server software used (including use of any unusual features), use of server-side scripting technologies, content management systems, etc.
It may also be useful to provide a mirror of your Web site by using a mirroring package or off-line browser. This will ensure that there is a static version of your Web site available which is not dependent on server-side technologies.
You should give some thought to contact details provided on the Web site. You will probably wish to include details of the project staff, partners, etc. However you may wish to give an indication if staff have left the organisation.
Ideally you will provide contact details which are not tied down to a particular person. This may be needed if, for example, your project Web site has been hacked and the CERT security team need to make contact.
Ideally you will ensure that your plans for mothballing your Web site are developed when you are preparing to launch your Web site!
With the growing popularity in use of mobile devices and pervasive networking on the horizon we can expect to see greater use of PDAs (Personal Digital Assistants) for accessing Web resources.
This document describes a method for accessing a Web site on a PDA. In addition this document highlights issues which may make access on a PDA more difficult.
AvantGo is a well-known Web based service which provides access to Web resources on a PDA such as a Palm or Pocket PC.
The AvantGo service is freely available from <http://www.avantgo.com/>.
Once you have registered on the service you can provide access to a number of dedicated AvantGo channels. In addition you can use an AvantGo wizard to provide access to any publicly available Web resources on your PDA.
An example of two Web sites showing the interface on a Palm is illustrated.
If you have a PDA you may find it useful to use it to provide access to your Web site, as this will enable you to access resources when you are away from your desktop PC. This may also be useful for your project partners. In addition you may wish to encourage users of your Web site to access it in this way.
AvantGo uses robot software to access your Web site and process it in a format suitable for viewing on a PDA, which typically has more limited functionality, memory, and viewing area than a desktop PC. The robot software may not process a number of features which may be regarded as standard on desktop browsers, such as frames, JavaScript, cookies, plugins, etc.
The ability to access a simplified version of your Web site can provide a useful mechanism for evaluating the ease with which your Web site can be repurposed and for testing the user interface under non-standard environments.
You should be aware of the following potential problem areas:
As well as providing enhanced access to your Web site use of tools such as AvantGo can assist in testing access to your Web site. If your Web site makes use of open standards and follows best practices it is more likely that it will be usable on a PDA and by other specialist devices.
You should note, however, that use of open standards and best practices will not guarantee that a Web site will be accessible on a PDA.
A Web sites 404 error page can be one of the most widely accessed pages on a Web site. The 404 error page can also act as an important navigational tool, helping users to quickly find the resource they were looking for. It is therefore important that 404 error pages provide adequate navigational facilities. In addition, since the page is likely to be accessed by many users, it is desirable that the page has an attractive design which reflects the Web sites look-and-feel.
Web servers will be configured with a default 404 error page. This default is typically very basic.
In the example shown the 404 page provides no branding, help information, navigational bars, etc.
Figure 1: A Basic 404 Error Message
An example of a richer 404 error page is illustrated. In this example the 404 page is branded with the Web site's colour scheme, contains the Web site's standard navigational facility and provide help information.
Figure 2: A Richer 404 Error Message
It is possible to define a number of types of 404 error pages:
An article on 404 error pages, based on a survey of 404 pages in UK Universities is available at <http://www.ariadne.ac.uk/issue20/404/>. An update is available at <http://www.ariadne.ac.uk/issue32/web-watch/>.
There are several reasons why it is important to ensure that links on Web sites work correctly:
However there are resource implications in maintaining link integrity.
A number of approaches can be taken to checking broken links.
Note that these approaches are not exclusive: Web site maintainers may choose to make use of several approaches.
There is a need to implement a policy on link checking. The policy could be that links will not be checked or fixed - this policy might be implemented for a project Web site once the funding has finished. For a small-scale project Web site the policy may be to check links when resources are added or updated or if broken links are brought to the project's attention, but not to check existing resources - this is likely to be an implicit policy for some projects.
For a Web site one which has a high visibility or gives a high priority to the effectiveness of the Web site, a pro-active link checking policy will be needed. Such a policy is likely to document the frequency of link checking, and the procedures for fixing broken links. As an example of approaches taken to link checking by a JISC service, see the article about the SOSIG subject gateway [1].
Experienced Web developers will be familiar with desktop link-checking tools, and many lists of such tools are available [2] [3]. However desktop tools normally need to be used manually. An alternative approach is to use server-based link-checking software which send email notification of broken links.
Externally-hosted link-checking tools may also be used. Tools such as LinkValet [4] can be used interactively or in batch. Such tools may provide limited checking for free, with a licence fee for more comprehensive checking.
A popular approach is to make use of SSIs (server-side includes) to retrieve common features (such as headers, footers, navigation bars, etc.). This can be useful for storing HTML elements (such as the DOCTYPE declaration) in a manageable form. However this may cause validation problems if the SSI is not processed.
Another approach is to use a browser interface to tools, possibly using a Bookmarklet [5] although UKOLN's server-based ,tools approach [6] is more manageable.
It is important to ensure that link checkers check for links other than <a href=""...> and <img src="...">. There is a need to check external JavaScript, CSS, etc. files (linked to by the <link> tag) and that checks are carried out on personalised interfaces to resources.
It should also be noted that erroneous link error reports may sometimes be produced (e.g. due to misconfigured Web servers).
Web sites which contain more than a handful of pages should provide a search facility. This is important for several reasons:
The two main approaches to the provision of search engines on a Web site are to host a search engine locally or to make use of an externally-hosted search engine.
The traditional approach is to install search engine software locally. The software may be open source (such as ht://Dig [1]) or licensed software (such as Inktomi [2]). It should be noted that the search engine software does not have to be installed on the same system as the Web server. This means that you are not constrained to using the same operating system environment for your search engine as your Web server.
Because the search engine software can hosted separately from the main Web server it may be possible to make use of an existing search engine service within the organisation which can be extended to index a new Web site.
An alternative approach is to allow a third party to index your Web site. There are a number of companies which provide such services. Some of these services are free: they may be funded by advertising revenue. Such services include Google [3], Atomz [4] and FreeFind [5].
Using a locally-installed search engine gives you control over the software. You can control the resources to be indexed and those to be excluded, the indexing frequency, the user interface, etc. However such control may have a price: you may need to have technical expertise in order to install, configure and maintain the software.
Using an externally-hosted search engine can remove the need for technical expertise: installing an externally-hosted search engine typically requires simply completing a Web form and then adding some HTML code to your Web site. However this ease-of-use has its disadvantages: typically you will lose the control over the resources to be indexed, the indexing frequency, the user interfaces, etc. In addition there is the dependency on a third party, and the dangers of a loss of service if the organisation changes its usage conditions, goes out of business, etc.
Surveys of search facilities used on UK University Web sites have been carried out since 1998 [6]. This provides information not only on the search engines tools used, but also to spot trends.
Since the surveys began the most widely used tool has been ht://Dig - an open source product. In recent years the licensed product Inktomi has shown a growth in usage. Interestingly, use of home-grown software and specialist products has decreased - search engine software appears now to be a commodity product.
Another interesting trend appears to be in the provision of two search facilities; a locally-hosted search engine and a remote one - e.g. see the University of Lancaster [7].
This document provides advice on how the HTML <link> element can be used to improve the navigation of Web sites.
The purpose of the HTML <link> element is to specify relationships with other documents. Although not widely used the <link> element provides a mechanism for improving the navigation of Web sites.
The <link> element should be included in the <head> of HTML documents. The syntax of the element is: <link rel=”relation” href=”url”>. The key relationships which can improve navigation are listed below.
| Relation | Function |
| next | Refers to the next document in a linear sequence of documents. |
| prev | Refers to the previous document in a linear sequence of documents. |
| home | Refers to the home page or the top of some hierarchy. |
| first | Refers to the first document in a collection of documents. |
| contents | Refers to a document serving as a table of contents. |
| help | Refers to a document offering help. |
| glossary | Refers to 1 document providing a glossary of terms that pertain to the current document. |
Use of the <link> element enables navigation to be provided in a consistent manner as part of the browser navigation area rather than being located in an arbitrary location in the Web page. This has accessibility benefits. In addition browsers can potential enhance the performance by pre-fetching the next page in a sequence.
A reason why <link> is not widely used has been the lack of browser support. This has changed recently and support is now provided in the latest versions of the Opera and Netscape/Mozilla browsers and by specialist browsers (e.g. iCab and Lynx).
Since the <link> element degrades gracefully (it does not cause problems for old browser) use of the <link> element will cause no problems for users of old browsers.
An illustration of how the <link> element is implemented in Opera is shown below.
Figure 1: Browser Support For The <link> Element
In Figure 1 a menu of navigational aids is available. The highlighted options (Home, Contents, Previous and Next) are based on the relationships which have been defined in the document. Users can use these navigational options to access the appropriate pages, even though there may be no corresponding links provided in the HTML document.
It is important that the link relationships are provided in a manageable way. It would not be advisable to create link relationships by manually embedding them in HTML pages if the information is liable to change.
It is advisable to spend time in defining the on key navigational locations, such as the Home page (is it the Web site entry point, or the top of a sub-area of the Web site). Such relationships may be added to templates included in SSIs. Server-side scripts are a useful mechanism for exploiting other relationships, such as Next and Previous - for example in search results pages.
Additional information is provided at
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-10/>.
Many Web developers and administrators are conscious of the need to ensure that their Web sites reach as high a level of accessibility as possible. But how do you actually find out if a site has accessibility problems? Certainly, you cannot assume that if no complaints have been received through the site feedback facility (assuming you have one), there are no problems. Many people affected by accessibility problems will just give up and go somewhere else.
So you must be proactive in rooting out any problems as soon as possible. Fortunately there are a number of handy ways to help you get an idea of the level of accessibility of the site which do not require an in-depth understanding of Web design or accessibility issues. It may be impractical to test every page, but try to make sure you check the Home page plus as many high traffic pages as possible.
If you have a disability, you have no doubt already discovered whether your site has accessibility problems which affect you. If you know someone with a disability which might prevent them accessing information in the site, then ask them to browse the site, and tell you of any problems. Particularly affected groups include visually impaired people (blind, colour blind, short or long sighted), dyslexic people and people with motor disabilities (who may not be able to use a mouse). If you are in Higher Education your local Access Centre [1] may be able to help.
Get hold of a text browser such as Lynx [2] and use it to browse your site. Problems you might uncover include those caused by images with no, or misleading, alternative text, confusing navigation systems, reliance on scripting or poor use of frames.
You can get a free evaluation version of IBM's Homepage Reader [3] or pwWebSpeak [4], speech browsers used by many visually impaired users of the Web. The browsers "speak" the page to you, so shut your eyes and try to comprehend what you are hearing.
Alternatively, try asking a colleague to read you the Web page out loud. Without seeing the page, can you understand what you're hearing?
As suggested by the World Wide Web Consortium (W3C) Web Accessibility Initiative (WAI) [5], you should test your site under various conditions to see if there are any problems including (a) graphics not loaded (b) frames, scripts and style sheets turned off and (c) browsing without using a mouse. Also, try using bookmarklets or favelets to test your Web site under different conditions: further information on accessibility bookmarklets can be found at [6].
There are a number of Web-based tools which can provide valuable information on potential accessibility problems such as Rational Policy Tester Accessibility [7] and The Wave tools [8]. You should also check whether the underlying HTML of your site validates to accepted standards using the World Wide Web Consortium's MarkUp Validation Service [9] as non-standard HTML can also cause accessibility problems
Details of any problems found should be noted: the effect of the problem, which page was affected, plus why you think the problem was caused. You are unlikely to catch all accessibility problems in the site, but the tests described here will give you an indication of whether the site requires immediate attention to raise accessibility. Remember that improving accessibility for specific groups, such as visually impaired people, will often have usability benefits for all users.
Since it is unlikely you will catch all accessibility problems and the learning curve is steep, it may be advisable to commission an expert accessibility audit. In this way, you can receive a comprehensive audit of the subject site, complete with detailed prioritised recommendations for upgrading the level of accessibility of the site. Groups which provide such audits include the Digital Media Access Group, based at the University of Dundee or the RNIB, who also audit Web sites for access to the blind.
Additional information is provided at
<http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-12/>.
This document was written by David Sloan, DMAG, University of Dundee and originally published at by the JISC TechDis service We are grateful for permission to republish this document.
Before creating a Web site for your project you should give some thought to the purpose of the Web site, including the aims of the Web site, the target audiences, the lifetime, resources available to develop and maintain the Web site and the technical architecture to be used. You should also think about what will happen to the Web site once project funding has finished.
Your project Web site could have a number of purposes. For example:
Your Web site could, of course, fulfill more than a single role. Alternatively you may choose to provide more than one Web site.
You should have an idea of the purposes of your project Web site before creating it for a number of reasons:
Once funding has been approved for your project Web site you may wish to provide information about the project, often prior to the official launch of the project and before project staff are in post. There is a potential danger that this information will be indexed by search engines or treated as the official project page. You should therefore ensure that the page is updated once an official project Web site is launched so that a link is provided to the official project page. You may also wish to consider stopping search engines from indexing such pages by use of the Standard For Robot Exclusion [1].
Many projects will have an official project Web site. This is likely to provide information about the project such as details of funding, project timescales and deliverables, contact addresses, etc. The Web site may also provide access to project deliverables, or provide links to project deliverables if they are deployed elsewhere or are available from a repository. Usually you will be proactive in ensuring that the official project Web site is easily found. You may wish to submit the project Web site to search engines.
Projects with several partners may have a Web site which is used to support communications with project partners. The Web site may provide access to mailing lists, realtime communications, decision-making support, etc. The JISCMail service may be used or commercial equivalents such as YahooGroups. Alternatively this function may be provided by a Web site which also provides a repository for project resources.
Projects with several partners may have a Web site which is used to provide a repository for project resources. The Web site may contain project plans, specifications, minutes of meetings, reports to funders, financial information, etc. The Web site may be part of the main project Web site, may be a separate Web site (possibly hosted by one of the project partners) or may be provided by a third party. You will need to think about the mechanisms for allowing access to authorised users, especially if the Web site contains confidential or sensitive information.
Once you have agreed on the purpose(s) of your project Web site(s) [1] you will need to choose a domain name for your Web site and conventions for URIs. It is necessary to do this since this can affect (a) The memorability of the Web site and the ease with which it can be cited; (b) The ease with which resources can be indexed by search engines and (c) The ease with which resources can be managed and repurposed.
You may wish to make use of a separate domain name for your project Web site. If you wish to use a .ac.uk domain name you will need to ask UKERNA. You should first check the UKERNA rules [2]. A separate domain name has advantages (memorability, ease of indexing and repurposing, etc) but t his may not be appropriate, especially for short-term projects. Your organisation may prefer to use an existing Web site domain.
You should develop a policy for URIs for your Web site which may include:
It is strongly recommended that you make use of directories to group related
resources. This is particularly important for the project Web site itself and for
key areas of the Web site. The entry point for the Web site and key areas should
be contained in the directory itself: e.g. use http://www.foo.ac.uk/bar/
to refer to project BAR and not http://www.foo.ac.uk/bar.html) as
this allows the bar/ directory to be processed in its entirety, independently or
other directories. Without this approach automated tools such as indexing software,
and tools for auditing, mirroring, preservation, etc. would process other directories.
You should seek to ensure that URIs are persistent. If you reorganise your Web site you are likely to find that internal links may be broken, that external links and bookmarks to your resources are broken, that citations to resources case to work. Y ou way wish to provide a policy on the persistency of URIs on your Web site.
Ideally the address of a resource (the URI) will be independent of the format of the resource. Using appropriate Web server configuration options it is possible to cite resources in a way which is independent of the format of the resource. This should allow easy of migration to new formats (e.g. HTML to XHTML) and, using a technology known as Transparent Content Negotiation [3] provide access to alternative formats (e.g. HTML or PDF) or even alternative language versions.
Ideally URIs will be independent of the technology used to provide access to
the resource. If server-side scripting technologies are given in the file extension
for URIs (e.g. use of .asp, .jsp, .php, .cfm, etc. extensions) changing
the server-side scripting technology would probably require changing URIs. This
may also make mirroring and repurposing of resources more difficult.
Ideally URIs will be memorable and allow resources to be easily indexed and repurposed. However use of Content Management Systems or databases to store resources often necessitates use of URIs which contain query strings containing input parameters to server-side applications. As described above this can cause problems.
You should consider the following approaches which address some of the concerns:
It is desirable to measure usage of your project Web site as this can give an indication of its effectiveness. Measuring how the Web site is being used can also help in identifying the usability of the Web site. Monitoring errors when users access your Web site can also help in identifying problem areas which need to be fixed.
However, as described in this document, usage statistics can be misleading. Care must be taken in interpreting statistics. As well as usage statistics there are a number of other types of performance indicators which can be measured.
It is also important that consistent approaches are taken in measuring performance indicators in order to ensure that valid comparisons can be made with other Web sites.
Web statistics are produced by the Web server software. The raw data will normally be produced by default - no additional configuration will be needed to produce the server's default set of usage data.
The server log file records information on requests (normally referred to as a "hit") for a resource on the web server. Information included in the server log file includes the name of the resource, the IP address (or domain name) of the user making the request, the name of the browser (more correctly, referred to as the "user agent") issuing the request, the size of the resource, date and time information and whether the request was successful or not (and an error code if it was not). In addition many servers will be configured to store additional information, such as the "referer" (sic) field, the URL of the page the user was viewing before clicking on a link to get to the resource.
A wide range of Web statistical analysis packages are available to analyse Web server log files [1]. A widely used package in the UK HE sector is WebTrends [2].
An alternative approach to using Web statistical analysis packages is to make use of externally-hosted statistical analysis services [3]. This approach may be worth considering for projects which have limited access to server log files and to Web statistical analysis software.
In order to ensure that Web usage figures are consistent it is necessary to ensure that Web servers are configured in a consistent manner, that Web statistical analysis packages process the data consistently and that the project Web site is clearly defined.
You should ensure that (a) the Web server is configured so that appropriate information is recorded and (b) that changes to relevant server options or data processing are documented.
You should be aware that the Web usage data does not necessarily give a true indication of usage due to several factors:
Despite these reservations collecting and analysing usage data can provide valuable information.
Web usage statistics are not the only type of performance indicator which can be used. You may also wish to consider:
With all of the indicators periodic reporting will allow trends to be detected.
It may be useful to determine a policy on collection and analysis of performance indicators for your Web site prior to its launch.
Digital text is one of the oldest description methods, but remains divided by differing file format, encoding methods, schemas, and encoding methods. When choosing a digital text format it is necessary to establish the project needs. Is plain text suitable for the task and are text markup and formatting required? How will the information be displayed and where? This document describes these issues and provides some guidelines for their use.
Digital text has existed in one form or another since the 1960s. Many computer users take for granted that they can quickly write a letter without restriction or technical considerations. A commercial project, however, requires consideration of long-term needs and goals. To avoid complications at a later date, the developer must ensure the tools in use are the most appropriate for the task and, if not, what can be used in their place. To achieve this three questions should be answered:
It is often assumed that everyone can read text. However, this is not always the case. Digital text imposes restrictions upon the content that can have a significant impact upon the project.
In particular, there are two main issues:
The choice of format will be dependent upon the following factors:
For allowing universal information access, plain text remains useful. It has the advantage of being simple to interpret and small in file size. However, there are some differences in the method that is used to encode text characters. The most common variations are ASCII (American Standard Code for Information Interchange) and Unicode.
Several problems may be encountered when storing textual information. For text files it is a simple process to convert the file to Unicode. However, for more complex data, such as databases, the conversion process will become more difficult. Problems may include:
Although ASCII and Unicode are useful for storing information, they are only able describe each character, not the method they should be displayed or organized. Structural mark-up languages enable the designer to dictate how information will appear and establish a structure to its layout. For example, the user can define a tag to store book author information and publication date.
The use of structural mark-up can provide many organizational benefits:
The most common markup languages are SGML and XML. Based upon these languages, several schemas have been developed to organize and define data relationships. This allows certain elements to have specific attributes that define its method of use (see Digital Rights document for more information). To ensure interoperability, XML is advised due to its support for contemporary Internet standards (such as Unicode).
Digital video can have a dramatic impact upon the user. It can reflect information that is difficult to describe in words alone, and can be used within an interactive learning process. This document contains guidelines to best practice when manipulating video. When considering the recording of digital video, the digitiser should be aware of the influence of file format, bit-depth, bit-rate and frame size upon the quality of the resulting video.
Digital video consists of a series of images played in rapid succession to create the illusion of movement. It is commonly accompanied by an audio track. Unlike graphics and sound that are relatively small in size, video data can be hundreds of megabytes, or even gigabytes, in size.
The visual and audio information are individually stored within a digital 'wrapper' an umbrella structure consisting of the video and audio data, as well as information to playback and resynchronise the data.
Digital video remains a complex area that combines the problems of audio and graphic data. When choosing to encode video the designer must consider several issues:
The distribution method will have a significant influence upon the file format, encoding type and compression used in the project.
Removeable media - Video distributed on CD-ROM or DVD are suited to progressive encoding methods that do not conduct extensive error checking. Although file size is not as critical in comparison to Internet streaming, it continues to have some influence.
The compression type is dependent upon the need of the user and the type of removeable media:
| NAME | PURPOSE OF MEDIA | Compression | ||
| Streaming | Progressive | Media | ||
| Advanced Streaming Format (ASF) | Y | Temporal | ||
| Audio Video Interleave (AVI) | Y | Temporal | ||
| MPEG-1 | Y | VideoCD | Temporal | |
| MPEG-2 | Y | DVD | Temporal | |
| QuickTime (QT) | Y | Y | Temporal | |
| QuickTime Pro | Y | Y | Temporal | |
| RealMedia (RM) | Y | Y | Temporal | |
| Windows Media Video (WMV) | Y | Y | Temporal | |
| DivX | Y | Amateur CD distribution | Temporal | |
| MJPEG | Y | Spatial | ||
Table 1: A comparison list of the different file formats, highlighting their intended purpose and compression method.
The provision of video data for an Internet-based audience places specific restrictions upon the content. Quality of the video output is dependent upon three factors:
| Screen Size | Pixels per frame | Bit depth (bits) | Frames per second | Bandwidth required (megabits) |
| 640 x 480 | 307,200 | 24 | 30 | 221.184 |
| 320 x 240 | 76,800 | 16 | 25 | 30.72 |
| 320 x 240 | 76,800 | 8 | 15 | 9.216 |
| 160 x 120 | 19,200 | 8 | 10 | 1.536 |
| 160 x 120 | 19,200 | 8 | 5 | 0.768 |
Table 2: Indication of the influence of screen size, bit-depth and frames per second has upon required bandwidth
When creating video, the designer must balance the video quality with the facilities available to the end user. As an example, an 8-bit screen of 160 x 120 pixels, and 10-15 frames per second is used for the majority of content found on the Internet.
Video presents numerous problems for the designer caused by the complexity of formats and structure. Problems may include:
Temporal Compression - Reduces the amount of data stored over a sequence of frames. Rather than describing every pixel in each frame, temporal compression stores a key frame, followed by descriptive information on changes.
Spatial Compression - Condenses each frame independently by mapping similar pixels within a frame. For example, two shades of red will be merged. This results in a reduction in image quality, but enables the file to be edited in its original form.
Progressive Encoding - Refers to any format where the user is required to download the entire video before they are allowed to watch it.
Internet Streaming - Enables the viewer to watch sections of video without downloading the entire thing, allowing users to evaluate video content after just a few seconds. Quality is significantly lower than progressive formats due to compression being used.
A project's Web site address will provide, for many, the best means for finding out about the project, reading abouts its activities and using the facilities which the projects provides. It is therefore highly desirable that a project's Web site address remains stable. However there may be occasions when it is felt necessary to change a project's Web site address. This document provides advice on best practices which should help to minimise problems.
Ideally the entry point for project's Web site will be short and memorable. However this ideal is not always achievable. In practice we are likely to find that institutional or UKERNA guidelines on Web addresses preclude this option.
The entry point should be a simple domain name such as <http://www.project.ac.uk/> or a directory such as <http://www.university.ac.uk/depts/library/project/>. Avoid use of a file name such as <http://www.university.ac.uk/depts/library/project/index.html> as this makes the entry point longer and less memorable and can cause problems if the underlying technologies change.
If the address of a project Web site is determined by institutional policies, it is still desirable to avoid changing the address unnecessarily. However there may be reasons why a change to the address is needed.
Projects should consider potential changes to the Web site address before the initial launch and seek to avoid future changes or to minimise their effect. However if this is not possible the following advice is provided:
This information will give you an indication of the impact a change to your Web site address may have. If you intend to change the address you should:
It is advisable to check links prior to the change and afterwards, to ensure that no links are broken during the change. You should seek to ensure that links on your Web site go to the new address.
Below are some key pointers that can help you enhance the quality assurance procedures used for your Web site.
Are the tools that you use to create your Web site appropriate for their tasks? Do they produce compliant and accessible code? Can the tools be configured to incorporate QA processes such as HTML validation, link checking, spell checking, etc? If not, perhaps you should consider evaluating other authoring tools or alternative approaches to creating and maintaining your content.
How do you deal with problem reporting? Consider implementing a fault reporting log. Make sure that all defects are reported, that ownership is assigned, details are passed on to the appropriate person, a schedule for fixes is decided upon, progress made is recorded and the resolution of problem is noted. There could also be a formal signing off procedure.
A model such as the QA Focus Timescale Model will help you to plan the QA you will need to implement over the course of your project:
There are a variety of tools out there for use and a number are open source or free to use. These can be used for HTML and CSS validation, link checking, measuring load times, etc.
Manual approaches to Web site testing can address areas which will not be detecting through use of automated tools. You should aim to test key areas of your Web site and ensure that systematic errors which are found are addressed in areas of the Web site which are not tested.
A benchmarking approach involves comparisons of the findings for your Web site with your peers. This enables comparisons to be made which can help you identify areas in which you may be successful and also areas in which you may be lagging behind your peers.
You could give a severity rating to problems found to decide whether the work be done now or it can wait till the next phase of changes. An example rating system might be:
Make sure that you do not just fix problems you find. Recognising why the problems have occurred allows you to improve your publishing processes so that the errors do not reoccur.
The following resources provide additional advice on quality assurance for Web sites.
You should ensure that your Web site complies with HTML standards. This will involve selecting the standard for your Web site (which currently should be either HTML 4.0 or XHTML 1.0); implementing publishing procedures which will ensure that your Web pages comply with the standard and quality assurance procedures to ensure that your publishing processes work correctly [1] [2].
You should make use of CSS (Cascading Style Sheets) to define the appearance of your HTML pages. You should seek to avoid use of HTML formatting elements (e.g. avoid spacer GIFs, <font> tags, etc.) - although it is recognised that use of tables for formatting may be necessary in order to address the poor support for CSS-positioning in some Web browsers. You should also ensure that your CSS is compliant with appropriate standards [3].
You should provide a search facility for your Web site if it contains more than a few pages [4].
You should aim to ensure that the 404 error page for your Web site is not the default page but has been configured with appropriate branding, advice and links to appropriate resources, such as the search facility [5].
You should ensure that you have a URI naming policy for your Web site [6].
You should ensure that you check for broken links on your Web site. You should ensure that links work correctly when pages are created or updated. You should also ensure that you have a link checking policy which defines the frequency for checking links and your policy when broken links are detected [7].
You should address the accessibility of your Web site from the initial planning stages. You should ensure that you carry out appropriate accessibility testing and that you have an accessibility policy [8].
You should address the usability of your Web site from the initial planning stages. You should ensure that you carry out appropriate usability testing and that you have a usability policy.
You should make use of several browsers for testing the accessibility, usability and functionality of your Web site. You should consider making use of mainstream browsers (Internet Explorer and FireFox) together with more specialist browsers such as Opera.
You should ensure that you have appropriate quality assurance procedures for your Web site [9] [10].
This document provides advice on configuring popular Web browsers in order to ensure your Web site is widely accessible. The document covers Internet Explorer 7.0, Firefox 3 and Opera 9.6 running on Microsoft Windows.
Some browsers do not support JavaScript. Some organisations / individuals will disable JavaScript due to security concerns.
| Browser | Technique |
|---|---|
| Internet Explorer | Select Tools menu and Internet Options option. Select the Security tab, choose the Internet icon choose the Custom level option. Scroll to the Scripting option and choose the Disable (or Prompt) option. |
| Firefox | Select Tools menu and Options option. Open Content, unselect the Enable Javascript option and select OK. |
| Opera | Select File menu and choose Preferences option. Choose the Multimedia option, disable JavaScript option and select OK. |
Some individuals will need to resize the display in order to read the information provided.
| Browser | Technique |
|---|---|
| Internet Explorer | Select View menu and choose Text Size option. |
| Firefox | Select View menu and choose the Zoom option. Choose the option to Zoom in. Repeat using Zoom out |
| Opera | Select View menu and choose Zoom option. Then zoom by a factor or, say, 50% and 150%. |
Some people cannot see images and some may disable images for performance or privacy reasons.
| Browser | Technique |
|---|---|
| Internet Explorer | Select Tools menu and Internet Options option. Uncheck the Show pictures automatically option. |
| Firefox | Select View menu and Options option. Open the Content tab, uncheck the Load images automatically tab and select OK. |
| Opera | Select File menu and choose Preferences option. Choose Multimedia option, select the Show images pull-down menu and choose the Show no images option and select OK. |
Some browsers and assistive technologies may not support pop-up windows. Individuals may disable pop-up windows due to their misuse by some commercial sites.
| Browser | Technique |
|---|---|
| Internet Explorer | Select the Tools tab and Pop-Up Blocker option. Ensure that the Pop-Up Blocker option is selected. |
| Firefox | Select Tools menu and Options option. Select the Content tab and click on the Block pop-up windows option. |
| Opera | Select File menu and choose Preferences option. Choose Windows option in the Pop-ups pull-down menu and choose the Refuse Pop-ups option and select OK. |
You should use the procedures in a systematic way: for example as part of a formal testing procedure in which specific tasks are carried out.
Bookmarklets are browser extension may extend the functionality of a browser. Many accessibility bookmarklets are available (known as Firefox Extensions for the Firefox browser). It is suggested that such tools are used in accessibility testing. See Interfaces To Web Testing Tools at <http://www.ariadne.ac.uk/issue34/web-focus/>
As described in other QA Focus briefing document [1] [2] it is important to ensure that Web sites comply with standards and best practices in order to ensure that Web sites function correctly, to provide widespread access to resources and to provide interoperability. It is therefore important to check Web resources for compliance with standards such as HTML, CSS, accessibility guidelines, etc.
This document summarises different models for such testing tools and describes a model which is based on provided an interface to testing tools through a Web browsers address bar.
There are a variety of models for testing tools:
Although a variety of models are available, they all suffer from the lack of integration will the normal Web viewing and publishing process. There is a need to launch a new application or go to a new Web resource in order to perform the checking.
A URI interface to testing tools avoids the barrier on having to launch an application or move to a new Web page. With this approach if you wish to validate a page on your Web site you could simply append an argument (such as ,validate) in the URL bar when you are viewing the page. The page being viewed will then be submitted to a HTML validation service. This approach can be extended to recursive checking: appending ,rvalidate to a URI will validate pages beneath the current page.
This approach is illustrated. Note that this technique can be applied to a wide range of Web-based checking services including:
This approach has been implemented on the QA Focus Web site (and on UKOLN's Web site). For a complete list of tools available append ,tools to any URL on the UKOLN Web site or see [3].
This approach is implemented using a simple Web server redirect. This has the advantage of being implemented in a single place and being available for use by all visitors to the Web site.
For example to implement the ,validate URI tool the following line should be added to the Apache configuration file:
RewriteRule /(.*),validate http://validator.w3.org/check?uri=http://www.foo.ac.uk/$1 [R=301]where www.foo.ac.uk should be replaced by the domain name of your Web server (note that the configuration details should be given in a single line).
This approach can also be implemented on a Microsoft IIS platform, as described at [3].
The QA Focus Toolkits are an online resource which can be used as a checklist to ensure that your project or service has addressed key areas which can help to ensure that your deliverables are fit for its intended purpose, widely accessible and interoperable and can be easily repurposed.
The QA For Web Toolkit is one of several toolkits which have been developed by the QA Focus project to support JISC's digital library programmes. This toolkit addresses compliance with standards and best practices for Web resources.
The QA For Web Toolkit is available from <http://www.ukoln.ac.uk/qa-focus/toolkit/>. The toolkit is illustrated in Figure 1:
Figure 1: The QA For Web Toolkit
The toolkit addresses the following key areas
The toolkit can provide access to a set of online checking services.
You should seek to ensure that systematic checking is embedded within your work. If you simply make occasional use of such tools you may fail to spot significant errors. Ideally you will develop a systematic set of workflow procedures which will ensure that appropriate checks are carried out consistently.
You should also seek to ensure that you implement systematic checks in areas in which automated tools are not appropriate or available.
You may wish to use the results you have found for audit trails of compliance of resources on your Web site.
The QA For Web Toolkit described in this document provides a single interface to several online checking services hosted elsewhere. The QA Focus project and its host organisations (UKOLN and AHDS) have no control over the remote online checking services. We cannot guarantee that the remote services will continue to be available.
Further toolkits are available at <http://www.ukoln.ac.uk/qa-focus/toolkit/>
.RSS is increasingly being used to provide news services and for syndication of content. The document provides a brief description of RSS news feed technologies which can be used as part of a communications strategy by projects and within institutions. The document summarises the main challenges to be faced when considering deployment of news feeds.
News feeds are an example of automated syndication. News feed technologies allow information to be automatically provided and updated on Web sites, emailed to users, etc. As the name implies news feeds are normally used to provide news; however the technology can be used to syndicate a wide range of information.
The BBC ticker [1] is an example of a news feed application. A major limitation with this approach is that the ticker can only be used with information provided by the BBC.
The RSS standard was developed as an open standard for news syndication, allowing applications to display news supplied by any RSS provider.
RSS is a lightweight XML application (see RSS fragment). Ironically the RSS standard proved so popular that it led to two different approaches to its standardisation. So RSS now stands for RDF Site Summary and Really Simple Syndication (in addition to the original phrase Rich Site Summary).
<title>BBC News</title> <url>http://news.bbc.co.uk/nol/shared/img/bbc_news_120x60.gif</url> <link>http://news.bbc.co.uk/</link> <item> <title>Legal challenge to ban on hunting</title> <description>The Countryside Alliance prepares a legal challenge to Parliament Act ... </description> <link>http://news.bbc.co.uk/go/click/rss/0.91/public/-/1/hi/... </link>.
Figure 1: Example Of An RSS File
Despite this confusion, in practice many RSS viewers will display both versions of RSS (and the emerging new standard, Atom).
There are a large number of RSS reader software applications available [2] and several different models. An example of a scrolling RSS ticker is also shown above [3]. RSSxpress [4] (illustrated below) is an example of a Web-based reader which embeds an RSS feed in a Web page.
In addition to these two approaches, RSS readers are available with an email-style approach for the Opera Web browser [5] and Outlook [6] and as extensions for Web browsers [7] [8].
There are several approaches to the creation of RSS news feeds. Software such as RSSxpress can also be used to create and edit RSS files. In addition there are a number of dedicated RSS authoring tools, including standalone applications and browser extensions (see [9]). However a better approach may be to generate RSS and HTML files using a CMS or to transform between RSS and HTML using languages such as XSLT.
Issues which need to be addressed when considering use of RSS include:
Wiki technologies are increasingly being used to support development work across distributed teams. This document aims to give a brief description of Wikis and to summarise the main challenges to be faced when considering the deployment of Wiki technologies.
A Wiki or wiki (pronounced "wicky" or "weekee") is a Web site (or other hypertext document collection) that allows a user to add content. The term Wiki can also refer to the collaborative software used to create such a Web site [1].
The key characteristics of typical Wikis are:
The Wikipedia is the largest and best-known Wiki - see <http://www.wikipedia.org/>.
The Wikipedia provides a good example of a community Wiki in which content is provided by contributors around the world.
The Wikipedia appears to have succeeded in providing an environment and culture which has minimised the dangers of misuse. Details of the approaches taken on the Wikipedia are given on the Wikipedia Web site [2].
Wikis can be used for a number of purposes:
As described in [6] advantages of Wikis may include:
Disadvantages of Wikis include:
An identifier is any label that allows us to find a resource. One of the best-known identifiers is the International Standard Book Number (ISBN), a unique ten-digit number assigned to books and other publications. On the Internet the most widely known identifier is the Uniform Resource Locator (URL), which allows users to find a resource by listing a protocol, domain name and, in many cases, file location.
A persistent identifier is, as the name suggests, an identifier that exists for a very long time. It should at the very least be globally unique and be used as a reference to the resource beyond the resource's lifetime. URLs, although useful, are not very persistent. They only provide a link to the resource's location at the moment in time they are cited, if the resource moves they no longer apply. The issue of 'linkrot' on the Internet (broken links to resources), along with the need for further interoperability has led to the search for more persistent identifiers for digital resources.
The International Digital Object Identifier (DOI) Foundation [1] states that there are two principles for persistent identification:
A Uniform Resource Identifier (URI) is the string that is used to identify anything on the Internet. URLs along with Uniform Resource Names (URNs) are both types of URI. A URN is a name with global scope and does not necessarily imply a location. A URN will include a Namespace Identifier (NID) Code and a Namespace Specific String (NSS). The NID specifies the identification system used (e.g. ISBN) and the NSS is local code that identifies a resource. For someone to find a resource using a URN they must use a resolver service.
Persistent URLs (PURLs) [2] have been developed by the Online Computer Library Centre (OCLC) as an interim measure for Internet resources until the URN framework is well established. A PURL is functionally a URL, but rather than pointing at a location points at a resolution service, which redirects the user to the appropriate URL. If the URL changes it just needs to be amended in the PURL resolution service
Example: http://purl.oclc.org/OCLC/PURL/summary
This is made up of the protocol (http), the resolver address
(http://purl.oclc.org/) and the user-assigned name (OCLC/PURL/summary).
The Digital Object Identifier (DOI) system was initiated by the Association of American publishers in an attempt to assist the publishing community with copyright and electronic commerce. DOIs are described by the International DOI Foundation, who manage them, as persistent, interoperable, actionable identifiers. They are persistent because they identify an object as a first-class entity (not just the location), they are interoperable because they are designed with the future in mind and they are actionable because they allow a user to locate a resource by resolution using the Handle System. The Handle System, developed by the Corporation for National Research Initiatives (CNRI) includes protocols that enable a distributed computer system to store handles of digital resources and resolve them into a location. DOIs can be assigned by a Registration Agency (RA), which provides services for a specific user community and may charge fees. The main RA for the publishing community is CrossRef [3].
Example: 10.1000/123456
This is made up of the prefix (10.1000) which is the string assigned
to an organisation that registering DOIs and the suffix (123456) which
is a unique (to a given prefix) alphanumeric string, which could be an existing identifier.
While DOIs hold great potential for helping many information communities enhance interoperability they have yet to reach full maturity. There are still many unresolved issues, such as their resolution (how users use them in to receive a Web page), registration of the DOI system, the persistence of the International DOI Foundation as an organisation and what exactly their advantages are over handles or PURLs. Until these matters are resolved they will remain little more than a good idea for most communities.
However the concept of persistent identifiers is still imperative to a working Internet. While effort is put into finding the best approach there is much that those creating Web pages can do to ensure that their URIs are persistent. In 1998 Tim Berners-Lee coined the phrase Cool URIs to describe URIs which do not change. His article explains the methods a Webmaster would use to design a URI that will stand the test of time. As Berners-Lee elucidates "URIs don't change: people change them." [4].
Information on performance indicators for Web sites has been published elsewhere [1] [2]. This document provides additional information on the specific need for usage statistics for Web sites and provides guidance on ways of ensuring the usage statistics can be comparable across Web sites.
When a user accesses a Web page several resources will normally be downloaded to the user (the HTML file, any embedded images, external style sheet and JavaScript files, etc.). The Web server will keep a record of this, including the names of the files requested and the date and time, together with some information about the user's environment (e.g. type of browser being used).
Web usage analysis software can then be used to provide overall statistics on usage of the Web site. As well as giving an indication of the overall usage of a Web site, information can be provided on the most popular pages, the most popular entry points, etc.
Usage statistics can be used to give an indication of the popularity of Web resources. Usage statistics can be useful if identifying successes or failures in dissemination strategies or in the usability of a Web site.
Usage statistics can also be useful to system administrators who may be able to use the information (and associated trends) in capacity planning for server hardware and network bandwidth.
Aggregation of usage statistics across a community can also be useful in profiling the impact of Web services within the community.
Although Web site usage statistics can be useful in a number of areas, it is important to be aware of the limitations of usage statistics. Although initially it may seem that such statistics should be objective and unambiguous, in reality this is not the case.
Some of the limitations of usage statistics include:
Although Web site usage statistics cannot be guaranteed to provide a clear and unambiguous summary of Web site usage, this does not mean that the data should not be collected and used. There are parallels with TV viewing figures which are affected by factors such as video recording. Despite such known limitations, this data is collected and used in determining advertising rates.
The following advice may be useful:
You should ensure that you document the approaches taken (e.g. details of the analysis tool used) and any processing carried out on the data (e.g. removing robot traffic or access from within the organisation). Ideally you will make any changes to the processing, but if you do you should document this.
Traditional analysis packages process server log files. An alternative approach is to make use of an externally-hosted usage analysis service. These services function by providing a small graphical image (which may be invisible) which is embedded on pages on your Web site. Accessing a page causes the graphic and associated JavaScript code, which is hosted by a commercial company, to be retrieved. Since the graphic is configured to be non-cachable, the usage data should be more reliable. In addition the JavaScript code can allow additional data to be provided, such as additional information about the end users PC environment.
Web services are a class of Web application, published, located and accessed via the Web, that communicates via an XML (eXtensible Markup Language) interface [1]. As they are accessed using Internet protocols, they are available for use in a distributed environment, by applications on other computers.
The idea of Internet-accessible programmatic interfaces, services intended to be used by other software rather than as an end product, is not new. Web services are a development of this idea. The name refers to a set of standards and essential specifications that simplify the creation and use of such service interfaces, thus addressing interoperability issues and promoting ease of use.
Well-specified services are simple to integrate into larger applications, and once published, can be used and reused very effectively and quickly in many different scenarios. They may even be aggregated, grouped together to produce sophisticated functionality.
The Google spellchecker service, used by the Google search engine, suggests a replacement for misspelt words. This is a useful standard task; simply hand it a word, and it will respond with a suggested spelling correction if one is available. One might easily imagine using the service in one's own search engine, or in any other scenario in which user input is taken, perhaps in an intelligent "Page not found" error page, that attempts to guess at the correct link. The spellchecker's availability as a Web service simplifies testing and adoption of these ideas.
Furthermore, the use of Web services is not limited to Web-based applications. They may also usefully be integrated into a broad spectrum of other applications, such as desktop software or applets. Effectively transparent to the user, Web service integration permits additional functionality or information to be accessed over the Web. As the user base continues to grow, many development suites focus specifically on enabling the reuse and aggregation of Web services.
'Web services' refers to a potentially huge collection of available standards, so only a brief overview is possible here. The exchange of XML data uses a protocol such as SOAP or XML-RPC. Once published, the functionality of the Web service may be documented using one of a number of emerging standards, such as WSDL, the Web Service Description Language.
WSDL provides a format for description of a Web service interface, including parameters, data types and options, in sufficient detail for a programmer to write a client application for that service. That description may be added to a searchable registry of Web services.
A proposed standard for this purpose is UDDI (Universal Description, Discovery and Integration), described as a large central registry for businesses and services. Web services are often seen as having the potential to 'flatten the playing field', and simplify business-to-business operations between geographically diverse entities.
Due to the popularity of the architecture, many resources exist to support the development and use of Web services in a variety of languages and environments. The plethora of available standards may pose a problem, in that a variety of protocols and competing standards are available and in simultaneous use. Making that choice depends very much on platform, requirements and technical details.
Although Web services promise many advantages, there are still ongoing discussions regarding the best approaches to the underlying technologies and their scope.
The term 'Web 2.0' was coined to define an emerging pattern of new uses of the Web and approaches to the Web development, rather than a formal upgrade of Web technologies as the 2.0 version number may appear to signify. The key Web 2.0 concepts include:
The key application areas which embody the Web 2.0 concepts include:
Asynchronous JavaScript and XML (AJAX) is an umbrella term for a collection of Web development technologies used to create interactive Web applications, mostly W3C standards (the XMLHttpRequest specification is developed by WHATWG [1]:
Since data can be sent and retrieved without requiring the user to reload an entire Web page, small amounts of data can be transferred as and when required. Moreover, page elements can be dynamically refreshed at any level of granularity to reflect this. An AJAX application performs in a similar way to local applications residing on a user's machine, resulting in a user experience that may differ from traditional Web browsing.
Recent examples of AJAX usage include Gmail [2], Flickr [3] and 24SevenOffice [4]. It is largely due to these and other prominent sites that AJAX has become popular only relatively recently - the technology has been available for some time. One precursor was dynamic HTML (DHTML), which twinned HTML with CSS and JavaScript but suffered from cross-browser compatibility issues. The major technical barrier was a common method for asynchronous data exchange; many variations are possible, such as the use of an "iframe" for data storage or JavaScript Object Notation for data transmission, but the wide availability of the XMLHttpRequest object has made it a popular solution. AJAX is not a technology, rather, the term refers to a proposed set of methods using a number of existing technologies. As yet, there is no firm AJAX standard, although the recent establishment of the Open AJAX group [5], supported by major industry figures such as IBM and Google, suggests that one will become available soon.
AJAX applications can benefit both the user and the developer. Web applications can respond much more quickly to many types of user interaction and avoid repeatedly sending unchanged information across the network. Also, because AJAX technologies are open, they are supported in all JavaScript-enabled browsers, regardless of operating system - however, implementation differences of the XMLHttpRequest between browsers cause some issues, some using an ActiveX object, others providing a native implementation. The upcoming W3C 'Document Object Model (DOM) Level 3 Load and Save Specification' [6] provides a standardised solution, but the current solution has become a de facto standard and is therefore likely to be supported in future browsers.
Although the techniques within AJAX are relatively mature, the overall approach is still fairly new and there has been criticism of the usability of its applications; further information on this subject is available in the Ajax and Usability QA Focus briefing document [7]. One of the major causes for concern is that JavaScript needs to be enabled in the browser for AJAX applications to work. This setting is out of the developer's control and statistics show that currently 10% of browsers have JavaScript turned off [8]. This is often for accessibility reasons or to avoid scripted viruses.
The popularity of AJAX is due to the many advantages of the technology, but several pitfalls remain related to the informality of the standard, its disadvantages and limitations, potential usability issues and the idiosyncrasies of various browsers and platforms. However, the level of interest from industry groups and communities means that it is undergoing active and rapid development in all these areas.
OPML stands for Outline Processor Markup Language. OPML was originally developed as an outlining application by Radio Userland. However it has been adopted for a range of other applications, in particular providing an exchange format for RSS.
This document describes the OPML specification and provides examples of use of OPML for the exchange of RSS feeds.
The OPML specification [1] defines an outline as a hierarchical, ordered list of arbitrary elements. The specification is fairly open which makes it suitable for many types of list data. The OPML specification is very simple, containing the following elements:
OPML has various shortcomings:
OPML can be used in a number of application areas. One area of particular interest is in the exchange of RSS files. OPML can be used to group together related RSS feeds. RSS viewers which provide support for OPML can then be used to read in the group, to avoid having to import RSS files individually. Similarly RSS viewers may also provide the ability to export groups of RSS files as a single OPML file.
OPML viewers can be used to view and explore OPML files. OPML viewers have similar functionality as RSS viewers, but allow groups of RSS files to be viewed.
The QA Focus Web site makes use of RSS and OPML to provide syndication of the key QA Focus resources [2]. This is illustrated in Figure 1, which shows use of the Grazr inline OPML viewer [3]. This application uses JavaScript to read and display the OPML data.
Other OPML viewers include Optimal OPML [4] and OPML Surfer [5].
Figure 1: Grazr
It should be noted that OPML is a relatively new format and only limited experiences have been gained in its usage. Organisations who wish to make exploit the benefits of OPML should seek to minimise any risks associated with use of the format and develop migration strategies if richer or more robust alternative formats become available.
This briefing document makes use of information published in the OPML section on Wikipedia [6].
This briefing document provides advice for Web authors, developers and policy makers who are considering making use of Web 2.0 services which are hosted by external third party services. The document describes an approach to risk assessment and risk management which can allow the benefits of such services to be exploited, whilst minimising the risks and dangers of using such services.
Note that other examples of advice are also available [1] [2].
This document covers use of third party Web services which can be used to provide additional functionality or services without requiring software to be installed locally. Such services include:
Advantages of using such services include:
Possible disadvantages of using such services include:
A number of risks associated with making use of Web 2.0 services are given below, together with an approach to managing the dangers of such risks.
| Risk | Assessment | Management |
|---|---|---|
| Loss of service (e.g. company becomes bankrupt, closed down, ...) | Implications if service becomes unavailable. Likelihood of service unavailability. |
Use for non-mission critical services. Have alternatives readily available. Use trusted services. |
| Data loss | Likelihood of data loss. Lack of export capabilities. |
Evaluation of service. Non-critical use. Testing of export. |
| Performance problems. Unreliability of service. |
Slow performance | Testing. Non-critical use. |
| Lack of interoperability. | Likelihood of application lock-in. Loss of integration and reuse of data. |
Evaluation of integration and export capabilities. |
| Format changes | New formats may not be stable. | Plan for migration or use on a small-scale. |
| User issues | User views on services. | Gain feedback. |
Note that in addition to risk assessment of Web 2.0 services, there is also a need to assess the risks of failing to provide such services.
A risk management approach [3] was taken to use of various Web 2.0 services on the Institutional Web Management Workshop 2006 Web site.
This briefing document provides advice on approaches to measuring the impact of a service provided by a Web site.
The document describes an approach to risk assessment and risk management which can allow the benefits of such services to be exploited, whilst minimising the risks and dangers of using such services.
A traditional approach to measuring the impact of a Web site is to report on Web server usage log files [1]. Such data can provide information such as an indication of trends and growth in usage; how visitors arrived at the Web site; how users viewed pages on your Web site and details on the browser technologies used by your visitors.
However although such information can be useful, it is important to recognise that the underlying data and the data analysis techniques used may be flawed [2]. For example:
It should also be noted that care must be taken when aggregating usage statistics:
So although analysis of Web site usage data may be useful, the findings need to be carefully interpreted.
Although Web site usage analysis may have flaws, there are other approaches which can be used to measure the impact of a Web site: Such alternative can be used to complement Web usage analysis.
Possible disadvantages of using such services include:
In order to maximise the benefits, you may find it useful to develop an Impact Analysis Strategy. This should ensure that you are aware of the strengths and weaknesses of the approaches you plan to use, have mechanisms for gathering information in a consistent and effective manner and that appropriate tools and services are available.
This document provides an introduction to microformats, with a description of what microformats are, the benefits they can provide and examples of their usage. In addition the document discusses some of the limitations of microformats and provides advice on best practices for use of microformats.
"Designed for humans first and machines second, microformats are a set of simple, open data formats built upon existing and widely adopted standards. Instead of throwing away what works today, microformats intend to solve simpler problems first by adapting to current behaviors and usage patterns (e.g. XHTML, blogging)." [1].
Microformats make use of existing HTML/XHTML markup: Typically the <span> and <div> elements and class attribute are used with agreed class name (such as vevent, dtstart and dtend to define an event and its start and end dates). Applications (including desktop applications, browser tools, harvesters, etc.) can then process this data.
Popular examples of microformats include:
An example which illustrates the commercial takeup of the hCalendar microformat is its use with the World Cup 2006 fixture list [4]. This application allows users to choose their preferred football team. The fixtures are marked up using hCalendar and can be easily added to the user's calendaring application.
Microformats have been designed to make use of existing standards such as HTML. They have also been designed to be simple to use and exploit. However such simplicity means that microformats have limitations:
Despite their limitations microformats can provide benefits to the user community. However in order to maximise the benefits and minimise the risks associated with using microformats it is advisable to make use of appropriate best practices. These include:
This document describes a user-focussed approach to Web accessibility in which the conventional approach to Web accessibility (based on use of WAI WCAG guidelines) can be applied within a wider context.
The conventional approach to Web accessibility is normally assumed to be provided by implementation of the Web Content Accessibility Guidelines (WCAG) which have been developed by the Web Accessibility Initiative (WAI).
In fact the WCAG guidelines are part of a set of three guidelines developed by WAI, the other guidelines being the Authoring Tools Accessibility Guidelines (ATAG) and the User Agent Accessibility Guidelines (UAAG). The WAI approach is reliant on full implementation of these three sets of guidelines.
Although WAI has been a political success, with an appreciation of the importance of Web accessibility now widely acknowledged, and has provided a useful set of guidelines which can help Web developers produce more accessible Web sites, the WAI model and the individual guidelines have their flaws, as described by Kelly et al [1]:
Although the WAI approach has its flaws (which is understandable as this was an initial attempt to address a very difficult area) it needs to be recognised that WCAG guidelines are valuable. The challenge is to develop an approach which makes use of useful WCAG guidelines in a way which can be integrated with others areas of best practices (e.g. including usability, interoperability, etc.) and provides a richer and more usable and accessible experience to the target user community.
In the tangram model for Web accessibility (developed by Sloan, Kelly et al [3]) each piece in the tangram (see below left) represents guidelines in areas such as accessibility, usability, interoperability, etc. The challenge for the Web developer is to develop a solution which is 'pleasing' to the target user community (see below right).
The tangram model provides several benefits:
Web 2.0 is described by Wikipedia as referring to "a second generation of services available on the web that lets people collaborate and share information online" [1].
Web 2.0 is essentially all about creating richer user experiences through providing interactive tools and services, which sit on top of static web sites. Web sites which utilise aspects of Web 2.0 are often personalisable, dynamically driven, and rich in community tools and sharing functions. The data from underlying systems, such as a Library Management System, can be exposed and shared, usually using XML. Web 2.0 developments are underpinned by open source software and open standards - and they often use widely available components such as RSS, blogging tools and social bookmarking services.
Recently, the term Library 2.0 has also come to prominence. Library 2.0 [2] follows the principles of Web 2.0, in that it promotes the evaluation and adoption of software and tools which were originally created outside of the Library environment. These are over-layed on traditional library services - such as the Library OPAC - in order to create a more dynamic, interactive and personalisable user experience.
Web 2.0 technologies can be used to vastly improve the user experience when searching the Library OPAC. Traditionally, many Library OPACs have been designed with librarians rather than users in mind, resulting in interfaces which are not intuitive or attractive to users.
An excellent example of Web 2.0 in action comes from Plymouth State University [3]. The Library OPAC has been redesigned to give it the look and feel of a blog. The home page consists of a new books feed, presented in an engaging and attractive fashion, in contrast to the more usual approach of providing a set of search options. Users can view items, or click on options to 'find more like this' 'comment' or 'get more details'. The site is powered by WPopac, which the developer describes as 'an OPAC 2.0 Testbed' [4]. WPopac is itself based around the WordPress blogging tool [5].
The site contains lots of other useful features such as a list of the most popular books, recent search terms used by other users, ability to tag items with user-chosen tags, user comments and book reviews. Many of these features are provided by the use of RSS feeds from the Library Management System itself. The tagging tools are provided by an external social tagging Web site called Technorati [6].
Book reviews and detailed descriptions are also provided from the Amazon Web site, and other Amazon services [7] such as 'search inside' and 'tables of contents' are also integrated into the site.
Another interesting approach to the OPAC comes from Ann Arbor District Library (a US public library), who have created an online 'wall of books' using book jacket images [8]. Each image in the 'wall' links back to an item record in the Library OPAC. This is a novel approach to presenting and promoting library services, using an attractive 'virtual' library display to entice people into the OPAC for further information.
Google have provided a number of solutions for Libraries wishing to encourage their users to access local electronic and print resources when searching in Google Scholar [9]. Libraries can link their collections to Google Scholar to ensure that users are directed to locally-held copies of resources. The OCLC WorldCat database has already been harvested by Google Scholar, so that all the records in this database (a large Union Catalogue) are searchable via Google Scholar.
Google is also offering its 'Library Links' programme which enables libraries using an OpenURL link resolver to include a link from Google Scholar to their local resources as part of the Google Scholar search results. Google Scholar users can personalise their searching by selecting their 'home' library as a preference. In order to set up integration with an OpenURL resolver, libraries simply need to export their holding from their link resolver database and send this to Google. Once set up, Google will harvest new links from the link resolver database on an ongoing basis.
A mash-up can be described as a web site which uses content from more than one source to create a completely new service. One example of a tool which can be used to support 'mash-ups' is Greasemonkey [10]. Greasemonkey is an extension for the Firefox web browser which enables the user to add scripts to any external web page to change its behaviour. The use of scripts enables the user to easily control and re-work the design of the external page to suit their own specific needs.
The University of Huddersfield have used Greasemonkey to enable local information to be displayed in Amazon when a user is searching Amazon [11]. The information is drawn from their Library OPAC - for example, users can be shown whether a particular title is available in the Library at Huddersfield, and can link back to the Library OPAC to see the full record. If the book is out on loan, a due date can be shown. This approach encourages users back into the Library environment to use Library services rather than making a purchase through Amazon.
Intute is a free online service managed by JISC for the UK higher education community [12]. It provides access to a searchable catalogue of quality-stamped web resources suitable for use in education. It was previously known as the RDN (Resource Discovery Network). Intute can be used by libraries to create their own local lists of web resources, thus reducing the need for libraries to maintain their own lists of useful Web sites for their users. Libraries can use the MyIntute service to create their own lists of resources drawn from the Intute catalogue. These can be updated on a weekly basis, if required, by creating weekly email alerts which identify new records added to the database which meet a stated set of criteria. The records can then be exported in order to present them on the libraries' own Web site, using local branding and look and feel. Library staff can add new records to the Intute database if they find useful resources which have not already been catalogued in Intute.
Blogs are increasingly used by libraries as promotional, alerting and marketing tools; providing a useful method of promoting new services, alerting users to changes and offering advice and support.
The Library at the Royal College of Midwives [13] runs a blog to keep users informed about new service developments. Typical postings include information about new books received by the Library, pointers to content from electronic journals, news about new projects and services and other items which might usually be found in a Library newsletter. The advantage of the blog over a newsletter is that it is quick and easy to maintain and update, can therefore be kept more up-to-date, and can be integrated into the other services that the Library offers, through the Library Web site. Users can also choose to receive it as an RSS feed.
At the University of Leeds, Angela Newton runs a blog which is aimed at supporting information literacy developments [14]. Angela's blog is focused mainly at academic and support staff at Leeds who are interested in developing information-literate students. She focuses on a range of topics, such as assessment and plagiarism, academic integrity, use of information in education, research methods and e-learning tools. Angela's blog is one of a number of 'practitioner' blogs at Leeds, and has been well received by the e-learning community within the institution.
Another example is the "Univ of Bath Library Science News" service. In this case a blog service hosted at Blogspot.com provides "Updates for the Faculty of Science from your Subject Librarians: Linda Humphreys (Chemistry, Physics, Pharmacy & Pharmacology, Natural Sciences) Kara Jones (Biology & Biochemistry, Mathematics and Computing Sciences)" [15].
Web 2.0 is described by Wikipedia as referring to "a second generation of services available on the web that lets people collaborate and share information online" [1].
Web 2.0 is essentially about creating richer user experiences through providing interactive tools and services. Web sites which utilise aspects of Web 2.0 are often personalisable, dynamically driven, and rich in community tools and sharing functions. The data from underlying systems, such as a Library Management System, can be exposed and shared, usually using XML. Web 2.0 developments are underpinned by open source software and open standards - and they often use widely available components such as RSS, blogging tools and social bookmarking services.
Recently, the term Library 2.0 has also come to prominence [2]. Library 2.0 follows the principles of Web 2.0, in that it promotes the evaluation and adoption of software and tools which were originally created outside of the Library environment. These are over-layed on traditional library services - such as the Library OPAC - in order to create a more dynamic, interactive and personalisable user experience.
Information professionals often express concern about a number of issues relating to implementation of Web 2.0 within their Library service.
A significant concern centres on questions regarding scaleability of the Web 2.0 approach. Information professionals are usually concerned with finding institution-wide approaches to service provision - for example, in relation to reading lists it is important that a Library service is able to receive these from tutors in a timely fashion, that they are supplied in a consistent format and that they are made available in a standard and consistent way - perhaps through a central reading list management service with links to the Library Web site and the VLE. If other approaches start to be used it becomes difficult for these to be managed in a consistent way across the institution. For example, a tutor might decide to use a service such as Librarything [3] to create his or her own online reading list. Information professionals then face a potential headache in finding out about this list, synchronising it with other approaches across the institution, integrating it with other systems on campus such as the Library Sys tem, VLE or portal and presenting it in a consistent fashion to students.
Another concern centres on the supportability of Web 2.0 tools and services. Information professionals are often involved with training users to use library tools and services. They use a variety of approaches in order to achieve this ranging from hands-on training sessions, through to paper-based workbooks and interactive online tutorials. Information professionals are often concerned that users will struggle to use new tools and services. They are keen to develop training strategies to support implementation of new services. With Web 2.0 this can be difficult as users may be using a whole range of freely available tools and services, many of which the information professional may not themselves be familiar with. For example, if Tutor A is using Blogger [4] with her students, whereas Tutor B is using ELGG [5]], information professionals may find themselves being faced with expectations of support being provided for a wide variety of approaches. Students might encounter a different set of tools for each module that they take, and the support landscape quite quickly becomes cluttered. Information professionals can start to feel that they are losing control of the environment in which they are training and supporting users, and may also start to feel uneasy at their own inability to keep up to speed with the rapid changes in technology.
Information professionals are also concerned about the longevity of Web 2.0 services. By its very nature, Web 2.0 is a dynamic and rapidly moving environment. Many of the tools currently available have been developed by individuals who are committed to the open source and free software movement who may not be backed by commercial funding; the individuals may have a tendency to lose interest and move on to other things once an exciting new piece of technology comes along. Some successful tools may end up being bought by commercial players which might result in their disappearance or incorporation into a commercial charging model. It appears risky to rely on services which may disappear at any time, where no support contract is available, no guarantee of bugs being fixed or formal processes for prioritisation of developments.
Where Web 2.0 developments are backed by commercial organisations, this may also cause some concern. For example, Amazon provide many useful Web 2.0 services for enhancing the Library OPAC. However, information professionals may feel uneasy about appearing to be promoting the use of Amazon as a commercial service to their users. This might potentially damage relationships with on-campus bookshops, or leave the Library service open to criticism from users that the Library is encouraging students to purchase essential materials rather than ensuring sufficient copies are provided.
Web 2.0 technologies may also raise anxieties concerning strategy issues. Information professionals might worry that if Google Scholar [6] is really successful this would reduce use of Library services, potentially leading to cancellation of expensive bibliographic and full-text databases and a resulting decline in the perceived value of the Library within the institution. Library strategies for promoting information literacy might potentially be undermined by students' use of social tagging services which bypass traditional controlled vocabularies and keyword searching. The investment in purchase and set-up of tools such as federated search services and OpenURL resolvers might be wasted because users bypass these services in favour of freely available tools which they find easier to use.
Information professionals can turn many of the perceived drawbacks of Web 2.0 to their advantage by taking a proactive approach to ensure that their own services are integrated with Web 2.0 tools where appropriate. Google, for example, offers a 'Library Links' programme which enables libraries using an OpenURL link resolver to include a link from Google Scholar to their local resources as part of the Google Scholar search results. Google Scholar users can personalise their searching by selecting their 'home' library as a preference. In order to set up integration with an OpenURL resolver, libraries simply need to export their holding from their link resolver database and send this to Google. Once set up, Google will harvest new links from the link resolver database on an ongoing basis. By using such tools, the information professional can put the Library back in the picture for users, who can then take advantage of content and services that they might not otherwise have come across because they had by-passed the Library Web site.
It is also important to work with Library Systems vendors to encourage them to take an open approach to Web 2.0 integration. Many Library Systems vendors are starting to use Web 2.0 approaches and services in their own systems. For example, the Innovative Interfaces' LMS [7] now provides RSS feed capability. RSS feeds can be surfaced within the OPAC, or can be driven by data from the Library system and surfaced in any other Web site. This provides a useful service for ensuring greater integration between Library content and other systems such as institutional VLEs or portals. Users can also utilise RSS feeds to develop their own preferred services. Information professionals should lobby their LMS partners to support a more open standards approach to service development and integration, and should ensure that they don't get too constrained by working with one particular vendor.
Use of the national services can also help to ensure a more sustainable approach is taken to Web 2.0 developments. For example Intute [8], a nationally funded service working closely with the higher education community, can provide a range of Web 2.0 services which libraries can utilise in enhancing their own local services, with the advantage that the service is funded on a long-term basis and support can be provided by a dedicated team of staff employed full-time to resolve issues, develop services and fix bugs.
Information professionals also need to work together to share ideas and experiences, implement developments and learn from each other. There are already lots of good examples of this kind of sharing of ideas and expertise - for example, Dave Pattern's blog at the University of Huddersfield [9] provides a useful resource for those interested in implementing Web 2.0 services in a library context. It is also important that information professionals are willing to work across professions - implementation of Web 2.0 services requires the contribution of IT professionals, e-learning specialists and academics.
Finally, information professionals need to be willing to get their hands dirty and take risks. Web 2.0 is often concerned with rapid deployment of services which may still be in a beta state. The key is to get things out quickly to users, then develop what works and learn from things that doesn't. This requires a willingness to be flexible, a confidence in users' ability to cope with rapid change without requiring a lot of hand-holding and support, and the courage to step back from a particular approach that hasn't worked and move on to other things. Not everything will be successful or enthusiastically taken up by your users and you need to be prepared to cut your losses if something does not work. Users' views should be actively sought, and they should be involved in the development and testing process wherever possible.
This document describes how Wiki software can be used to enrich events such as conferences and workshops. The document provides examples of how Wikis can be used; advice on best practices and details of a number of case studies.
Many events used to support the development of digital library services nowadays take place in venues in which WiFi network is available. Wikis (Web-based collaborative authoring tools) are well suited to exploit such networks in order to enrich such events in a variety of ways.
Examples of how Wikis can be used at events include:
Issues which need to be addressed when planning a Wiki service at an event include:
A summary of use of Wikis at several UKOLN events are given below.
| Event | Comments |
|---|---|
| Joint UKOLN/UCISA Workshop, Nov 2004 | A workshop on "Beyond Email: Strategies For Collaborative Working In The 21st Century" was held in Leeds in Nov 2004. The four discussion groups each used a Wiki provided by the externally-hosted Wikalong service. The Wiki pages were copied to the UKOLN Web site after the event. It was noted that almost 2 years after the event the original pages were still intact (although link spam was subsequently found). See <http://www.ukoln.ac.uk/web-focus/events/workshops/ucisa-wlf-2004-11/> |
| IWMW 2005 Workshop, Jul 2005 | Wikalong pages were set up for the discussion groups at the Institutional Web Management Workshop 2005. As an example of the usage see <http://www.ukoln.ac.uk/web-focus/events/workshops/ webmaster-2005/discussion-groups/south-east/> |
| Joint UKOLN / CETIS / UCISA Workshop, Feb 2006 | A workshop on Initiatives & Innovation: Managing Disruptive Technologies was held at the University of Warwick in Feb 2006. The MediaWiki software was installed locally for use by the participants to report on the discussion groups. See <http://www.ukoln.ac.uk/web-focus/events/workshops/ ucisa-ukoln-cetis-2006/wiki/>. |
| ALT Research Seminar 2006 | The licensed Jot Wiki service was used during a day's workshop on Emerging Technologies and the 'Net generation'. The notes kept on the Wiki were used to form the basis of a white paper. See <http://altspring.jot.com/WikiHome>. |
| IWMW 2006 Workshop, Jun 2006 | The MediaWiki software was used by the participants at the Institutional Web Management Workshop 2006 to report on the discussion groups and various sessions. It was also available for use prior to the event. See <http://www.ukoln.ac.uk/interop-focus/community/index/IWMW2006> |
This document describes how social tagging services can be used to enrich events such as conferences and workshops. The document provides examples of how social tagging services can be used; advice on best practices and details of a number of case studies.
Social tagging services, such as social bookmarking services (e.g. del.icio.us) and photo sharing services (e.g. Flickr) would appear to have much to offer events such as conferences and workshops, as such events, by definition, are intended for groups of individuals with shared interests.
Since many events used to support the development of digital library services nowadays take place in venues in which WiFi network is available, such events are ideal for exploiting the potential of social tagging services.
Examples of how social tagging can be used at events include:
Issues to be addressed when using social networking services at events include:
The Institutional Web Management Workshop 2006, held at the University of Bath on 14-16th June 2006, made extensive use of social bookmarking services:
Increasingly WiFi networks are available in lecture theatres [1]. With greater ownership of laptops, PDAs, etc. we can expect conference delegates to make use of the networks. There is a danger that this could lead to possible misuse (e.g. accessing inappropriate resources; reading email instead of listening; etc.) This document describes ways in which a proactive approach can be taken in order to exploit enhance learning at events. The information in this document can also be applied to lectures aimed at students.
A simple technique when PowerPoint slides are used is to make the slides available on the Web and embed hypertext links in the slides (as illustrated). This allows delegates to follow links which may be of interest.
Providing access to PowerPoint slides can also enhance the accessibility of the slides (e.g. visually impaired delegates can zoom in on areas of interest).
Social bookmarking tools such as del.icio.us can be used to record details of resources mentioned [2] and new resources added and shared.
Providing discussion facilities such as instant messaging tools (e.g. MSN Messenger, Jabber or Gabbly) can enable groups in the lecture theatre to discuss topics of interest.
VoIP (Voice over IP) software (such as Skype) and related audio and video-conferencing tools can be used to allow remote speakers to participate in a conference [3] and also to allow delegates to listen to talks without being physically present.
Delegates can make use of Blogs to take notes: This is being increasingly used at conferences, especially those with a technical focus, such as IWMW 2006 [4]. Note that Blogs are normally used by individuals. In order to allow several Blogs related to the same event to be brought together it is advisable to make use of an agreed tag [5].
Unlike Blogs, Wikis are normally used in a collaborative way. They may therefore be suitable for use by small groups at a conference [6]. An example of this can be seen at the WWW 2006 conference [7].
Although WiFi networks can provide benefits there are several challenges to be addressed in order to ensure that the technologies do not act as a barrier to learning.
Increasingly WiFi networks are available in lecture theatres, conference venues, etc. We are beginning to see various ways in which networked applications are being used to enhance conferences, workshops and lectures [1].
If you are considering making use of a WiFi network to support an event you will need to ensure that (a) a WiFi network is available; (b) costs, if any, for use of the network and (c) limitations, if any, on use of the network. Note that even if a WiFi network is available, usage may restricted (e.g. to academic users; local users; etc.)
There may be a danger in being driven by the technology (just because a WiFi network is available does not necessarily mean that the participants will want to make use of it). Different groups may have differing views on the benefits of such technologies (e.g. IT-focussed events or international events attracting participants from North America may be particularly interested in making use of WiFi networks).
If significant demand for use of the WiFi network is expected you may need to discuss this with local network support staff to ensure that (a) the network has sufficient bandwidth to cope with the expected traffic and (b) other networked services have sufficient capacity (e.g. servers handling logins to the network).
You may choose to provide details of how to access the WiFi network and leave the participants to make use of it as they see fit. Alternatively you may wish to manage the way in which it is used, and provide details of networked applications to support the event, as described in [2], [3] and [4].
If there is a charge for use of the network you will have to decide how this should be paid for? You may choose to let the participants pay for it individually. Alternatively the event organisers may chose to cover the costs.
You will also have to set up a system for managing usernames and passwords for accessing the WiFi network. You may allocate usernames and passwords as participants register or they may have to sign a form before receiving such details.
There will be a need to address the support requirements to ensure that effective use is made of the technologies.
You will need to address various issues related to the venue and the security of computers. For example, you may need to provide advice on where laptop users should sit (often next to a power supply and possibly away from people who do not wish to be distracted by noise). There will also be health and safety issues to consider. There will also be issues regarding the physical security of computers and the security against viruses, network attacks, etc.
Web security is an ongoing concern of many - site developers, browser developers and everyday users. Some of the basics of Web security have been covered in a previous briefing paper [1]. However, the increasing use of Web Services and APIs in various contexts has led to some novel security concerns, as well as the resurgence of several older issues. This document will discuss a few of the security issues brought up by the use of AJAX and 'Web 2.0' service APIs.
Since Web services are not hosted locally, consuming data from such services involves making requests to services on other domains. Default security settings in JavaScript disallow this - most browsers will not permit it for security reasons. There are legitimate security reasons for this. If developers wish to overcome this restriction, they typically create a proxy for that service - a server-side script running on their local domain that forwards the request and returns the response. Proxies must be secured against unauthorised use. Many services will ask for an API key or password; be careful with this information and do not make it visible in the JavaScript of your page.
Do not consider the browser as a secure environment; users can read JavaScript - even if it has been obfuscated - and alter it as it runs on their machine. In fact, they can tailor requests that do not make use of the page at all. Therefore, ensure that all the crucial business logic takes place on the server, rather than the browser. You may wish to perform it on the browser to avoid unnecessary crosstraffic between client and server, or for usability/interface reasons, but though this means that the logic has been duplicated, it is important to perform this step again when processing input requests.
According to research by Gartner Inc, 70% of attacks occur via the application layer [2]. Before deploying AJAX, consider the risks and ensure that your project is ready and able to meet the commitment required to complete the task securely. Access control in particular should be considered attentively, as well as communications channels - remember that by default XMLHTTPRequest does not encrypt the data it transmits.
Several applications of AJAX have been designed to provide almost real-time input or feedback to the user, or for continuous small updates to be made to a page. When putting together an application using AJAX or frequent service calls in general, add up the amount of bandwidth that will be used during a typical interaction or use of the service.
If your service is slow or unavailable - or JavaScript is turned off on the browser - the majority of web applications should still work. The only exception to this is the relatively small subset of applications whose functionality depends directly on input taken from services, such as mash-ups based around maps taken from Google Earth.
Because AJAX applications share the business logic between the server and the client, the developers responsible for each element need to work together closely. Developers dealing with technology relatively new to them will need time to produce successive prototypes, since this is a learning process with few authoritative references from which to work.
As with traditional Web applications [3], make security a priority, and plan for maintenance in your budget. When specifying an application, page or component that takes user input, write down a list of possible vulnerabilities and ensure that you have addressed these during the design and build phases. Test your Web applications - both the JavaScript layer and the server-side layer(s). Speak to a security expert if possible, and ensure that you have taken reasonable precautions. A secure application can only be ensured by an ongoing commitment to that aim.
Finally, be conservative with application of novel technologies, and consider a 'feature-freeze' and testing cycle before deployment. New features will also require testing before deployment, so plan to add features only when there is time to audit the result.
[ Home Page - Surveys - Documents - Presentations - Search ]
Web page by Brian Kelly of UKOLN.
Last Modified 1-August-2006
Email comments to webmaster@ukoln.ac.uk