Best Practices For Project Web Sites Based on experiences from previous programmes

1
Best Practices For Project Web SitesBased on
experiences from previous programmes

• Brian Kelly
• UK Web Focus
• UKOLN
• University of Bath

Email B.Kelly_at_ukoln.ac.uk URL http//www.ukoln.ac.
uk/
UKOLN is supported by
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 cant 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
Contents
Web Site Dissemination

• Weve Been Here Before
• Web-Based Dissemination
• News Feeds
• Standards
• Mirroring, Migration Preservation
• Monitoring Benchmarking
• Thoughts on Browsers
• Conclusions

Embedding Web Service
You want people to know about your project but
you also want your project deliverables to be
embedded within institutions
4
Weve 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 Pinfields talk)
• EU Programmes

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 41 IIS 10 NCSA 3 Netscape
  3 Other 6 (e.g. Mac, GN)
• See lthttp//www.exploit-lib.org/issue7/webwatch/gt
  

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 lthttp//www.ariadne.ac.uk/issue26/web-watch/gt
  

SOSIG 7,076OMNI 5,830EEVL 3,865History 2,605Ne
tskills 2,363Ariadne 2,144 xxx 10
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
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.a
riadne.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/metad
ata/intro.pdf (.cfm, .asp, .jsp)
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
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!

Note
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.
11
Other Barriers To Indexing

• Other barriers to indexing robots
• Frames
• Most search engines cant index framesets and
  rely on appropriate ltNOFRAMESgt tags
• Flash (and other proprietary formats)
• Most search engines cant index proprietary
  formats
• Poorly implemented JavaScript pages
• Search engines may not have JavaScript
  interpreters and cant index text generated by
  JavaScript
• Poorly implemented user-agent negotiation
  (client-or server-side)
• Most search engines dont 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
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 lthttp//www.cast.org/bobby/gt

You should formulate plans for making your Web
site search-engines friendly and accessible
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
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
  lthttp//www.linkpopularity.com/gt)

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
Monitoring

• Many evaluation tools and Web services are
  available (some for free)

See lthttp//www.ukoln.ac.uk/web-focus/events/work
shops/pub-lib-2000/workshop/gt for exercises from
Auditing and Evaluating Web Sites workshop (and
new workshop next week)
17
Embedding Your Service

• So youve 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 arent too concerned about deployment.
But what if your project is so good that others
want to deploy it?
18
Standards, Architectures, Applications, Resources

• Lets agree on the standards and be agnostic on
  the applications used to implement the standards,
  provided services are interoperable

Architectures models for implementing systems
Standards concerned with protocols and file
formats
Which standards are applicable NT / UnixFile
system / database application HTML tools /
content management
Open standards vs. Proprietary HTML / XML vs.
PDF CSS / XSL vs. HTML
Applications software products used to implement
systems
Resources financial and staff costs needed to
implement systems
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
19
Barriers to Embedding

• In order to persuade institutions to deploy your
  service
• You will have to convince the SysAdmin your
  software
• Doesnt have security holes
• Wont degrade the performance of the service
• Wont require updates to any system libraries
• Wont 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 Services
  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
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 institutions own look-and-feel
  and URL

Short paper on this work given at WWW 10. See
lthttp//www.ukoln.ac.uk/web-focus/papers/www10/gt
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 lthttp//www.rdn.ac.uk/rdn-i/gt

22
(No Transcript)
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
Extension to News Feeds

• The RDN
• Wants to provide news feeds about developments by
  RDN hubs
• Its 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 lthttp//rssxpress.ukoln.ac.uk/gt

Can this (slightly) heavyweight CGI solution
complemented by a lightweight JavaScript solution
be used within your project?
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
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
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
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
  lthttp//home.netscape.com/cms/certinfo.htmlgt)
• Netscape moving out of browser market? See
  lthttp//browserwatch.internet.com/news/stories2001
  /news-20010606-1.htmlgt

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)
• Dont forget the people issues (liaison,
  listening, etc.) not covered in this talk