This document discusses challenges related to managing institutional websites and proposes strategies to address those challenges. It notes that websites have become a primary source of institutional information but are often poorly managed. It recommends: 1) recognizing the importance of information management; 2) distinguishing authenticated from unauthenticated data; 3) establishing the appropriate degree of centralization vs decentralization; 4) assigning clear information management responsibilities; 5) addressing technical infrastructure issues; and 6) integrating systems to support the website. The overall message is that websites require consolidated information management strategies to effectively support the institution.

1. Information Management &
The Institutional Website
Promoting & Supporting
Organisational Change
Jon Wallis
University of Wolverhampton

2. Who am I?
Wearing two hats:
University Webmaster
Responsible for
“Corporate Pages”
Co-ordination & day-to-day management
Promotion/policing of design guidelines
Senior Lecturer in Computing
Teaching
Networks, Communications & Distributed
Information Systems
Research
Information Management aspects of WWW
Search Engine Technology

3. Where is this talk coming from?
 Based on
 Three years’ experience of running a large institutional
website
 Past research into managing non-WWW information in
a distributed systems environment”
 On-going research into Information Management
aspects of Websites
 aim to survey HE and commercial organisations
 Currently work-in-progress
 Disclaimer!
 All views and opinions are mine wearing my ‘academic
hat’
 They don’t necessarily represent the official policy
or views of the University

4.  “Experimental” webserver in School of Computing,
April 1994
 Main “corporate” webserver in Computer Centre
since September 1994
 both of these were effectively “uncontrolled”
 Controlled by Marketing dept from mid-1995 until
end of 1997
 Marketing “sub-contracted” the job to me
 Technical support from Computer Centre
 Marketing dept withdrew because the Website no
longer ‘just’ marketing
 Current status of website management “in limbo”, pending
re-organisation of University IT Services
 Now appears in job description of Asst. Director of IT
Services (Standards & Developments)
A brief history of the UoW Website

5. Current Status of UoW Website
 Over 67,500 pages
 Multiple Servers
 limited at present, but very likely to increase
 Highly diverse School & Department pages
 in terms of
 Content
 Style
 Design
 Quality
 Usefulness (despite corporate rules and guidelines)
 Shipping over 700 Mb of data a day
 this may be a better indicator than mere “hits”

6. The “Web Effect”
 A “paradigmatic” shift in the nature of
information provision
 A massive rise in expectations - realistic and otherwise
 Towards the “single institutional image”
 Before the Web
 Multiple information sources producing multiple
versions of the same information, aimed at different
target “communities”
 prospective students, businesses, etc
 Information often only available on request
 e.g. staff phone numbers
 Many inadequacies in “strategic” information
management were “hidden”
 because separate individuals deal with separate
departments

7. The “Web Effect” (2)
 Since the Web
 An information “explosion”
 Information initially provided without much planning for
purpose or audience
 Information often direct conversion of existing
“physical” version
 Prospectus
 Course literature
 Telephone/e-mail listings
 The Institutional Website is a ‘single institutional
image’
 Potential for Web as primary information source
 Information transparency
 Everything is available to everyone, everywhere

8. Problems with Websites
 Reflection of internal structure
 e.g., server hierarchy (and content) structured by
School & Department
 “Internal-only” information may be visible
 Users aren’t interested in our internal structure
 What if the internal structure changes?
 changing URLs is possible but problematic
 dead-links both inside and outside
 technical system complexity
e.g., symbolic links, server redirections
 but not changing them perpetuates model of old
structure
 Function over structure?

9. Problems with Websites (2)
Poor mapping between internal structure
and user groups
e.g. entry to UoW site is currently aimed at
specific user communities:
For Prospective Students
For Current Students
For Staff
For Alumni
plus other necessary abstractions (“About
the University”, “Contact Us”, etc)

10. Problems with Websites (3)
 But we don’t have a “For Prospective Students
Department”
 We do have
 A Media & Publicity Service (Prospectus)
 An Admissions Unit
 An International Relations Office
 A Students’ Union
 10 Academic Schools etc…..
 The overall provision of information needs to be
managed - but how?
 Hope for the best? (more chaos?)
 Create a new department to do it ? (more bureaucracy?)
 Co-ordinate autonomous departments? (more bureaucracy
and chaos?)

11. Problems with Websites (4)
 Web information is different ...
 Conventional information provision is essentially
linear and structured by the provider
 Written/Printed
 Spoken
 Web information is non-linear and (despite careful
design) is effectively ‘re-structured’ by every user
 Multiple entry points
 Multiple pathways
 It therefore demands a different approach
 But how many web authors have studied hypertext
“theory”
... and can apply it?

12. Problems with Websites (5)
 Currency of information
 If it isn’t managed, how do you know?
 Move from “Last Modified” to “Valid Until” dates
 Treats information like food (“Best Before”)
 Helps promote a more active culture of maintenance
 Checking can then be automated more easily
especially if metadata is used (but that’s another talk in
itself)
 Maintainer must be identifiable and contactable
 Preferably an actual person, not just a job title
 Someone must be actually “responsible”
 The “author” may not be the “maintainer”
 No good shooting the messenger
 How often is this sort of information ever checked and
enforced?

13. Problems with Websites (6)
Search Engines and external links
Dead links often exist for long periods
First 100 or so Alta Vista “relevant” links were to
our 1996 and 1997 prospectuses
Our 1998 Prospectus isn’t even called that
it’s an “Essential Guide”, but people don’t search for
that
Some search tools now contain historic
“snapshots” of the web
Out-of-date (and therefore invalid) information may
be preserved for long-term access

14. Problems with Websites (7)
 Websites actually cost money
 This can be a revelation to management
 How do you cost a website?
 How much does it cost to author a page/site?
 How do you perform a Cost Benefit Analysis for a
website?
 What proportion of people’s jobs spent authoring?
 Should they be doing it anyway?
 What’s the most cost effective way of doing it?
 Do you know
(a) how much your website cost to create?
(b) how much it costs to run it?
(c) if it is “economically viable”?
 But what is the cost of not doing it?

15. Website Maturity Models
Based on “maturity models” of IT systems
May help to analyse, predict and plan
development
or at least identify where it all went wrong
Different models from different perspectives
Activity
functional - what’s being done?
Stakeholder
 people - who’s doing it?
Technical
systems and software - how’s it being done?

16. ‘Activity’ Model
Doing something - anything
a means to an end - getting web experience
almost anything is valid content
Doing something useful
e.g., conversion of existing literature, alternative
channel for basic information (e.g., phonebook)
Doing something professional
e.g., contributing to marketing function, supporting
traditional course delivery
Doing something new and creative
e.g., a self-contained channel for learning
based on Tom Keen, MIT

17. ‘Stakeholder’ Model
Technical
Most institutional webservers began in technical
departments
e.g., computer centres, schools of computing
Publicity/Marketing
Control ‘taken over’ by marketing or publicity
departments
Institutional prospectus and advertising
Information Provision
As many stakeholders as ‘channels of information’
Complexity of website structure tends to
approaches complexity of organisational
structure

18. ‘Technical’ Model
Single webserver
usually in central Computing Services or IT
department
Multiple servers
usually single platform (usually Unix)
Wolves only has 4 servers - some Universities
have dozens
Multiple platforms
Unix, NT, Mac - maybe others
Extra technologies
Plug-ins, SSI, PHP, JavaScript, Java, ActiveX
 Note: Technical “maturity” does not necessarily equal
desirability or manageability

19. The Need to Adopt a Consolidated
Approach to Information Management
Websites represent a massive growth in
information provision
in terms of both volume and users
Web technology enables anyone to publish
anything, leading to
unmanageable complexity
consistency and integrity problems
accessibility problems
non-interoperable systems
A Website is a major information resource and
must be managed

20. 1. Recognise the Importance
of Information
Recognise that all users - both internal and
external - can (potentially) access the
information they require directly
a process of disintermediation
problem of one source but multiple needs
Information previously thought merely
internally "useful" is now externally visible
e.g. internal phone directory updated annually, now
on-line and “real-time”
Information Audit
what information and who controls it - and at what
cost?

21. 2. Distinguish between authenticated
and unauthenticated data
Information can be published at many levels
and by many people
Some will remain under direct internal control
(and should)
Much won't (and shouldn’t)
the balance depends on other decisions
e.g., the degree of decentralisation
Who authenticates?
The author? (may not have the authority)
The provider? (may not have the expertise)
Third party? (webmaster? someone else?)

22. Example Information Categories
 Authenticated Central
 e.g. prospectus
 Authenticated Local (Departmental)
 e.g., H&S instructions, Course Regulations
 Authenticated Local (Individual, Staff)
 e.g., Module Resource pages
 Unauthenticated Local (Departmental)
 variant copies of “central” information
 Unauthenticated Local (Individual, Staff)
 e.g., staff home pages (which may be related to
official role or may not)
 Unauthenticated Local (Individual, Student)
 e.g. student home pages (which may be connected
with study or may not)
 All types of information on an "Associated
Organisation" sub-site
 e.g,. HUBS, BCS branch

23. 3. Establish Degree of Centralisation
 Locus: “Centralised” or “Decentralised”
 Control: “Autonomous” or “Restricted”
 Gives 4 main models:
1. Centralised Restricted
2. Centralised Autonomous
3. Decentralised Restricted
4. Decentralised Autonomous
Ref: Samuel Hinton, “From Home Page to Home Site”, a paper presented at WWW7 -
see: http://www.anu.edu.au/~e951611/www7/37.html
 Information should be managed as close to its source
as possible?
 Requires strong definition and co-ordination of information
strategy
 Requires local web expertise

24. Decentralisation
 Some sort of decentralised model is most likely
 fully centralised would be utterly impractical
 Raises issues of
 control
 how to enforce corporate policies
academic institutions are notorious for autonomy
 integrity
 how to ensure consistent information
e.g.,local copies of corporate data
 security
 who is authorised to edit documents
 technology
 system integration and accessibility

25. Is it Internal or External?
 The temptation was (is?) to put everything on the web
 simply because you can (not a good reason)
 Not everything is fit for public consumption
 Some information is merely irrelevant
 use of fire extinguishers
 Some information may be confidential
 minutes of meetings
 Some information may be downright embarrassing
 internal reports about departmental inefficiency
 Need for split into “Internet” and “intranet” websites
 This requires you to know what information you have, who
provides it and who wants it - need for an “audit”

26. Development of Multiple Websites
 External-facing
 For Visitors
 General information
 For Prospective Students
 Prospectuses, local information
 Internal-facing
 For Existing Students
 Course materials, regulations, results
 For Staff
 Administrative information, procedures
 Technically possible to “filter” some users at point
of access
 IP “masks” for known groups
 staff, students, etc

27. 4. Assign Information Management
Responsibilities
 Is there an existing system?
 e.g., ISO 9000 (BS5750) procedures
 Central co-ordination and control
 Planning overall information resources
 e.g., organisational data model
 formulating policies (security, access, etc)
 How much does it actually do (versus just co-ordinate)
 More autonomy at local level = more control at the centre
 Local management and enactment
 Defining, providing & maintaining information
 Ensuring compliance with central policies (e.g. security, style)
 Identifying changes in requirements and practices

28. 5. Technical Infrastructure (TI) Issues
 The Web adds a layer on top of existing TI
 Unifying shell or wrapper over heterogeneous TI.
 Can help remove problems - but can add them too
 All requires additional resources and management
 Need to maintain underlying systems remains
 But use of Web may show need to consolidate them
 Danger of uncontrolled local technical developments
 The “weeds taking over the garden” (James Martin)
 e.g., browser-specific resources, plug-ins, etc
 Is the required client technology widespread?
 Core TP systems will remain (e.g.,finance, records),
 but the Web can simplify access to them
 Subsidiary system elements may still required to meet
specific local needs

29. 6. System Integration Issues
 Institutions will already have multiple systems
 Proprietary/commercial and bespoke in-house
 “Enterprise-wide” and local
 What are the available interfaces?
 ODBC, DCOM, ActiveX, Java-based ...
 How mature and stable are the ‘standards’?
 Where does the integration occur?
 Before the server?
 some sort of middleware
 At the server?
 built-in/add-on interfaces or CGI
 At the client?
 Java or ActiveX ... or something else
 Enforcement of standards?

30. Who runs your website?
 Which department?
 Computer Centre/IT Services department?
 Because it’s technical
 Marketing, Publicity or Media department?
 Because it’s “public-facing”
 Registry (or equivalent)
 Because it’s a major data resource
 Staffing
 “Webmaster” - historically technically-based
 A dedicated multi-skilled team?
 High-level involvement
 Both corporately and departmentally
 Often little understanding of the issues
 Design and Technical
 Usually inadequate resource allocation and timescales

31. Case Study 1
Media and Publicity Services
 A “traditional” marketing department
 Responsible for
 Prospectus and corporate advertising
 Press relationships
 Took over control of website at early stage
 Commissioned first web-based prospectus
 Relinquished control of website
 Because no extra funding available for the extra work
 But actively involved in developing content
 Aim of databased information sources - currently heavily
reliant on manual intervention
 No specific web related posts
 but Web awareness now a short-listing criterion

32. Case Study 1
Media and Publicity Services
 Web seen as a “central tool”
 but other channels remain key (e.g. hard copy)
 ironically, production of printed media likely to increase as
result of web originated requests
 Web initially seen as marketing “dream”
 24 hrs, global, always current, local production costs
 Cost of producing web material became a barrier
 Conventional media now points to web resources
 increased expectations of what is available
 Email direct from web pages “opens up” institution
 Not keen on “policing” content of entire site
 Many “rogue” pages not widely seen anyway

33. Case Study 2
The Registry Intranet
 Began as a small “proof-of-concept” project
 A demonstrator to provide (limited) central information
 e.g. exam and teaching timetables
 An “administration server”
 accessed by simply typing “admin” into browser
 Once people saw what was possible…..
 Requests to provide information on others’ behalf
 Spawned other departmental intranet servers
 The information is all there
 Making it available is technically easy
 But it takes time, needs staff (and costs money)
 Very successful
 But not yet “strategic” - still a “local” initiative

34. Case Study 3
Student Information Project
 University-wide initiative
 Not Website specific
 But the Website highlights issues of provision
 Major questions
 What information do we provide to students?
 What information should we provide?
 How should we provide it?
 Student life-cycle perspective
 “Horizontal” rather than “vertical” division
 Integrates across internal boundaries (like the web?)
 Avoids imposition of internal structures on students
 Students still want hard-copy information