tags) were used in place of tables to create areas on the page (a banner at the top, a side bar for providing a summary of the page content), graphics were used sparingly, and colour was used to create a consistent and recognisable look across the site. It is also worth noting that I approached the design of the Web site with the attitude that it I could not assume that it would be possible to control layout down to the nearest point.
While writing the pages I tested primarily against Netscape 4.7, since this had the poorest support of XHTML and CSS of the browsers which we wanted to make a good job of rendering the Web design. I also made heavy use of the W3C XHMTL and CSS validation service [2], and against Bobby [3] to check for accessibility issues. Once the code validated and achieved the desired effect in Netscape 4.7 I checked the pages against a variety of browser platforms.
While it was never my aim to comply with a particular accessibility level, the Bobby feedback allowed me to enhance accessibility while building the pages.
Problems Experienced
Most of the problems stemmed from the need to support Netscape 4.7, which only partially implements the CSS specification. This cost time while I tried approaches which didn't work and then looked for work-around solutions to achieve the desired effect. For example, Netscape 4.7 would render pages with text from adjacent columns overlapping unless the divisions which defined the columns had borders. Thus the
tags have styles which specify borders with border-style: none; which creates a border but doesn't display it.
The key problem here is the partial support which this version of Netscape has for CSS: older versions have no support, and so the style sheet has no effect on the layout, and it is relatively easy to ensure that the HTML without the style sheet makes sense.
Another problem was limiting the amount of white space around headings. On one page in particular there were lots of headings and only short paragraphs of text. Using the HTML
, , , etc. tags left a lot of gaps and led to a page which was difficult to interpret. What I wanted to do was to have a vertical space above the headings but not below. I found no satisfactory way of achieving this using the standard heading tags which worked in Netscape 4.7 and didn't cause problems in other browsers. In the end, I created class styles which could be applied to a to give the effect I wanted e.g.:
Subheading
Short paragraph
This was not entirely satisfactory since any indication that the text was a heading is lost if the browser does not support CSS.
Pleasant Surprises
The Web site is now two years old and in that time I have started using two new browsers. I now use Mozilla as my main browser and was pleasantly surprised that the site looks better on that than on the browsers which I used while designing it. The second browser is an off-line Web page viewer which can be used to view pages on a PDA, and which makes a reasonable job rendering the FAILTE Web site - a direct result of the accessibility of the pages, notably the decision not to use a table to control the layout of the page. This is the first time that the exhortation to write Web sites which are device-independent has been anything other than a theoretical possibility for me (remember WebTV?)
Things I Would Do Differently
I think that it is now much easier to use XHTML and CSS since the support offered by authoring tools is now better. I would also reconsider whether Netscape 4.7 was still a major browser: my feeling is that while it still needs supporting in the sense that pages should be readable using it, I do not think that it is necessary to go to the effort of making pages look attractive. In particular I would not create styles which imitated in order to modify the appearance of headings. I look forward to the time when it is possible to write a page using standard HTML repertoire of tags without any styling so that it makes sense as formatted text, with clear headings, bullet lists etc., and then to use a style sheet to achieve the graphical effect which was desired.
References
1 FAILTE,
2 W3C HTML Validation Service, W3C,
3 Bobby, WatchFire,
Contact Details
Phil Barker, ICBL, MACS, Heriot-Watt University, Edinburgh
Email: philb@icbl.hw.ac.uk URL: http://www.icbl.hw.ac.uk/~philb/
Standards For e-learning: The e-MapScholar Experience
About This Document
This case study describes the approaches to choosing and deploying standards for e-learning in the e-MapScholar project.
Citation Details
Standards For e-learning: The e-MapScholar Experience, QA Focus, UKOLN,
Keywords: standards, Javascript, browser, e-Map-Scholar, case study
Background
The e-MapScholar project [1] aims to develop tools and learning and teaching materials to enhance and support the use of geo-spatial data currently available within tertiary education in learning and teaching, including digital map data available from the EDINA Digimap service [2]. These tools and learning materials will be delivered over the Web and will be accessed from a repository of materials branded the "Learning Resource Centre".
The project is funded by the JISC [3] to form part of the DNER, now called the Information Environment [4] and works closely with other projects funded under the same programme.
The Need For Standards
From the outset of the e-MapScholar Project it was apparent that various standards needed to be agreed upon and conformed to. The two core issues were:
Material and software would be developed at a number of different sites, but needed to be integrated together as part of the software engineering process.
The solution should work on a variety of different platforms, yet be reliable and predictable in its behaviour.
In reaching a broad community of users, a compromise needed to be found between delivery of service to 'low spec' PCs and high-end functionality that would support interactive tools. A range of technical discussions at the outset of the project discussed these implications in the context of choice of standards and technical evaluation criteria.
The Approach Taken
The various technical elements and their respective standards were specified at the start of the project. These included the use of Java 1.1 for the interactive applets (see Figure 1), and Javascript 1.2 and HTML 4.01 for the user interface. All learning material content would be stored in XML files which would be transformed using XSLT and Java. Similarly, authors of learning materials would also be provided with a set of guidelines for producing the content.
Figure 1: Screen shots of interactive tools produced by e-MapScholar
Java 1.1
All software components were written in Java 1.1. All code has and remains fully compliant with this version. Though Java 1.1 does not have as much functionality as later versions e.g. 1.2 and 1.3, it makes the service compliant with a broader choice of browsers and operating systems. Java code was also written to control the conversion of XML into HTML.
JavaScript 1.2 and HTML 4.0.1
HTML 4.01 is used for the layout of the learning resource centre pages. Using HTML standards ensure that the site is more accessible to a wider range of browsers, and is transformed more quickly and easily. The use of client-side JavaScript has been kept to a minimum and only used for pop-up window items such as the help menu and map legends. These are all written in JavaScript 1.2. Using this version of JavaScript again reflected a compromise between control of graphics and levels of interaction, and compatibility with browsers and operating systems.
Author Guidelines
Authors providing content to the learning units have been issued with a document containing guidance notes. This document aims to standardise the content of the learning units, by providing procedures on how various elements of the units should be written. These elements include guidelines on the structuring of a unit, wording of learning objectives and quiz tools, and the acceptable formats for images and photographs. Complying with these guidelines will ensure the pedagogical aspect of the units meet teaching requirements and are suitable for students across a range of abilities.
The imposition of all of the above standards increased the chances of interoperability between the various units and modules comprising the service.
Problems Experienced
The use of Java 1.1 should ensure that users do not have to download the plug-in as the majority of browsers come packaged with this version of Java Virtual Machine installed (or higher). However, last year Microsoft launched their latest version of Internet Explorer (6.0) without a Java VM. This means that users of IE 6 will have to download a Java plug-in to run any Java applets, regardless of what version of Java the applets have been created with.
Web statistics [5] (illustrated in Figure 2) show that Internet Explorer is the most widely used Web browser, with IE 6 already accounting for a considerable portion of this usage. This means that 48% of Internet users will have to download the Java plug-in order to run any Java applets.
Figure 2: Pie chart of browser statistics generated using data from [6]
With many users upgrading to the new service in the future, one might question the point in using Java 1.1 when the majority of Internet users will still have to download the plug-in? Ideally, standards should be employed with the majority of users in mind.
Things We Would Do Differently
At the outset we chose Java 1.1 since it was incorporated in Internet Explorer and the majority of other browsers, and would not involve users having to download the plug-in. It is estimated that 48% of web users are using IE6, all of whom will need to download the Java plug-in. Our ambition of 'use without plug-in' has somewhat evaporated, and an argument could now be made that we could ask users to download other plug-ins, notably 'Flash'. Ironically IE6 users would not need to download Flash player as it comes ready packaged in IE6.
If Flash were used (in conjunction with Java 1.1) it would allow greater levels of interaction with the user, and easier development of visualisation tools. However, this would have required access to Flash developers which the project does not have at this stage. Currently no decision has been made on whether it is worth taking advantage of the additional functionality afforded by Flash player, but it does open a door, which was previously thought to be firmly closed.
On the whole, throughout the project, various software engineering problems have arisen. But broad agreement on the use of standards coupled with clarification of system requirements, and requirement specifications has helped to keep the project manageable from a software engineering prospective.
References
1 e-MapScholar Web site, EDINA,
2 Digimap Web site, EDINA,
3 JISC Web site,
4 Information Environment, JISC,
5 Browser News Web Statistics,
6 W3C Schools Browser Statistics,
Contact Details
Lynne RobertsonGeographySchool of Earth, Environmental and Geographical SciencesThe University of EdinburghDrummond StreetEdinburgh EH8 9XP
Email: lr@geo.ed.ac.uk
Standards and Accessibility Compliance for the DEMOS Project Web Site
About This Document
This case study describes the approaches taken to use of standards and accessible Web design by the DEMOS project.
Citation Details
Standards and Accessibility Compliance for the DEMOS Project Web Site QA Focus, UKOLN,
Related Documents
See also the Compliance With HTML Standards (briefing-01) briefing document.
Note
This case study is also included in the QA For Web Handbook.
Keywords: standards, Web, matrix, accessibility, compliance, DEMOS, case study
Background
Funded by the Higher Education Funding Council for England under strand three of the initiative 'Improving Provision for Students with Disabilities', the aim of the DEMOS Project [1] was to develop an online learning package aimed at academic staff and to examine the issues faced by disabled students in higher education. The project was a collaboration between the four universities in the Manchester area - the University of Salford [2], the University of Manchester [3], the Manchester Metropolitan University [4] and UMIST [5].
The Web Site
At the start of the project the purpose of the Web site was still unclear, which made it difficult to plan the information structure of the site. Of course, it would serve as a medium to disseminate the project findings, research reports, case studies... but for months the design and the information architecture of this site seemed to be in a never-ending state of change.
In the early stage of the project virtual learning environments, such as WebCT, were tested and deemed unsuitable for delivering the course material, due to the fact that they did not satisfy the requirements for accessibility.
At this point it was decided that the Web site should carry the course modules. This changed the focus of the site from delivering information about the progress of the project to delivering the online course material.
In the end we envisioned a publicly accessible resource that people can use in their own time and at their own pace. They can work through the modules in the linear fashion they were written in or they can skip through via the table of contents available on every page. There are also FAQ pages, which point to specific chapters.
Many academic institutions have already added links to the DEMOS materials on their own disability or staff development pages.
Problem Being Addressed
To ignore accessibility would have been a strange choice for a site that wants to teach people about disability. Accessibility was therefore the main criteria in the selection of a Web developer.
I have been a Web designer since 1998 and specialised in accessibility from the very beginning. For me it is a matter of ethics. Now it is also the law.
The challenge here was to recreate, at least partially, the feeling of a learning environment with its linear structure and incorporating interactivity in form of quizzes and other learning activities without the use of inaccessible techniques for the creation of dynamic content.
The Approach Taken
Accessibility techniques were applied from the beginning. But the site also represents an evolution in my own development as a Web designer, it always reflected my own state of knowledge. Where in the beginning accessibility meant eradicating the font tag, it now means standard-compliant code and tableless CSS layout.
Valid and Accessible Design and Code
This site was designed in compliance with the latest standards developed by the World Wide Web Consortium (W3C) [6] and using the latest accessibility techniques [7] as recommended by the Web Accessibility Initiative (WAI) [8].
In December 2001 the code base of the site was switched over to XHTML 1.0 Transitional. In November 2002 the site was further improved by changing it to a CSS layout, which is used to position elements on the page without the use of tables. The only layout table left is the one holding the header: logo, search box and top navigation icons.
Stylesheets are also used for all presentational markup and a separate print stylesheet has been supplied.
The code was validated using the W3C Validation Service [9].
Standards = Accessibility
With the advent of standard-compliant (version 6 and 7) browsers, the Web developer community started pushing for the adoption of the W3C guidelines as standard practise by all Web designer. Now that version 3 and 4 browsers with all their proprietary mark-up were about to be consigned to the scrap heap of tech history, it was finally possible to apply all the techniques the W3C was recommending. Finally the makers of user agents had started listening to the W3C too and were making browsers that rendered pages designed according to standards correctly. (It turns out things weren't all that rosy but that's the topic for another essay.)
Standards are about accessibility, or, as the W3C phrases it, 'universal design'. They ensure that universal access is possible, i.e. that the information contained on a Web page can be accessed using:
a modern standard-compliant browser on an up-to-date high spec PC
an old browser on a slow connection and legacy hardware
a text-only browser (often used as a basis for screen readers)
assistive technology (screen readers, foot pedals, braille printers, etc.)
a small device (PDA, mobile phone)
User Control
The most important reason for designing according to standards is that it gives the user control over how a Web page is presented. The user should be able to increase font sizes, apply preferred colours, change the layout, view headers in a logical structure, etc.
This control can be provided by the Web designer by:
using correct structural markup
using stylesheets to specify presentational styles (such as fonts and colours)
using CSS layout (instead of table layout)
applying accessibility techniques
On the DEMOS site, all presentational styles are specified in stylesheets. The site 'transforms gracefully' when stylesheets are ignored by the user agent, which means that the contents of a page linearises logically. The user has control over background and link colours via the browser preferences and can increase or decrease font sizes.
The DEMOS Guide to Accessible Web Design contains a chapter on User Control [10], which describes how these changes can be applied in various browsers.
Accessibility Techniques
(The links below lead to pages on the DEMOS site, more precisely: the DEMOS Guide to Accessible Web Design [11])
Some of the techniques used:
A mechanism to skip to the main content was provided.
Access keys were defined.
Alternative descriptions were provided for all images. Purely decorative images contain an empty ALT attribute.
Links are separated with printable characters.
Stylesheets are used to allow user control.
All acronyms and abbreviations are labelled.
Icons and colours are used in a consistent manner to improve accessibility for users with cognitive or learning disabilities.
The site can be navigated via the keyboard.
Tables are only used for data, not for layout (except for the header table).
Frames and dynamic content are avoided.
Accessible interactivity was provided using PHP.
Text is kept scannable, language clear and jargon is explained in glossaries.
Language changes are declared for the benefit of screen readers.
More information and details: Accessibility techniques used on the DEMOS site [12] (listed by WAI checkpoints).
Inclusive Design
Web developers sometimes believe that accessibility means providing a separate text-only or low-graphics version for the blind. First of all: I have always been on that side of the camp that believes that there should be only one version of a site and that it should be accessible.
"Don't design an alternative text-only version of the site: disabled people are not second class citizens..." (Antonio Volpon, evolt.org [13]).
Secondly, accessibility benefits not only blind people [14]. To be truly inclusive we have to consider people with a variety of disabilities, people with a range of visual, auditory, physical or cognitive disabilities, people with learning disabilities, not to forget colour blindness, senior citizens, speakers of foreign languages, etc.
Surely not all of them are part of the target audience, but you never know, and applying all available accessibility techniques consistently does not take that much more effort.
We tried to provide a satisfactory experience for everyone, providing user control, keyboard access, icons and colour to loosen things up, whitespace and headers to break up text in digestable chunks. And we encourage people to provide feedback, especially if they experience any problems.
Accessibility Testing
To ensure accessibility the site was tested across a variety of user agents and on different platforms. A number of screenshots from these tests [15] can be found at the DEMOS site. The site has also been tested using the Bobby [16] and Wave [17] accessibility checkers. It is AAA compliant, which means that it meets all three levels of accessibility.
Accessible Interactivity
One of the last things we finally solved to our satisfaction was the problem of creating interactive quizzes and learning activities for the course modules without the use of inaccessible techniques. Many of the techniques for the creation of dynamic and multimedia content (JavaScript, Java, Flash...) are not accessible.
Eventually we discovered that PHP, a scripting language, was perfect for the job. PHP is processed server-side and delivers simple HTML pages to the browser without the need for plug-ins or JavaScript being enabled.
Problems Encountered
Information Architecture and Navigation
As mentioned before, the Web site started without a clear focus and without a clear structure. Therefore there wasn't much planning and structured development. In the first months content was added as it was created (in the beginning mainly information about the project) and the site structure grew organically. This caused some problems later when main sections had to be renamed and content restructured. From the Web development point of view this site has been a lesson in building expandability into early versions of Web site architecture.
Since there was so much uncertainty about the information architecture in the beginning, the navigation system is not the best it could be. The site grew organically and navigations items were added as needed. The right-hand navigation was added much later when the site had grown and required more detailed navigation - more detailed than the main section navigation at the top of the page underneath the logo and strapline.
But the right-hand navigation is mainly sub-navigation, section navigation, which might be confusing at times. At the same time, however, it always presents a handy table of contents to the section the visitor is in. This was especially useful in the course modules.
The breadcrumb navigation at the top of the main content was also added at a later date to make it easier for the visitor to know where they are in the subsections of the site.
Netscape 4
Already mentioned in Phil Barker's report on the FAILTE Web site [18], Netscape 4 was also my biggest problem.
Netscape 4 users still represent a consistent 12% of visitors in the UK academic environment (or at least of the two academic sites I am responsible for). Since this is the target audience for the DEMOS site, Netscape 4 quirks (i.e. its lack of support for standards) had to be taken into account.
Netscape understands just enough CSS to make a real mess of it. Older browsers (e.g. version 3 browsers) simply ignore stylesheets and display pages in a simpler fashion with presentational extras stripped, while standard-compliant browsers (version 6 and 7) display pages coded according to standards correctly. Netscape 4 is stuck right between those two scenarios, which is the reason why the DEMOS site used tables for layout for a long time.
Tables are not really a huge accessibility problem if used sparingly and wisely. Jeffrey Zeldman wrote in August 2002 in 'Table Layout, Revisited' [19]:
Table layouts are harder to maintain and somewhat less forward compatible than CSS layouts. But the combination of simple tables, sophisticated CSS for modern browsers, and basic CSS for old ones has enabled us to produce marketable work that validates - work that is accessible in every sense of the word.
Tables might be accessible these days because screenreader software has become more intelligent but standard-compliance was my aim and layout tables are not part of that.
Luckily techniques have emerged that allow us to deal with the Netscape 4 quirks.
One option is to prevent Netscape 4 from detecting the stylesheet, which means it would deliver the contents in the same way as a text-only browser, linearised: header, navigation, content, footer following each other. No columns, colours, font specifications. But an audience of 12% is too large to show a site to that has lost its 'looks'. The site still had to look good in Netscape 4.
The other option is to use a trick to get Netscape 4 to ignore some of the CSS instructions [20] . Deliver a basic stylesheet to Netscape 4 and an additional stylesheet with extra instructions to modern browsers. This required a lot of tweaking and actually consumed an enormous amount of time but only because I was new to CSS layout. I have converted a number of other sites to CSS layout in the meantime, getting better at it every time.
The DEMOS site now looks good in modern browsers, looks OK but not terrific in Netscape 4, and simply linearises logically in browsers older than that and in text-only browsers.
To Do
There are still a few issues that need looking at, e.g. the accessibility of input forms needs improving (something I'm currently working on) and the structural mark-up needs improving so that headers are used in logical order starting with
There are also a few clashes of forms with the CSS layout. All forms used on the DEMOS site are still in the old table layout. I haven't had the time to figure out what the problem is.
Eventually I also plan to move the code to XHTML Strict and get rid of the remains of deprecated markup [21], which XHTML Transitional, the DOCTYPE [22] used at the moment, still forgives.
The Site's Future
Of course it is important to keep the materials produced over the last two and a half years accessible to the public after the funding has run out. This will happen at the end of March 2003. This site will then become part of the Access Summit Web site (at time of writing still under construction). Access Summit is the Joint Universities Disability Resource Centre that was set up in 1997 to develop provision for and support students with disabilities in higher education in Manchester and Salford.
We currently don't know whether we will be able to keep the domain name, so keep in mind that the URL of the DEMOS site might change. I will do my best to make it possible to find the site easily.
Further Information
DEMOS Web site,
Jarmin.com Guide to Accessible Web Design,
A collation of tips, guidelines and resources by the author of this case study. Focuses on techniques but includes chapters on barriers to access, evaluation, legislation, usability, writing for the Web and more. Includes a huge resources section where you can find links to W3C guidelines, accessibility and usability articles, disability statistics, browser resources, validation tools, etc. This section also contains resources that helped me understand the power of stylesheets .
DEMOS Accessibility Guide,
Consists of the Techniques section from the Guide to Accessible Web Design , plus extra information on accessibility techniques used on the DEMOS site (listed by WAI checkpoints) and a number of demonstrations on how the site looks under a variety of circumstances.
References
The DEMOS Project,
University of Salford,
University of Manchester,
Manchester Metropolitan University,
UMIST,
World Wide Web Consortium (W3C),
Guide to Accessible Web Design, Iris Manhold,
Web Accessibility Initiative (WAI), W3C,
Validation Service, W3C,
DEMOS Accessibility Guide: User Control, Iris Manhold,
DEMOS Accessibility Guide, Iris Manhold,
Accessibility Techniques Used On The DEMOS Site,
The Lifecycle of Web Accessibility, Antonio Volpon, evolt.org,
Benefits Of Accessibility, Iris Manhold,
The DEMOS site Tested,
Bobby Accessibility Checker,
Wave Accessibility Checker,
Standards and Accessibility Compliance for the FAILTE Project Web Site, QA Focus, Phil Barker,
Table Layout, Revisited, Jeffrey Zeldman, A List Apart, 17 August 2001,
Tricking Browsers And Hiding Styles, Eric A. Meyer,
Deprecated markup,
Doctype,
Contact Details
Iris ManholdManchester Metropolitan UniversityManchester
6 Standards Toolkit
Standards Toolkit
The metadata toolkit provides a checklist which is intended to ensure that projects address key areas when planning the deployment of metadata.
Note that an online version of this toolkit is available at . The online version provides links to relevant QA Focus resources.
1. Ownership of StandardIs the standard you are considering using:
owned by an acknowledged open standards body?
owned by a neutral body, but not (yet) formally adopted as an open standard (e.g. Dublin Core)?
owned by a company (i.e. a proprietary standard)2. Openness of Proprietary FormatIf the standard is proprietary:
Is there an open development process (e.g. Sun's Java Community Programme)?
Is the specification is published openly (e.g. Microsoft's RTF)?
Is the specification has been published by third parties reverse-engineering the specification (e.g. Microsoft's Word)?
Has the specification not been published?3. Availability of ViewersAre viewers for the format:
Available free of charge?
Available on multiple platforms?
Available as open source?
4. Availability of Authoring ToolsAre authoring tools for the format:
Available free of charge?
Available on multiple platforms?
Available as open source?
5. Functionality of the StandardDoes the standard provide:
Rich functionality?
Basic functionality?
6. User RequirementsDoes the standard:
Largely provide the functionality required by end users of the service?
Adequately provide the functionality required by end users of the service?
Insufficiently provide the functionality required by end users of the service?
Largely fail to provide the functionality required by end users of the service? 7. Fitness for PurposeIs the standard:
Ideal for the purpose envisaged?
Appropriate for the purpose envisaged?
Not particularly appropriate for the purpose envisaged?
8. Resource ImplicationsWill use of the standard:
Have significant staffing implications for development and maintenance?
Have relatively few staffing implications for development and maintenance?
Have significant financial implications for development and maintenance?
Have relatively few financial implications for development and maintenance? 9. PreservationIs the format:
Easy to preservation?
Difficult to preserve?
You are unsure of the ease of preservation?
10. MigrationIf it becomes necessary to migrate to an alternative format will it be:
Easy to migrate to alternative formats?
Difficult to migrate to alternative formats?
11. Stability of StandardIf it becomes necessary to migrate to an alternative format will it be:
Easy to migrate to alternative formats?
Difficult to migrate to alternative formats?
12. Cultural FactorsAs well as the various technical issues addressed above, there is also a need to consider the organisational culture of the developers. For example is your organisation:
Keen to make use of innovative developments?
Keen to make use of mature solutions?
Use Of This Toolkit
It is envisaged that this toolkit will be used to support the planning processes at the early stages of the development of a digital library service.
The issues covered in the toolkit are intended to help in the technical and managerial discussions which projects will be involved in.
Projects will probably find it helpful if the answers to the issues raised are documented, and possibly included in reports to the funders or as part of the projects internal documentation.
7 Further Information
We hope that the QA For Standards Handbook provides useful advice to projects and services which are engaged in digital library development work.
In addition to this handbook there are other sources of information funded by the JISC which provide useful advice.
CETIS
CETIS is a JISC-funded advisory service which provides advice on educational metadata for the further and higher education communities.
Further information on CETIS is available on the Web site which is available at .
The CETIS Web site is illustrated.
UKOLN
UKOLN is funded by the JISC and the MLA (Museums, Libraries and Archives Council) to provide advice and support on digital management issues to the further and higher education and cultural heritage communities.
Further information on UKOLN is available on the Web site which is available at .
The UKOLN Web site is illustrated.
Acknowledgements
We are grateful to the following for contributing to the work of the QA Focus project:
Members of the JISC including Caroline Ingram our initial point of contact in JISC and Rachel Bruce and Balviar Notay, who provided valuable advice and support to the QA Focus team following Carolines departure from JISC.
The contributors to the briefing papers and case studies included in the handbook: Lynne Robertson (e-MapScholar project, University Of Edinburgh), Iris Manhold, (DEMOS project, Manchester Metropolitan University) and Phil Barker, (FAILTE project, Heriot Watt University).
Colleagues at UKOLN and the AHDS who provided valuable input to the work of the QA Focus project.
Karla Youngs and Ed Bremner, TASI, for their contributions to the work of QA Focus in its early days.
Others involved in JISC and related work who, knowingly or unknowingly, contributed to our work.
PAGE
PAGE 1
1 Introduction
PAGE 32
PAGE 32
2 About This Handbook
4 Standards Briefing Papers
5 Standards Case Studies
6 Standards Toolkit
7 Further Information
Acknowledgements
Figure 1: The Demos Web Site
Figure 1: The FAILTE home page
The UKOLN Web Site
The CETIS Web Site
& D E
6
7
I
J
K
L
R
X
n
w
y
z
{
! " # $ % & 2 3 ǿ{nc hww mH nH u hww 5mH nH tH u 2j hww h4 >*B*UmH nH ph u hww mH nH uhwt/ hww 0J mH nH u$j hwt/ hww 0J UmH nH u j hww Uhww h8?W h26 j hh] UmH nH u hh] 56CJ aJ hh] CJ0 aJ0 hB CJ0 aJ0 hh] # E
6
X
n
{
T F [^`[ R8]R^8 V 6 3 4 N O P Q R S T U V r s t u rgM2j hww h4 >*B*UmH nH ph u hww mH nH tH u jw h4 UmH nH u 2j hww h4 >*B*UmH nH ph u hww mH nH uhwt/ hww 0J mH nH uhww 5mH nH tH u $j hwt/ hww 0J UmH nH u j} h4 UmH nH u hww mH nH u j hww UmH nH u $ % & @ A B C D E F G H d e f g x y z ׳t׳Z 2j hww h4 >*B*UmH nH ph u jk h4 UmH nH u 2j hww h4 >*B*UmH nH ph u hww mH nH uhww mH nH tH u$j hwt/ hww 0J UmH nH u jq h4 UmH nH u j hww UmH nH uhww mH nH u hwt/ hww 0J mH nH u #z
·©©yhy©N 2j hww h4 >*B*UmH nH ph u j_ h4 UmH nH u hww 5mH nH tH u 2j hww h4 >*B*UmH nH ph u hww mH nH uhwt/ hww 0J mH nH uhww mH nH tH u$j hwt/ hww 0J UmH nH u j hww UmH nH u je h4 UmH nH u hww mH nH u _
| I L - $ m 6 H
=
>
?
Y
Z
[
\
]
^
_
`
a
}
~
Դߠ߆yhyߠ jS h4 UmH nH u hww 5mH nH tH u 2j hww h4 >*B*UmH nH ph u hww mH nH uhww mH nH tH u jY h4 UmH nH u j hww UmH nH uhww mH nH u hwt/ hww 0J mH nH u$j hwt/ hww 0J UmH nH u!
6 7 8 9 Z [ \ v w x y z { | } ~ źӏņlź[ӏņ jG h4 UmH nH u 2j hww h4 >*B*UmH nH ph u hww mH nH uhww mH nH tH u jM h4 UmH nH u j hww UmH nH uhww mH nH u hwt/ hww 0J mH nH u$j hwt/ hww 0J UmH nH u 2j hww h4 >*B*UmH nH ph u
& ' ( B C D F G H I źӏņl_źN_ j; h4 UmH nH u hww 5mH nH tH u 2j
hww h4 >*B*UmH nH ph u hww mH nH uhww mH nH tH u jA
h4 UmH nH u j hww UmH nH uhww mH nH u hwt/ hww 0J mH nH u$j hwt/ hww 0J UmH nH u 2j hww h4 >*B*UmH nH ph uI J K g h i j ) * + E F G I J K L M N j ߱l߱[ j/
h4 UmH nH u 2j hww h4 >*B*UmH nH ph u hww mH nH tH u j5 h4 UmH nH u j hww UmH nH uhww mH nH u 2j hww h4 >*B*UmH nH ph u hww mH nH uhwt/ hww 0J mH nH u$j hwt/ hww 0J UmH nH u#j k l m
& ' ( * + , Ďk^M j# h4 UmH nH u hww 5mH nH tH u 2j hww h4 >*B*UmH nH ph u hww mH nH uhww mH nH tH u j) h4 UmH nH u j hww UmH nH uhww mH nH u $j hwt/ hww 0J UmH nH u 2j
hww h4 >*B*UmH nH ph u hwt/ hww 0J mH nH u , - . / K L M N _ ` a { | } үҤy_ҤN j h4 UmH nH u 2j hww h4 >*B*UmH nH ph u hww mH nH tH u j h4 UmH nH u j hww UmH nH uhww mH nH u 2j hww h4 >*B*UmH nH ph u hww mH nH uhwt/ hww 0J mH nH u$j hwt/ hww 0J UmH nH u hww 5mH nH tH u ! " # $ % & B C D E J K L f ҷҷxҷ^ҷ 2j hww h4 >*B*UmH nH ph u hww mH nH tH u j h4 UmH nH u 2j hww h4 >*B*UmH nH ph u hww mH nH uhwt/ hww 0J mH nH uhww 5mH nH tH u $j hwt/ hww 0J UmH nH u hww mH nH u j hww UmH nH u f g h j k l m n o - ·©©uh`\TP\K\ hh] 6h/ h/ hh] 6hh] j hww Uhww 5mH nH tH u j h4 UmH nH u 2j hww h4 >*B*UmH nH ph u hww mH nH uhwt/ hww 0J mH nH uhww mH nH tH u$j hwt/ hww 0J UmH nH u hww mH nH u j hww UmH nH u j h4 UmH nH u - ) x P B T " " " " " :# # $ $
% k% % *&