1. Best Practices For Project Web Sites Based on experiences from previous programmes Brian Kelly UK Web Focus UKOLN University of Bath UKOLN is supported by: Email B.Kelly@ukoln.ac.uk URL http://www.ukoln.ac.uk/

2. 2 What Happens When The Funding Stops? When the project funding finishes: The project gracefully turns into a fully-fledged service, with new funding from JISC, the EU, your institution, etc.  The project staff all leave and the Web site is shut down, is moved and can’t be found, or is broken and there is no-one with the interest, expertise or permissions to fix it An aim of this talk is to consider ways to help your project migrate to an ongoing service, or to minimise disruption if additional funding is not forthcoming

3. 3 Contents We’ve Been Here Before Web-Based Dissemination News Feeds Standards Mirroring, Migration & Preservation Monitoring & Benchmarking Thoughts on Browsers Conclusions Web Site Dissemination Embedding Web Service You want people to know about your project – but you also want your project deliverables to be embedded within institutions

4. 4 We’ve Been Here Before Who remembers: CTI Projects CBL applications locked into obsolete hardware TLTP Projects CBL developers using Toolbook on standalone PC, which could not be deployed on campus LAN eLib Projects Web sites disappear Other issues (Stephen Pinfield’s talk) EU Programmes …

5. 5 Survey of EU Web Sites WebWatching Telematics For Libraries Project Web Sites (Fourth Framework) Exploit Interactive article published in Oct 2000 Web site availability: Server details: Apache – 41IIS – 10NCSA – 3 Netscape – 3Other – 6 (e.g. Mac, GN) See YesNeverDomainPage GoneGone 65 16 1112

6. 6 Survey of eLib Web Sites WebWatching eLib Project Web Sites Ariadne article published in Jan 2001 Of 71 Web sites, 3 domains no longer available and 2 entry points have gone LinkPopularity.com results shown: Survey also includes:  Analysis of entry points (links, HTML, accessibility)  Nos. of pages indexed by AltaVista - 0 in some cases   Due to robots.txt file  Due to frames interface or other robots barrier See SOSIG7,076 OMNI5,830 EEVL3,865 History2,605 Netskills2,363 Ariadne2,144 … xxx~10

7. 7 Web Site Promotion You want: Your quality pages to be found in a timely fashion by users of search engines To encourage others to link to you To ensure this happens you should: Have a domain and URL naming policy Exploit the Robots Exclusion Protocol Be aware of barriers to robots (which may also be barriers to humans) Think about a linking policy and procedures

8. 8 URL Naming Policy Issues: Having your own domain is a good idea (e.g. http://www.ariadne.ac.uk/ ) Short URLs are good (more memorable; search engines tend not to index deeply) Sub-domains may be a useful compromise (e.g. http://ariadne.bath.ac.uk/ ) Keep URLs short by using directory defaults: www.ariadne.ac.uk/issue5/metadata/intro.htm www.ariadne.ac.uk/issue5/metadata/ Shorter, less prone to typos and allows for format and language negotiation, new server management tools, etc …/issue5/metadata/intro.fr.html …/issue5/metadata/intro.pdf(.cfm,.asp,.jsp) www.ariadne.ac.uk/issue5/metadata/intro.htm www.ariadne.ac.uk/issue5/metadata/ Shorter, less prone to typos and allows for format and language negotiation, new server management tools, etc …/issue5/metadata/intro.fr.html …/issue5/metadata/intro.pdf(.cfm,.asp,.jsp)

9. 9 Planning Search Engine Strategy You search for your project name and find a personal page of a former colleague with informal information  To avoid this: Distinguish between (a) initial information about the project (b) information for project partners, funders, etc. and (c) information for end user Use search engine techniques to:  Ban search engines from indexing certain pages  Promote other pages as appropriate

10. 10 Robots Make use of the Robots Exclusion Protocol (REP) to ban robots from indexing : Non-public areas (e.g. area for partners) Pre-release Web sites Pages prior to an official launch Remember to switch off ban after launch! User-agent: * Disallow: /partners Disallow: /draft /robots.txt in Web root Note that use of directories to group related resources will have many benefits: controlling indexing robots, mirroring and auditing software, etc. Note:

11. 11 Other Barriers To Indexing Other barriers to indexing robots: Frames  Most search engines can’t index framesets and rely on appropriate tags Flash (and other proprietary formats)  Most search engines can’t index proprietary formats Poorly implemented JavaScript pages  Search engines may not have JavaScript interpreters and can’t index text generated by JavaScript Poorly implemented user-agent negotiation (client- or server-side)  Most search engines don’t have a Netscape or IE user- agent string and so will index “Upgrade to Netscape” Invalid HTML Pages  Search engines may not be as tolerant of HTML errors as Web browsers

12. 12 Accessibility Robots have similarities to the visually impaired Good design for robots is likely to be good design for people with disabilities (and vice versa) Make use of Bobby (both versions) to check accessibility – see You should formulate plans for making your Web site search-engines friendly and accessible

13. 13 Other Ways Of Dissemination Users find your Web site by: Search engines Following a link Entering a URL which they found on a mouse mat, pen, in an article, etc Links to your Web site are valuable as they: Drive traffic to your Web site Improve ranking in citation-based search engines such as AltaVista Possible problems with links: “Link-spamming services”  Being in the “Web sites that suck” portal Resources needed to encourage linking

14. 14 Encouraging Links You can: Submit to directories (e.g. Yahoo!) Use directory (and search engine) submission services Have clear entry points with static URLs for key menu pages Think about who you want to link to you and why they would do so Target them and think of motivation (e.g. attractive small icon) Monitor trends in links (e.g. try )

15. 15 Monitoring You may find it useful to: Monitor the status of your Web site  Nos. of pages indexed.  Nos. of links to your Web site  Accessibility of your Web site  Compliance with standards  Downtime of the service Monitor trends  Do the findings change over time / after dissemination Compare your findings with your peers  Comparison with other projects  Comparison with other institutions  Comparison with other communities

16. 16 Monitoring Many evaluation tools and Web services are available (some for free) See for exercises from Auditing and Evaluating Web Sites workshop (and new workshop next week)

17. 17 Embedding Your Service So you’ve now: Produced a high-quality Web site which is easily found, well-linked and accessible What Next? You may want institutions to install your service You may want institutions to install scripts which integrate with your service You may want institutions to install software on users’ desktop PCs Your project may simply be a proof-of-concept, and you aren’t too concerned about deployment. But what if your project is so good that others want to deploy it?

18. 18 Standards, Architectures, Applications, Resources Let’s agree on the standards and be agnostic on the applications used to implement the standards, provided services are interoperable Architectures: models for implementing systems Applications: software products used to implement systems Standards: concerned with protocols and file formats Open standards vs. Proprietary HTML / XML vs. PDF CSS / XSL vs. HTML Which standards are applicable NT / Unix File system / database application HTML tools / content management Apache / IIS FrontPage / Dreamweaver Oracle / SQLServer / MySQL ColdFusion vs ASP vs JSP Development vs. Migration costs Use of in-house expertise In-house vs. out-sourced Licensed vs. open source Resources: financial and staff costs needed to implement systems

19. 19 Barriers to Embedding In order to persuade institutions to deploy your service: You will have to convince the SysAdmin your software:  Doesn’t have security holes  Won’t degrade the performance of the service  Won’t require updates to any system libraries  Won’t require any reconfiguration of server software  Will be maintained and is adequately documented  Is worth him (usually) spending his time on the work You may have to convince the IT Service’s management You may need buy-in from the user of your service (e.g. the Library) How big a barrier do you think this will be?

20. 20 RDN-Include – A Case Study Subject gateways (such as SOSIG & EEVL) are successful but institutions: May feel they are taking users off-site May feel that they should be doing (or seen to be doing) the job locally Feel that their users will be disoriented by leaving the local look-and-feel (landscape) RDN-Include was developed: To allow institutions to provide access to RDN hubs using the institution’s own look-and-feel and URL Short paper on this work given at WWW 10. See

21. 21 RDN-Include and RDNi-Lite RDN-Include was developed: As a CGI script written in Perl Requires the institution to install the CGI Requires the RDN to update its tables RDNi-Lite was developed: To provide a lightweight alternative to RDNi To allow the service to be tried and implemented by an HTML author Implemented using JavaScript See

22. 22 It’s implemented using a single line of JavaScript

23. 23 News Feeds Providing automated news feeds which can be included in third party Web site with no manual intervention is a good way to support dissemination

24. 24 Extension to News Feeds The RDN: Wants to provide news feeds about developments by RDN hubs It’s using the RSS standard for news feeds (and XML/RDF application) A CGI-based RSS parser (and authoring tool) has been created To allow potential users to try it out easily, a JavaScript parser has also been written See Can this (slightly) heavyweight CGI solution complemented by a lightweight JavaScript solution be used within your project?

25. 25 Mirroring and Preservation Another way to embed your service remotely is for it to be mirrored: Use of Web mirroring software to install service at another location (e.g. overseas to overcome network bandwidth problems or behind a firewall) Issues about whether you are mirroring output from a service or the service itself (affected by push vs pull mode of mirroring) JISC, for example, may wish to mirror your service in order to preserve it (once funding runs out and everyone leaves) Note that you may wish to mirror only the project deliverables Web site, and not the Web site for partners or the Web site about the project – another reason for having separate Web sites

26. 26 Benchmarking You are responsible for designing architecture of your Web site and monitoring its effectiveness Certain things may be best done centrally: Ensuring compliance with contractual agreements (Web site still exists, conforms with accessibility guidelines, etc.) Benchmarks across programme in order to make comparisons, spot best practices, identify where advice & guidance is needed, etc. Not intended as league tables (projects will have different funding levels, remits, communities, levels of visibility, etc.) Plans to produce a briefing document on “Web Portal Guidelines For Programme Coordinators” for JISC (and EU?)

27. 27 Words On Browser Support The aim: Services would degrade gracefully for old browsers This has not happened  My concern - Can I make assumptions about: Frames & JavaScript support? Support for CSS (stylesheets) Browser plugins (eg Flash)? …

28. 28 Words On Browser Support Possible solutions: Design for mid-1990s Web technologies Client-side (JavaScript) user-agent sniffing Server-side (e.g. PHP, JSP, ASP) user-agent sniffing Design assuming support for current standards Should JISC aim to define minimum browser standards? Note: Design of richly functional, accessible services using flawed 1990s applications is difficult Pre 4.7 versions of Netscape are no longer supported (security concerns – see ) Netscape moving out of browser market? See Should JISC aim to define minimum browser standards? Note: Design of richly functional, accessible services using flawed 1990s applications is difficult Pre 4.7 versions of Netscape are no longer supported (security concerns – see ) Netscape moving out of browser market? See

29. 29 Conclusions To conclude: Make plans for the architecture of your Web service (URL naming, mirrorability, dissemination, etc.) at the start Monitor aspects of your Web service Design your service so that it can be embedded in other institutions (which will have different cultures, resource levels and priorities to your own) Don’t forget the people issues (liaison, listening, etc.) not covered in this talk