Developing and Maintaining Decentralized Webs
A Tutorial presented at the Fourth International World Wide Web Conference
Katie Scheding,
Multimedia Developer
Kelly Stack,
Information Literacy Specialist
Kent Wada, Coordinator, Advanced
Workstation Program
UCLA Office
of Academic Computing and the
InfoUCLA Team
- Abstract
- Introduction
- Data Analysis - The Web Foundation
- Role Assignment - Lining up Personnel Resources
- Web Design - The UCLA Model
- Final Thoughts
- References
As more and more people become interested in the Web beyond mere browsing,
Web sites spring up throughout an organization, often before a plan is
formulated at the central level. This situation creates the opportunity to
employ a decentralized data model for web design. In this tutorial, we will
dissect and analyze the UCLA approach to decentralized web development and
management.
Data analysis is the heart of good web building, and we will discuss that
first, presenting you with the tools you need to analyze your organization's
data. (This crucial step may be performed retroactively if webs are already in
place.) Because personnel costs are the highest proportion of any web project
budget, we will address the skills, knowledge, authority, and lines of
communication between personnel needed to create and maintain the decentralized
web. Using the UCLA web as a case study, we will then present our findings on
optimal web structure, interdepartmental coordination of web design, and some
potentially surprising conclusions regarding organization of individual webs
within a decentralized web system. Finally, we will offer some thoughts on
various more nebulous aspects of web design and maintenance, issues we haven't
quite solved ourselves, and ruminations on the future of electronic publishing.
Level Setting: This is not a course in HTML, CGI
programming, or web building tools and utilities. Participants should
already possess a general understanding of web design and management. This
tutorial is designed explicitly to address decentralized, distributed webs.
Although we recognize the validity of a centralized web model, people
wishing to learn about centralized webs would not be well-served by this
tutorial.
[Return to Table of Contents]
Centralized vs. Decentralized Data Models
The Centralized Data Model (shown below) seems "efficient."
Information can be organized from a global point of view, a consistent look and
feel can be achieved, and a single central mechanism exists to handle and
respond to feedback.
This data model works well for small organizations and for business with an
organizational culture that lends itself to centralized structure. If this is
true of your organization, you should probably take a different tutorial!
But operating under the centralized data model may engender the following
problems:
- It takes too long for information to be updated.
- Inaccuracies are introduced due to the distance between the source of the
data and its final publication.
- Creativity is stifled by centralized control.
- Feedback from data users to the central publishing body is not
redistributed to the data sources where it is needed.
If these issues are of concern, or if your organization is already
decentralized, a distributed data model will be of interest.
A distributed data model may appear "inefficient." It requires
more people to be trained to publish information and requires continuing
self-coordination among all information sources if it is to be successful. But
it enriches information presentation through timeliness, accuracy, diversity,
and it can enhance overall business operations through increased communication
across departments.
In order to make it work, the following issues must be addressed in a
distributed data model:
- Because data is published at the departmental level, there is a tendency
for each department to focus on its own constituency without regard to other
potential audiences.
- Individual departments often have difficulty in seeing the "big
picture" and therefore may duplicate pre-existing data or data already
under development elsewhere, and neglect to provide needed data.
- The compilation of data from several departments may present the end user
with a confusing patchwork.
- Departments have a tendency to structure data organizationally rather than
by subject.
- User feedback and queries may be misdirected and lost.
The UCLA Approach
In this tutorial, we will dissect and analyze the UCLA approach to
decentralized web development and management.
- Data Analysis -- the heart of good web building
- tools to analyze your organization's data
- Roles Assignment
- skills, knowledge, authority, and lines of communication between personnel
necessary for creating and maintaining the decentralized web
- Web Design
- optimal web structure, interdepartmental coordination of web design, and
some potentially surprising conclusions regarding organization of individual
webs within a decentralized web system
- Final Thoughts
- various more nebulous aspects of web design and maintenance, issues we
haven't quite solved ourselves, and ruminations on the future of electronic
publishing
[Return to Table of Contents]
A comprehensive data analysis is the foundation for any successful web. We
have found that once you have a thorough understanding of your data, the
decisions you need to make to implement your web become almost automatic.
First, divide the data into its component parts. If the data is a document,
an initial pass may be as simple as listing the titles from the table of
contents.
Your initial question when looking at the data is:
- What is the value of publishing this data on the web?
Next, ask the following questions about each part of the data:
- What medium is the data currently published in, if any?
- What is the primary audience for this data?
- Is this data critical to its primary audience?
- What is the secondary audience for this data?
- Is this data critical to its secondary audience?
- Is this data of interest internally, externally, or both?
- Is this data sensitive (e.g., should it be restricted to a specific group
or are there special legal restrictions on how this data may be disseminated)?
- What is the source for this data?
- Does the data change never, rarely, or more often? Is it important to have
a single unchanging master version?
- What type of indexing is appropriate for this data, if any?
The following matrix can help you to analyze your data:
This analysis will help you to determine:
- Whether or not this data should be published on the web at all.
- Whether or not the data must be converted from a pre-existing source.
- In general, data should not be maintained in more than a single format
(i.e., word processed, marked up in HTML, etc.). If this cannot be avoided,
conversion between formats must be carefully planned so that it becomes as
automatic as possible. This may entail redesign of the original document in
order to more easily accommodate HTML markup.
- When the data in question is complex, mission critical, lengthy, and
requires regular updates, SGML can be a good choice for formatting the master
document because of its power and flexibility. If data does not meet these
criteria or if the resources do not exist to mark up in SGML, another format
must be chosen for the authoritative source document. Because of its limited
structuring capabilities, HTML is usually not a good solution, especially when
the data in question must be published in print as well as on the web.
- Whether or not the data should be distributed.
- If multiple sources and audiences exist for a set of data, the data should
probably be distributed.
- The web site for the data.
- Usually the data source, although data that never or rarely changes may
reside at a site other than the source.
- The format for the data.
- If data is critical to the primary or secondary audience, you must make
accessibility by those audiences a top priority.
- If data is of interest externally, it may need to be presented differently
from data that is only of interest internally.
- If data is sensitive, it may need to be protected by password, IP address
or other means; some data may be inappropriate for web publishing altogether
regardless of access controls.
- How the data will be indexed or structured for access to internal
components.
- The impact on current computer operations.
Demonstration:
We will go through an example data analysis in class.
In Class Exercise:
In small groups, students will analyze a data set of their own choosing,
preferably one from someone's own organization.
[Return to Table of Contents]
There are seven major roles associated with web construction. Each role may
be performed by a single person or a team, and a single person or team may
perform more than one of these roles. The exact distribution of roles to
personnel depends on the array of resources brought to bear by the people
involved and the structure of the organization.
- Data Source
- The person or team who is the source of the data; usually best if this is
the same person or team who authors the data.
- Training: no additional training required
- Authority: must be authoritative on the content of the data
- Communication: if not the author, must be able to communicate
updated information to the author in a timely and efficient manner; meetings as
needed with others
- Author
- The person or team who composes the page; usually best if this is the same
person or team as the source of the data. In coordination with the Interface
Designer, conceptualizes the overall page design.
- Training: understanding of basic HTML, hypertext, and multimedia
concepts, complete understanding of subject area
- Authority: if not source of data, must be able to obtain source
data on demand
- Communication: frequent meetings with other authors and the
Interface Designer; meetings as needed with others
- Interface Designer
- The person or team who designs the layout and structure/formatting of the
page. In coordination with the Author, conceptualizes the overall page design.
- Training: basic HTML, multimedia design, human-machine interface
design
- Authority: no special authority needed
- Communication: meetings as needed
- Programmer
- The person or team who marks up the page in HTML, creates or manipulates
graphics, audio and video files, and writes CGI scripts. Usually the same team
or person as the Web Administrator.
- Training: advanced understanding of HTML and Web conventions,
multimedia file manipulation, and CGI programming
- Authority: no special authority needed
- Communication: meetings as needed
- Reviewer/Editor
- The person or team who reviews the page for content and/or style within the
context of the entire web, and gives approval for the page to be published.
This person or team may also be called on to make an explicit declaration that
the data is the sole official version for legal purposes where needed.
- Training: comprehensive overview-level understanding of web
subject area
- Authority: authorized to approve web publications
- Communication: regular meetings with all teams
- Feedback Monitor ("webmaster")
- The person or team who monitors feedback directed to the webmaster;
depending on the prominence of the page, this task may consume a substantial
portion of an FTE.
- Training: good overview-level understanding of web subject area
and basic understanding of web structure
- Authority: authorized to call on team of subject area
specialists for help in answering queries
- Communication: provides feedback to appropriate other teams
based on queries/comments directed to webmaster
- Web Administrator
- The person or team who is responsible for keeping the web hardware and
software maintained and up-to-date. Usually the same team or person as the
Programmer.
- Training: comprehensive understanding of web hardware and
software
- Authority: decisions about web hardware and software acquisition
- Communication: meetings as needed
Often these roles are performed by the same person, especially when the web
in question consists of only a few pages. The important thing to do is decide
which people within your organization will fulfill these roles, and determine
whether or not they have the training, level of authority, and lines of
communication to carry out their duties effectively.
The following chart illustrates the interaction of the web development and
maintenance process with the people who do the work:
The duties of most of these roles are self-evident, but we have found that
the role of Feedback Monitor is one of the more difficult roles to fill in a
decentralized environment. Email addressed to "webmaster" is
traditionally expected to contain comments about the web such as requests to add
links, but in fact such email may contain a wide range of comments and requests
that have nothing to do with the web. At UCLA, email addressed to webmaster
ranges from requests for the email address of a student identified only by first
name and possible major, to requests for a wide range of materials to be sent
via regular mail, to comments on the quality of non-web-related programs, and so
forth. Thus the webmaster is evolving into an important public relations entity
for the organization and a valuable source of feedback from the public to
various entities within the organization.
Email addressed to webadmin (or webmaster) at the top level of the UCLA Web
is sent to a central triage person, who has the ability to call upon a team of
subject area specialists in order to respond to mail:
Email addressed to webadmin at secondary levels of the UCLA Web is sent to a
triage team rather than to a single person. The team receives all email and
responds to it, as shown in the following diagram:
[Return to Table of Contents]
The UCLA Model integrates webs that contain multiple decentralized web
servers into an apparent unified whole. The elements of the UCLA Model are:
- multiple peer home pages
- subject-oriented top and second level pages
- interdepartmental team management of second level pages
- organizationally-oriented departmental level pages managed by individual
departments
When it is fully implemented, the outward-facing page of the UCLA web will
have the www.ucla.edu address. This page will be aimed at prospective students
and their families, visitors, and potential funders. This is not what we
consider to be the only UCLA Home Page, however. Because we recognize that
there are many audiences for UCLA data, both internal and external, we have
designed a variety of "peer home pages" to suit their needs. For
example, we anticipate that enrolled students will make either the Student
Information Web (http://www.ucla.edu/student/) or the Library Web
(http://library.ucla.edu/) their home page. Staff, on the other hand, will tend
to use pages that offer more administrative information as their home pages.
In designing the subject-oriented, top level web pages at UCLA, we observe
the following principles:
- focus on web structure first, appearance last
- build consensus among departments
- keep the end user point of view in mind
Our practice in developing the top level subject-oriented parts of the UCLA
Web is to put together teams made up of representatives from the departments
that hold source data for a particular data set. These working groups meet
regularly and intensively over a 3- to 6-month period during the initial design
phase of the web. After the content and structure are finalized and
implemented, a graphic designer is brought into the process to design the
interface. Finally the web is presented to senior management from within the
participating departments for review, revision and approval.
The Development of the Top Level UCLA Web - A Case Study
UCLA Web
- Context
- Initially UCLA Home Page was a proof of concept
- InfoUCLA is a comprehensive CWIS, including but not limited to the web,
with official funding and an interdepartmental team
- For more background information, read
The InfoUCLA Story
- Current UCLA Web designed by interdepartmental team of four; an offshoot of
InfoUCLA
- Top level categories which became Peer Home Pages chosen by these criteria:
- keep the number of categories to a minimum
- keep categories static
- make categories distributable
- Structure developed by organizing representative data from top level
categories to leaf nodes
- Appearance was a later consideration, in part because outward-facing page
was yet to be designed
- Review by community, including campus-wide vote on choice of graphical
interface
- Created Campus Web Publishers group to create a channel of communication
and build community among campus web publishers
- Spinning off Peer Home Pages working groups (e.g., Student Information)
Student Information Web
- With an InfoUCLA team member as facilitator, gathered together
semi-grassroots-level representatives from relevant departments.
Representatives did not have to have expertise in HTML, but did need
to have good understanding of the student services provided by their department.
- Brainstormed content - included everything, not just
electronically-available data.
- Categorized content - emphasizing compromise, consensus, and design from
the student's point of view.
- Assign categories to team members.
- Create category-level pages, begin review/revise cycle of several weeks in
duration. Important that category-level pages not be departmental home pages.
- Appearance and Acknowledgements.
- Review by senior management, working together as a team in order to
encourage cooperation and compromise.
- Design and pilot test system and procedures for continued distributed
maintenance.
- Create and sign off on inter-departmental contract for ongoing maintenance.
The Development of a UCLA Departmental Web - A Case Study
Context: Three of the four divisions within the Office of Academic Computing
(OAC) have existing Webs, which cover divisional information.
Initial directive: Create an OAC web which encompasses all of the divisional
webs, and as a secondary concern, conserve resources (people and hardware)
within the department. A division of OAC, the
Academic Technology Center (ATC)
prototyped an initial OAC web which was a single page with descriptions of the
divisional functions and links to their corresponding pages (those that
existed).
Data Analysis
A group was formed with representatives from each division to develop a more
complete OAC web. This group identified the primary audience as people browsing
or exploring the OAC web in search of general computing information. The
secondary audience was identified as people who knew which division in OAC they
needed to get to. Based on these assumptions, the OAC web was organized
primarily by topic or subject, and secondarily by organizational divisions.
In order to develop the topic pages, each division produced a list
of topics it was most suitable to provide on the Web. These topics were narrowed
and refined into six main topic pages and additional major links to other areas
that involved OAC. The topic pages were to be provided at a central
level by the ATC team, and they would in turn point to the other OAC resources
on the web (the divisional webs). This followed the prevailing campus model of
subject-oriented webs providing an overview and structure for the organizational
webs underneath them.
Role Assignment
Roles were assigned for the process of developing and maintaining these
topic pages and the corresponding divisional pages connected to them. The
responsibilities assigned for the OAC web fit loosely into the categories set
forth by this tutorial.
- Data Source
- Each division provided what was appropriate.
- Author
- Each division provided what was appropriate. Divisions with little or no
web experience leveraged the resources of the ATC.
- Interface Designer
- The ATC team, except for pages that were both OAC web pages and parts of
the InfoUCLA process.
- Programmer
- The ATC team.
- Reviewer/Editor
- This role was largely unidentified within the OAC structure, and
consequently brought up many points of contention. Although the OAC web
development group set forth some guidelines, no authority was given to implement
them.
- Feedback Monitor ("webmaster")
- The ATC team.
- Web Administrator
- Katie Scheding.
Web Design
Once the InfoUCLA team completed the Computing and Communications Page, the
OAC analysis of the primary audience was no longer valid. People who wanted to
browse for information based on subject were more likely to want to the entire
campus' view of computing, rather than that of a single department. The OAC Web
moved away from subject-oriented pages and instead primarily focused on an
organizational structure for most information. Users interested in browsing by
subject are encouraged to do so at the Computing and Communications Page level,
which represents the various divisions within OAC wherever their information is
most appropriate.
Conclusion
The most interesting point about the OAC web is that it has come full circle
from an initial prototype based on an organizational model, to a completely
subject oriented web and back. It shows a natural evolution for webs; attempting
to provide everything initially, then moving to provide what is most appropriate
or locally owned as other webs evolve and fill the gaps.
[Return to Table of Contents]
Creating and maintaining an effective webspace for your organization
requires a significant investment in time, people, equipment, and financial
resources. If it is to be successful in the long term, it must be fully
integrated as part of the business process of your organization. But what does
this mean? You will need to consider:
- cultural changes and perceptions about electronic publishing:
- how the organization needs to adapt to include this new medium
- how to do so without unnecessary disruption (planning, maintenance,
etc.)
- the fact the Web is only the latest Internet "hotspot": as other
hot technologies spring up, how will you protect the investment you have made in
the Web?
- integration with existing business process
- resources
- planning
- process for maintenance
- how to define a set of criteria to evaluate whether your Web is
effective (i.e. how to define what "effective" means for your Web)
[Return to Table of Contents]
[Return to Table of Contents]
Last updated and validated 26 October 1995
