QA For Web Sites

1. QA For Web Sites Ed Bremner TASI/ILRT University of Bristol Ed.Bremner@bris.ac.uk Marieke Guy UKOLN University of Bath M.Guy@ukoln.ac.uk Brian Kelly UKOLN University of Bath B.Kelly@ukoln.ac.uk EIB

2. QA For Web Sites • Aims Of Today’s Talk • To discuss some of the approaches currently taken to QA • To summarise findings of surveys of Web sites • To make recommendations for future QA work EIB

3. An Introduction to QA • What is Quality? “Quality is the ability of your product to be able to satisfy your users” Assurance? “Quality assurance is the process that demonstrates your product is able to satisfy your users” EIB

4. An Introduction to QA • What does Quality Assurance give? • ‘Quality’ means your project is ‘useful’ and without ‘quality’ you have nothing • ‘Quality’ provides a future for project • But ‘quality assurance’ needs standards to be meaningful • ‘Quality’ & ‘Best Practice’ can only be considered in terms of being ‘Fit for Purpose’ QA is the opportunity to learn! EIB

5. Approach Taken • Two possible approaches to ensuring compliance with standards and best practices: Enforce • Inspect all project’s work • Strict auditing, with penalties for no-compliance EIB

6. Approach Taken • Two possible approaches to ensuring compliance with standards and best practices: Encourage • Train all project staff • Developmental, explaining reasons for compliance, documenting examples of best practices and providing advice on implementation and monitoring EIB

7. Approach Taken • Two possible approaches to ensuring compliance with standards and best practices: Enforce vs Encourage QA Focus prefers to encourage! QA Focus - a JISC-funded project, formed to support a number of digital library development projects EIB

8. QA for Digitisation • Do it once…..do it right: • Project is fundamentally dependent upon the quality of original product • Quality is the pre-requisite to preservation • Quality expectations will only grow • Delivery problems can be fixed, but capture problems normally can’t EIB

9. QA for Digitisation • A multi-level approach may be taken to QA within the digitisation process: • Strategic QA Carried out before digitisation starts Research and establishing best practice & standards EIB

10. QA for Digitisation • A multi-level approach may be taken to QA within the digitisation process: • Strategic QA • Workflow QA Formative assessment, before & during development Establishing & documenting workflow & processes EIB

11. QA for Digitisation • A multi-level approach may be taken to QA within the digitisation process: • Strategic QA • Workflow QA • Sign-off QA Quality Control : Summative assurance at end of each process, providing an audit history for all QA work undertaken EIB

12. QA for Digitisation • A multi-level approach may be taken to QA within the digitisation process: • Strategic QA • Workflow QA • Sign-off QA • On-going QA Summative assurance as part of long term QA to establish a system to report, check & fix any faults found in future EIB

13. QA for Digitisation • QA Focus promotesa multi-level approach to digitisation: • Strategic QA • Workflow QA • Sign-off QA • On-going QA High Quality Product EIB

14. QA for Digitisation • …If you don’t capture quality… • you can never deliver quality… EIB

15. QA For Web Sites • The issues: • The Web is the main delivery mechanism for projects and services • There is an increasing awareness of the importance of: • Accessibility • Use of new devices (PDAs, WAP, e-books, …) • Repurposing of Web content (e.g. archiving) • Technologies such as XSLT will support repurposing … of valid XML resources • But: • Invalid HTML is the norm • Many authoring tools produce poor HTML • Authors aren’t aware of the problems MG

16. Guidelines • We often say: • Open standards are important • HTML, XML, XHTML, CSS, … are important • but fail to explain why and how • JISC’s QA Focus is addressing such concerns by: • Documenting example of best practices in which projects can share their implementation successes (and difficulties they experienced) • Provide brief advice in specific aspects of the standards and best practices • Surveying its communities to highlight best practices and areas in which improvements can be made • Demonstrating use of testing tools and procedures MG

17. Standards & Best Practices • Standards For Web: • Use compliant HTML / XHTML • Use CSS • Support WAI accessibility guidelines • Best Practices For Web: • Ensure Web resources can are suitable for reuse and repurposing • Where proprietary formats need to be used, flag them and use in most open way MG

18. Surveying The Community • Surveys of project Web sites have been carried out in order to: • Obtain a profile for the community • Identify examples of best practices • Identify areas in which further advice is needed • Surveys included: • HTML & CSS compliance  Accessibility • 404 error pages  HTTP headers • Repurposing resources MG

19. Survey Philosophy • The surveys made use of freely-available Web-based tools: • Methodology is open • No software needs to be installed locally (apart from Web browser) • Findings can be reproduced • Latest results can be obtained by clicking on link to testing service • The surveys typically examined project entry points and not entire Web site as: • This page has the highest profile • The aim is to validate a methodology which can be deployed by projects themselves, not to test every page on behalf of the projects MG

20. Survey Findings • Initial set of findings available from <http://www.ukoln.ac.uk/qa-focus/surveys/web-10-2002/> MG

21. Providing Motivation • We have found evidence of failure to comply with HTML standards • There is a need to explain why compliance is important (and avoid the “it’s OK in my browser” argument) and to provide motivation for projects to update their tools, authoring procedures, etc. • A further set of surveys look at repurposing of the project Web sites: • Availability of Web sites in the Internet Archive • Ease of making Web sites available on a PDA • Transformation of embedded metadata MG

22. A small number of Web sites were not in the Internet Archive due to the robots.txt file. We will need to provide advice in this area. A small number of Web sites could not be transformed. Analysis of HTTP headers indicated that this was due to incorrect HTTP headers. We will need to provide advice in this area. Repurposing Resources • We examined the Web sites to see if they were available in the Internet Archive and could be transformed into a format for viewing on a PDA MG

23. VirtualXHTMLresource Tidy (online) XSLT extraction of DC Visualisation & validation of DC DC in RDFformat RDF Validator Transforming Resources • Project entry points were processed by several online transformation services in order to validate and visualise embedded Dublin Core metadata HTMLresource Original page, containing embedded DC metadata MG

24. Providing Advice • We have: • Survey project Web sites and identified areas of lack of compliance with standards and best practices • Demonstrated examples of the potential importance of compliance for repurposing resources • In addition we need to provide: • Brief focussed advice on the standards • Information on how to monitor compliance • Case studies on solutions deployed by projects themselves • Guidance on dealing with implementation difficulties and what to do when strict compliance is difficult to achieve MG

25. Documentation: Advice • Advisory briefing documents are being produced • These are: • Brief, focussed documents • Informed by findings of the surveys MG

26. Documentation: Case Studies • Case Studies are being commissioned • These are: • Written by projects themselves • Describe the solution adopted to a particular problem • Include details of lessons learnt – not just a press release!

27. Next Steps • Extended Coverage We will be moving on from Web and digitisation to include other areas including: • Metadata  Multimedia • Software development  Deployment into service • … • Moving On From Automated Testing The initial work made use of automated testing tools: • Can be used remotely  Objective • Applicable across all projects We have started work on QA procedures in areas which are not suitable for automated checking MG

28. Limitations • There are a number of limitations to the work we have carried out so far: • Project Web sites have different purposes (information about the project; communications with project partners; project deliverables themselves; etc.) • Projects have different levels of funding, resources, expertise, etc. • Projects are at different stages of development (and some have finished) • The surveys are intended to demonstrate a methodology which projects can use for themselves MG

29. Self Assessment Toolkit • Further Deliverables • We will be developing a self-assessment toolkit for projects to use, by individual projects or across project clusters • The toolkit will consist of: • Examples of QA procedures • Documented examples of use of testing tools • Self-assessment questionnaires • Advice on standards and best practices • Case studies • FAQs • … MG

30. Questions • Any questions? MG