|
Building a local CMS at Kent State |
|
Subjects: |
Studies, Content
management software, Academic libraries, Computer
architecture, Metadata |
|
Classification
Codes |
9130, 8306, 5200, 9190 |
|
Locations: |
United
States--US |
|
Companies: |
Kent
State University (NAICS: 611310 ) |
|
Author(s): |
Rick
Wiggins, Jeph Remley, Tom Klingler |
|
Document
types: |
Feature |
|
Document
features: |
Diagrams, Illustrations, References |
|
Section: |
THEME ARTICLE |
|
Publication
title: |
Library
Hi Tech. Bradford: 2006. Vol. 24, Iss.
1; pg. 69, 33 pgs |
|
Source
type: |
Periodical |
|
ISSN: |
07378831 |
|
ProQuest
document ID: |
1028737551 |
|
Text
Word Count |
10625 |
|
Document
URL: |
http://proquest.umi.com/pqdweb?did=1028737551&Fmt=4&clientId=2335&RQT=309&VName=PQD |
|
Abstract (Document Summary) |
|
The purpose of
this paper is to describe the creation of a content management system (CMS)
for the Kent State University Libraries & Media Services Web site. It
describes the requirements for the site and for the CMS, the CMS architecture
and components. This paper describes the genesis and architecture of a
locally-written CMS that is strongly focused on metadata. A review of local,
library-specific needs combined with a review of the product universe
resulted in the decision to write a local CMS. |
|
Full Text (10625 words) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Copyright Emerald Group Publishing, Limited 2006
Background The first
generation Kent State University Libraries & Media Services (LMS) web
site was a small accumulation of static pages. The second generation site, in
place from the late 1990s through the early 2000s, responded annually to
millions of page requests. In the early 2000s, the web team, a subset of the
systems department staff, began to realize that the site had a long way to go
in terms of data consistency, presentation consistency, and automation. The
team began to hatch the idea to build a new, fully-automated site. A better
site needed better control over presentation to achieve a more professional,
consistent look. Better control over staff data input would eliminate poor
quality HTML. A better site required optimized management of data that tended
to appear in multiple places in various stages of currency. And, a top need
was better content description for more flexible retrieval and presentation.
Feeling that metadata was driving the future of the web, the team knew that
it needed to build a site that exploited metadata for the organization and
retrieval of both research data and basic operational library content. Each page on the
second generation site was made up primarily of static HTML pages coded in
Macromedia's Dreamweaver. Content providers for the site were a small (but
growing) number of LMS staff members with varying levels of HTML experience.
To create a new page, a staff member would typically copy an existing page,
save it as a new page, delete the content of the former page, and then create
their new content. Staff who did not know how to edit web pages would send
their edits to staff members with more experience (typically the site's
webmaster). With the number
of staff content providers on the site growing, most of whom had only a basic
understanding of HTML, the integrity of the site's overall look and feel
started to degrade. The site was formed with a series of nested tables, with
many layers of tables for overall page layout, navigation options, and other
components like page headers, content areas, and footer. The problem with the
practice of copying existing pages was that, in deleting areas of the former
page's content before entering the new content, the author would often delete
too much code, or not enough, which would result in a broken page layout of
broken tables. Many times the staff did not know how to fix it, or did not
pay any attention, and so the errors were left in place. Over time the pages
on the site that were supposed to have a consistent structure actually
started to look more and more different. For example, the footers began to
stretch over different areas of the bottom of the pages, and the site logo in
the upper right hand corner of the pages began to shift position from one
page to the next. The team clearly had a fundamental problem with the
structure and the editing process for the site. In addition to
accidentally breaking a page's layout, some staff started to go their own way
with their pages. Some altered page layouts by removing or changing the
navigation bar that was supposed to be consistent on all pages; others
changed font faces and colors, bringing a whole new level of undesired
"creativity" to the site. With different staff straying from the
original design, the LMS web site started to look less consistent and less
professional. Another problem
inherent to a site full of static web pages was the need to make site-wide
updates. There were times when a new item needed to be added to the
navigation sidebar, or the contents of the footer needed to be updated. There
were times when an update was needed to the overall look and layout of the
site to bring it back to a more consistent structure. Attempts to perform
site-wide find-and-replace code corrections were difficult or impossible
because staff had made changes to the code, sometimes intentionally,
sometimes accidentally. An attempt at a global update to the code would
reveal that many pages would still have to be individually updated. And, even
this approach assumed that these pages could be located by clicking through
the site and randomly coming across the errors. Sometimes a page's code did
not get updated as intended, continuing to break the integrity of the site.
All of these problems provided more evidence of the site's fundamental
structural problems. The team also
discovered hundreds of stray and duplicate pages; pages that were considered
"deleted" just because there were no known links to them; pages
that were older versions of a current page; entire directories with no known
links into them; duplication of data on different pages, sometimes with one
instance of the data being current and the duplicate out of date. It was
clearly time to plan a new site that would be built and managed by a new
method. Beginning to
plan At the start of
planning for the new site, a web committee of LMS employees was formed,
composed of interested staff members from various departments. The committee
decided the site should be recreated from scratch, content should be easier
to publish, and the site should be easier to maintain and update. It quickly
became apparent that the new site also had to offer improved features. The
committee very much wanted the new site to be based on the needs and feedback
of our users - the students, faculty and staff. It was widely felt that the
old site was built by librarians for users who, to navigate the site
successfully, would have to think like librarians. One of the first
important steps with the new web committee was to meet with focus groups and
conduct usability studies to find out what they did and did not like about
the existing site, how they used it, how difficult the site was for them to
use, and what they wanted in a new site. Rather than restricting what types
of users should be listened to, the committee ensured that the focus groups
were a mix of students, faculty and student library employees. After
completing release forms, the participants were asked questions about the
current site, were asked to compare it to other sites, and were allowed to
offer any concerns and requests that had not already been considered.
Participants in the focus groups were fed pizza and soda, and were given $15
each on their university ID spending account. Usability studies were
conducted as well, with individual participants completing assigned tasks
using the current site, and speaking aloud whatever thoughts or problems they
might be experiencing. Usability study participants were also each given $15
on their accounts. The pizza and money turned out to be just the right
enticement; just the right number of participants were involved, and they
were genuinely interested in helping the committee work towards a new and
better site. General goals
and requirements In order to
improve the usability and ease-of-maintenance of the new web site, the team
established a set of general goals for the new site. This list of goals
became the foundation on which were built the more detailed requirements for
the site and for a CMS that would be used to manage it. Edit content
using web forms Instead of using
web content editing software like Dreamweaver or BBEdit, the staff would do
all editing in the CMS using web forms. This approach would reduce the need
for special software purchases, installation, and training. Staff would be
able to edit web content from anywhere they could access the CMS with a
browser. In order to allow for what-you- see-is-what-you-get (WYSIWYG)
editing, special software would be purchased and installed into the CMS to
provide this functionality in a web browser. But, in order to maintain a
clean separation of the content from the presentation of the pages, many of
the typical HTML features that people would expect in such a tool would not
be made available. For example, the selection of fonts, font colors, and font
sizes would not be made available. More radical, the typical HTML table
editing tool available in web content editing software packages would not be
made available. This decision would prevent the use of tables for layout,
making the web site more ADA-compliant. Staff would not
need to know how to write HTML to edit content and would not be given the
ability to write raw HTML. The CMS and WYSIWYG editor would allow them to
create content without ever seeing the underlying HTML being generated. The
creation of the HTML would be done dynamically and would rely heavily on the
use of Cascading Style Sheets (CSS) for the description of the presentation. Organize pages
using metadata The traditional
hierarchical organization of the earlier sites now seemed too arbitrary and
inflexible. In time, any newly-invented hierarchy would no longer make sense,
but would be deeply embedded into the structure of the web site, making
widespread changes problematic. Instead, the team wanted to use metadata to
organize the pages on the new site. By allowing the staff to add classification
terms to the pages they created, the team could create dynamic indexes of
page links, provide a more focused search capability, and easily generate a
site index. This approach would allow patrons to use various methods of
locating content. To provide a rich enough set of terms, the team worked with
the web committee and the catalog and metadata librarian to create a
controlled vocabulary of functional terms - those related to library
functions, e.g. overdue fines. Additionally, they agreed to allow the use of
Library of Congress Subject Headings (LCSH). While LCSH terms would be more
useful for pages like subject guides, they would also be available for use
with any page. For more specific groupings of pages, a set of uncontrolled
"special" terms could be added to any page. In all, then, three
types of metadata were defined: functional terms, LCSH terms, and special
terms. This classifying
of pages would also support a metadata search of the site. While many sites
provide a keyword search, the committee felt that a metadata search would
produce better results, since these terms are specifically selected by the
library professionals to describe the content of the page. The use of
controlled vocabularies also would allow for the display of a dynamically-generated
site index. Each functional term and LCSH term in use would be displayed in
the site index with a list of all pages that had been classified with that
term. Store tabular
information in database tables In order to
provide a single location for common information, e.g. library hours, it was
agreed that all tabular information would be stored in actual database
tables. This information would be made available for display on any page in
the web site. The CMS would allow for the creation of new database tables,
the addition of new table fields, and the editing of table data. Within a page,
the CMS would allow a staff member to specify which table to use, which
fields (columns) to display, and which records (rows) to include. Using this
technique, a staff member would be able to create a table of information
without the use of an HTML table editing tool. Again, keeping an HTML table
editing tool out of the hands of a wide variety of staff would prevent
inconsistent looking pages and pages with broken formatting caused by broken
tables. Make the web
site able to be indexed by spiders The web pages
created using the CMS would be dynamically generated and would not have a
hierarchical directory and filename structure. In order to make these pages
able to be indexed by spiders, e.g. Google, the URL used for displaying
content could not include parametric information. Create draft
copies of pages for editing Staff would
create draft copies of pages when editing. This workflow would allow
previewing of draft page content via the intranet before the draft was
published to the public web site. Staff would be responsible for their
content and would not require any approval before publishing their content,
but could ask their colleagues to review their content before publishing it. CMS requirements Initially, the
team had hoped to identify a commercial or open source CMS that could be used
for the new site. As this section will show, the team specified its
requirements for such a product, reviewed quite a few of them, and eventually
reached the difficult realization that only a locally-written CMS could come
close to satisfying all the goals and requirements. The general
requirements for the CMS fall into five basic areas: (1) Content
creation: * Integrated
authoring environment: does the tool provide the ability to create all of the
types of content needed? * Separation of
content and presentation: is the content created independent of the
presentation? * Multi-user
authoring: can many users be editing content simultaneously without
overwriting each others' work? * Content
re-use: can a single copy of an item of information be displayed in multiple
locations with different views? * Metadata and
cataloging information creation: can metadata and cataloging information be
created and maintained for indexes, searching, and site mapping? * Link
management: does the system prevent internal links from breaking? * Non-technical
authoring: can content providers create content without knowing HTML? * Ease-of-use:
is the user interface intuitive and ease to learn? (2) Content
management * Version
control and archiving: does the tool allow previewing of new content and
roll-back to previously-published content? * Workflow: can
default editing permissions be set on a group level, and is there an approval
mechanism for approving changes to content? * Security: will
the tool integrate into the existing local security infrastructure? * Integrated
with external systems: will the tool work together with other existing
systems? * Reporting:
does the tool provide an extensive set of reports - both retrospective and
pro-active - and allow for customized report creation? (3) Publishing: * Stylesheets:
is the final appearance of the content controlled through stylesheets? * Page
templates: is the overall page layout controlled by templates, and can new
templates be easily added? * Extensibility:
is there a method to incorporate non-CMS managed content into the web site? * Support for
multiple formats: can the tool publish content in multiple formats, e.g.
HTML, PDF, WAP, etc.? *
Personalization: does the tool allow for presentation based on user profiles
or user preferences? * Usage
statistics: does the tool provide reporting on page hits, most popular pages,
daily usage, and search terms being used? (4)
Presentation: * Usability: is
the presented content easy to understand and use? * Accessibility:
does the presented content conform to the W3C web accessibility initiative? * Cross-browser
support: is the presented content viewable with all popular browsers on all
popular platforms? * Limited
client-side functionality: does the presented content require additional
client-side technology, e.g. Java, JavaScript, or Flash, to work properly? * Speed: is the
content presented with a minimal page size to make page loading quick? * Valid HTML:
does presented content conform to the current HTML specification? * Effective
navigation: does the presented content include consistent, comprehensive and
usable navigation aids? * Metadata: does
the presented content contain sufficient metadata to allow effective indexing
and searching? * Search engine
access: are the site pages accessible to spiders and crawlers so that the
site will be indexed by engines like Google? (5) Contract and
business: * Training: does
the vendor provide training materials for both the administration and use of
the CMS? * Documentation:
is there adequate documentation of the CMS for users, administrators, and
developers? * Warranty: what
is the warranty period for the product? * Maintenance
agreements: what maintenance options are available and at what cost? * Resources
required: does the product require hardware or software resources which LMS
does not currently have or could not easily acquire? * Skills
required: does the product require employee skills which LMS staff do not
currently have or could not easily acquire? * Cost: is the
cost of the product fixed or per-seat? Is it within reach? * Scalability:
how well will the product scale without requiring the acquisition of
additional hardware or software? * Reference
sites: what other sites are successfully using the product? CMS product
review To begin the
product review, the team established a simple spreadsheet matrix with
requirements along one axis and products along the other. Team members were
each assigned a group of products to research. Then, the review content was
merged and several meetings were dedicated to reviewing the results. Lists and
reviews The review of
potential CMS products was helped by these comprehensive CMS product listing
and review sites: * List of CMS at
Wikipedia - http://en.wikipedia.org/wiki/List_of_Content_
Management_Systems * CMS Watch
Vendor List - www.cmswatch.com/CMS/Vendors/ * The OSCOM CMS
Matrix -www.oscom.org/matrix/index.html * CMS Ratings at
opensourceCMS - http://opensourcecms.com/index.phpPoption
=content&task=view&id=388&Itemid=143 * CMS Review - www.cmsreview.com * Overviews of
CMS products at Hartman Communicatie BV - www.hartmancommunicatie.nl/extra/tools.htm; http://tools.hartman-communicatie.nl/overzicht.html Sample products Listed here is a
sampling of products that received some consideration. This list is not meant
to be exhaustive or evaluative, but to show the breadth of products and
environments that were considered. * Apache Lenya -
http://cocoon.apache.org/lenya/ - an open
source CMS. * Bricolage - www.bricolage.ee/
- an open source CMS. * Drupal - www.drupal.org/
- an open source CMS. * IVia - http://infomine.ucr.edu/iVia/
- an "open source internet portal and virtual library system". * Midgard - www.midgard-project.org/ - an open source
CMS. * OpenACS - http://openacs.org/
- an open source web site tool kit. * PhpWebSite - http://phpwebsite.appstate.edu/ - an open
source CMS. * Typo3 - http://typo3.org/about/typo3/
- an open source web content management framework. * WebldeaTree - www.webideatree.com/
- a commercial CMS. * Zope - http://www.zope.org/
- an application server environment for building a tool like a CMS. Promising new projects
and products Well after the
project was underway and the local CMS was nearly finished, the team
discovered these projects/products of interest. The team has not evaluated
them thoroughly but encourages anyone starting a product review to add them
to their list of products to review. * LibData - http://libdata.sourceforge.net/ - an open
source CMS from The University of Minnesota. * HyperContent -
http://hypercontent.sourceforge.net/ - an
open source CMS from Columbia University. * Caravel - www.caravelcms.org/
- an interesting new open source CMS. The final
deasion The team
realized early that the vast number of products in the CMS arena made it
impractical to review them all. Consequently, it acknowledged early that the
perfect product might simply be missed in the review process. In spite of
this challenge, the team proceeded with its systematic review. In most cases,
charts, lists, descriptions and reviews were used; in some cases software was
downloaded and tried. Some products
did not offer enough metadata control. Others did not offer the desired
editing control. Others did not offer the internal link maintenance desired
by the team. Some were too difficult to use. Others did not offer flexible
re-use of database table content. Many products
were far too expensive. The team leaned early toward seeking an open source
solution. They had no desire to spend a big chunk of money up front that
would be followed by endless annual maintenance charges. Also important
in the decision process was the fact that the team already had significant
infrastructure in place. The existing intranet was vibrant and heavily-used.
It was built in a UNIX, Apache, MySQL, and PHP environment. The team wanted
to be able to integrate the new CMS product into the intranet as another
staff working tool, and wanted to be able to exploit their proficiency in
PHP/MySQL with the new CMS. In short, none
of the low-cost or free products that were reviewed satisfied all of the new
site and CMS requirements. After a thoughtful process, the team came to the
difficult decision to write its own CMS in-house. The library's management
team, recognizing the central importance of a strong web site to the
library's future, made the strategic decision to dedicate the staff resources
to the project. Environment:
human Beyond the web
team, the local environment included a wide range of staff. Staff in diverse
departments like Reference, Circulation, Interlibrary Loan, Reserves,
Branches, Audiovisuals, and Teleproductions would all be contributing content
to the new site. In the case of resources like research databases, staff from
various departments would be contributing information about a single
resource. For example, a reference librarian would input database
descriptions and URLs and describe the appropriate subject metadata for that
database. At the same time, a technical services librarian would input
availability restrictions for that resource, like whether the library's
license permitted remote access to the database. Plans like these were laid
in place to capitalize on staff throughout the organization. To make these
plans efficient, the CMS would have to provide a variety of updates to staff.
For example, staff would have to receive an email update when a new resource
was added so that they could complete their portion of the work of describing
it, or so that they could point to it from one of their content pages. In
short, the human environment also supported the decision to build a local
CMS, because only a local System could be customized enough to include these
kinds of alerting services tailored to the work, the content, and the local
staffs division of duties. Environment:
technical The LMS
environment consists of both Microsoft Windows and Unix servers. The web
sites are supported by Apple Xserves running Mac OS X Server - a flavor of
FreeBSD Unix. The web server is the open-source Apache server. Almost all
coding is written in PHP, an open-source server-side scripting language. The
back-end database is the open-source MySQL server. Mac OS X Server comes with
Apache, PHP and MySQL already installed. Figure 1 shows
the server architecture. A Windows file server allows sharing of the
non-database web content, i.e. HTML pages and PHP scripts, between the
production web server and the test web server. The web servers connect to the
file server as a client using the network file system (NFS) protocol. They
are connected via a private local-area-network using a gigabit Ethernet
switch. Since the file server runs standard Windows 2003 server software,
staff can connect directly to this server using native Windows file sharing
(SMB). While it is possible to run Samba on the Mac OS X servers to provide
SMB services, the web team has found that having Windows desktops connect to
a real Windows file server allows them to control access more easily using
Microsoft's Active Directory services. This also means that user accounts do
not have to be created on the web servers for staff use, thus reducing
administration requirements. As Mac OS X's support for Active Directory
matures, the file server might be able to be replaced with a storage area
network (SAN) device. Having a
separate test web server with access to the full set of HTML pages and PHP
scripts allows thorough testing of software updates and changes to
applications without disturbing the production web site. Once testing of
these updates and changes is complete, they can be safely applied to the
production server.
The LMS intranet
web site provides a central point for information needed by the staff. Many
staff tools, including the CMS, are now web-based and accessible via the local
intranet. Access to the intranet is via the secure-HTTP (HTTPS) protocol.
Access to the public web site is via standard HTTP protocol. The staff use
both Windows and Macintosh desktop systems. In order to provide a
what-you-see-is-what-you-get (WYSIWYG) editor for staff to use in our CMS,
the team needed to find something that would work on both platforms. They
chose the Editize editor from SitePoint Pty. Ltd. Editize is written in Java
and runs inside both Windows and Macintosh web browsers. Some problems were
experienced with Editize working properly in Internet Explorer (IE) on some
staff Windows desktops. Unable to determine why this was occurring, the team
decided to offer DevEdit, a product from Interspire Pty. Ltd., as a Windows
IE-only option. DevEdit does not use Java and so does not present the same
browser problems as Editize. Development plan The committee
wanted the new web site to go live at the start of the next fall semester,
only 14 months after the decision to write a local CMS. This tight timeline
made a development plan very important. The team had to work quickly,
breaking down what modules to build, what prototypes to test, what focus
groups to conduct, and the like, and then layout a timeline in which all of
these needed to occur. Because there were so many different aspects of the
project, some could take place at the same time. Others had very specifie
prerequisites. With a team working on the overall project, the workload could
be divided. The basic content creation code was written first. Then, content
creation started while the team finished writing the remaining content
creation pieces and the public display code. Prototypes for
the design of the new site were being developed while the CMS was still being
coded. Because all content was stored within database tables, and because CSS
was being used to separate content from style, the layout and design of the
site did not have to be completed before the contributors started developing
the content. Sketches for the new site were created based on focus group and
usability study feedback on the original site, as well as on the new features
the committee wanted to add to the new site. Although the sketches and
prototypes of the new site were not functional, they were adequate to describe
intended functionality to the focus group participants and get their
feedback, finding out what features they did not feel the new site needed,
what was missing, and what needed to be changed. Two rounds of prototypes
were presented to focus groups, with the second round of sketches having a
tighter focus based on the feedback from the first focus group. There were many
features that the participants loved and/or felt were long overdue, such as a
field on every page to search the library's online catalog, and the link on
the home page that takes users directly to their account login for renewing
books and the like. The idea of simply reducing the amount of content on our
home page received some of the best responses from the participants. Some features of
the new site they disliked, such as redundancy of information and links on
the new home page. This input really helped the team pare down the content
and streamline the home page. The focus groups also helped in cleaning up
some of the design issues on pages that were too busy in their layout or
background colors. Site developers were also reminded by the focus groups to
keep the terminology on the site simple and clear. Sometimes,
hearing how the new features could help them in new ways, they changed their
minds and decided they would like the new services, such as the thin space
dedicated to their link history (also known as breadcrumbs), or the added
space dedicated to the Media Services portion of Libraries & Media
Services. Some focus group participants felt the navigation tabs across the
top of the page should remain ' "on" after a user clicked on one of
them and went to the designated page. After they learned the site was not
nailed down with a rigid hierarchy, and that there were numerous ways to get
to a page depending on the user's needs, they understood that leaving a tab's
background color in the "on" state could be misleading. There were some
instances when services the participants continued to feel were not needed
were kept in the new site due to the requirements laid down by the web
committee, such as the "What's New" section on the home page, which
they felt they never viewed and took up valuable space. It turns out that the
focus groups consisted mostly of library patrons who found out about the
study from the "What's new" list, so even though they felt
"What's New" did not warrant the space, they were using it! Based on the
timeline to date, the content editor had to be one of the first things
developed so that staff could begin adding content to the site even as the
CMS was continuing to be developed. In addition to general text, images and
links to other sites, resources (e.g. links to databases, journals, and web
sites) were also an extremely important aspect of the new site. Since
resources were to be incorporated into the content of many pages, the
resource editor had to be built at the same time the content editor was being
developed. The programmers were on a tight schedule to get the CMS editor
built as quickly as possible, while making it as reliable as possible. Once
the most basic parts of the CMS editor were constructed, staff could be
trained and set to work on stocking the CMS databases with site content. Training and
documentation Once the content
editing tools were functional, at least the text, image, resource and table
building tools, staff training began. At no time before were so many LMS
staff prepared to develop pages on the web site. Multiple training sessions
were required to reach all the staff who were being assigned responsibility
for their departments' content. Most seemed quite enthusiastic to learn the
new tools, some were intimidated, and others felt restricted by a system that
did not let them design whatever they wanted and have direct access to the
HTML. In time, though, they all found the new system helped maintain a more
structured, polished looking web site. The staff were
able to train on a test version of the CMS, building as many pages as they
wanted without affecting what the public would see. They could build pages
with any content just to learn the system, or they could build rough drafts
of pages they wanted to later publish to the public site, getting a feel for
how they wanted to present their information while still learning the CMS. At
first they had to do this without even knowing what it would look like to the
public. Focus group feedback on the prototypes had not yet been completed,
and construction on the public version of the site was far from complete.
These practice exercises also helped the staff learn that this new CMS stored
their information in such a way that any later change to the look of the site
would not result in a loss of their content. The staff were
first taught how to build standard content pages - text, links and images.
For many this was a brand new concept. Additional training sessions were set
up just for the librarians who would be working with resources, and other
sessions just for those who needed to create tables. Considerably later, a
refresher on table creation was included with the form building training
session. During the
summer, as the programmers were coding the CMS and public site, and as staff
were just starting to learn how to use the CMS, two student employees were
hired to also thoroughly learn the system. They followed the programmers
along to classes and individual staff training sessions, and used the test
version themselves. Their job was to learn the system as if they were the
developers and the staff using the CMS, and to write up the documentation for
it. Two different approaches to documentation were used. One student was to
write up a training manual for the CMS, which would be accessible online so
staff could refer to it rather than going to the programmers with each
question. The training manual included step-by-step instructions on how to
use each tool built into the CMS, and included screenshots with every
section. The other
approach was to build in context-sensitive help. The other student worked on
a glossary of tool tips, so that staff could click on a section of the CMS
they were using and get the tips and defining terms for that specific section
of the tool. This context-sensitive help throughout the CMS proved to be very
valuable and well-received by the staff. In building this documentation, the
students were able to take an outsider's point of view on the whole system
and recommend ways to improve the usability of the CMS to the programmers, as
well as visit individual staff who still needed one-on-one help with creating
their pages. The CMS Instruction Manual table of contents (Figure 2)
illustrates the extent and length of the manual. The instruction
manual page on adding the metadata for a new web page (Figure 3) shows the
depth of instruction that the summer student assistants were able to develop. And, the
instruction manual page on adding a new resource (Figure 4) shows this same
depth as well as the extent to which metadata is applied to resources on the
site. This sample page illustrates how the staff applies LC terms, format
terms, descriptions and course weights to the description of an individual
resource. Database schema Considering the
complexity of the CMS, a lot of energy was initially spent on determining the
overall database schema. The team knew there was a risk of getting part way
into the project and realizing that something vital just would not work
because of an overlooked content or storage requirement. This team of
programmers had not previously attempted a project of this scope, and so
quite a bit of consideration went into developing an extensive, extensible,
thorough, and reliable schema. Schema planning was based on previous
experience with less complicated projects, as well as the desire to implement
and combine all the desired new features of this CMS and web site.
Figure 5, the
CMS and web site table schema, gives an idea of the extent, complexity, and
hierarchical relationship between all the database tables designed into the
new CMS and the new site. Content creation When the staff
logs in to the intranet and enters the CMS to begin work on a page, the CMS
homepage presents details on her/his 20 oldest pages (Figure 6). The left
column of the CMS provides links to all of the available tools: page editors,
table tool, resource editor, file and image tools, reports, subject headings
lists and tools, preferences, help, and an enhancement submission tool. Page overview
and navigation A page on the
new site typically uses a standard template. The template page is broken up
into three basic rows of content, and each of those can be broken into
sub-sections. A typical page (Figure 7) includes in the top row a header with
navigation, a Quick Jump navigation tool, and breadcrumbs; in the middle row,
the main content area with a left side column, a center column, and a right column;
and in the bottom row, a footer. The header
includes logos and two search fields - one for searching the site's content,
and one for searching the online catalog. The "Search our site"
tool allows a patron to enter search terms which are matched against metadata
terms for pages and resources on the web site. If no results are found, the
patron has the option of performing a keyword search against the complete
page content of the web site. Additionally, since many patrons were
attempting to do catalog searches via the "Search our site" tool,
an option to send the keyword search terms to the online catalog is provided.
Beneath the
logos and search fields, but still in the header section, are the navigation
tabs. These tabs break out some of the subsections of the site, but the
content is not necessarily restricted to any one of the tabs. Because the
team avoided enforcing a rigid hierarchy on the content, the tabs do not
remain "lit," or selected, once the user has clicked on one of
them.
Beneath the tabs
(and still in the header) is a Quick Jump drop down menu including some of
the most popular links within the site. Next to this are the bread crumbs,
which let a user track back through their path of visited pages in the web
site, as an alternative to using their web browser's back button.
The "Site
Index" tab displays a dynamically-generated list of all pages and
resources organized by metadata terms. An alphabetical list of all metadata
terms in use by any page or resource is displayed. The patron may select the
initial letter of the terms to display. Only controlled vocabulary terms are
included in the Site Index. Beneath the
header section is the main content area, which is divided into three columns.
The page editor (see Figure 8) shows the three columns available for content:
left, middle, and right. In this instance, the author is about to insert a
Page Index (a list of other pages on the site) in the middle column of the
new page. The left column
is always present by default. The author of a page may choose to turn the
left column off, but the web committee recommends that the staff keep it
viewable, unless turning it off is absolutely necessary for the content of their
page. In this way, users will not be confused by the changing upper left
starting point of the page content as they navigate through the site. The
middle column, or more appropriately "the main column" is where
page authors put most of their content. The optional right column is rarely
used, but can be handy when an author wants to provide additional information
or links that they feel might need to stand out from the main content area.
In early discussions of adding RSS feeds, this right-hand column has been
considered as a location. The optional left and right columns are each fixed
width, and the main/middle column expands to fill the remaining space. The
style sheets for the left and right columns scale down the content to be
proportional to the smaller space. Fonts are smaller; space between
paragraphs is decreased.
Each page has a
footer, which starts with a text-only version of the tabs across the top of
each page. Next comes the Icon Legend/Key, which shows the icons that may be
found on any page and what they stand for (off-site links, PDF files,
required form fields, etc.) Since some of these icons are dynamically
displayed on the site, based on links and content provided by the staff, the
key for all icons is consistently displayed on all pages. After the key are left
and right columns of information, containing when the page was last updated,
a privacy statement link, copyright information, the option to e-mail a link
to the page, and a contact link for the page. Simple URL Because the site
URLs contain only page numbers, they can be difficult for patrons to
remember. In order to provide an easy-to-remember URL for pages, the CMS
allows staff to assign a word to the page that can be used with the URL. For
example, this page: www.library.kent.edu/page/10562,
which contains information about how to find articles, can also be accessed
using this URL: www.library.kent.edu/articles This "Simple
URL" is stored along with the soundex value for it. If a patron enters a
Simple URL that is not in the database, they see a list of Simple URLs with
similar soundex values to what was entered. Getting started:
text and images As the
programmers started to build the presentation modules, first came the module
for the most basic parts of the web site - the text and image areas. The
third-party WYSIWYG editor (Figure 9) that was licensed and integrated into
the CMS editor pages allows the author to add and edit text, to mark text as
headers or regular content, and to make links to other pages and images. It
also provides standard editing features such as bold, italics, ordered and
unordered lists, and text alignment. Image tool Staff may insert
images, but the images much first be uploaded using a tool that allows the
image to be given a name and description. Staff may use images uploaded by
other staff, and they have the option to preview all the uploaded images,
including the graphic, the file name, and the description. The image tool
restricts what file types the staff can upload to the JPG, GIF, SWF, and PNG
formats, as well as limiting the file sizes that can be uploaded. This
restriction assures that the staff does not upload files that might be too large
and therefore too slow for a person using a dial-up connection to download at
home. In addition to
images, a restricted list of other file types may be uploaded to the CMS,
including text files, spreadsheets, PDFs, PowerPoint presentations and videos
(DOC, TXT, RTF, PDF, XLS, PPT, MOV, MPG and AVI). These files can then be
embedded in a page, or linked to from the page. These uploaded files also
have a restriction on their file size, but special exceptions can be made for
larger files if necessary. Table tool On the old site,
HTML tables were often misused to create the layout of a page or to hold
images in place. Web development in general is moving away from this
practice, and instead using cascading style sheets for the positioning of
content. It is becoming more clear that tables should be used as they were
originally intended - for tabular data. To help correct the tendency to
misuse HTML tables, the team deactivated the option to create them in the
WYSIWYG editor and built a much more powerful tool in their place. The table
tool allows the staff to create database tables, name the tables, set up the
fields (columns) of data in the tables, and define what type of data
(characters, dates, yes/no, etc) will be stored. Staff can then add a table
section to their pages using the data from a table they created or data from
a fellow staff member's table. A single table can have its data displayed on
multiple pages, or multiple times on a single page.
Staff can create
database tables, stock them with content, and then choose how that content is
displayed in their pages, intermingled with the text and image sections. The
table data can be sorted to display in any order, and can have the display of
its content restricted by criteria set by the author (e.g. only display data
within a certain date range, only display data with certain text, or only
display data if check-marked, etc). When displaying
content from a table, the staff member chooses from a series of options to
determine what content will and will not display, what order it will display
in, and how it will display (Figure 10). The table data can be displayed in
the expected grid-like table format, or it can be manipulated to display as a
bulleted list. Table title and rows may be displayed, and when appropriate,
table rows may be numbered. The table's location on the page may be given an
HTML anchor, and its position on the page may be centered and have a set
width, or the browser may use the default settings. There are times when an
author only wants to display a limited number of results from the table, so
this option was built into the tool. The display of data can be
date-dependent, so that a record can be set to display within a particular
date range.
Multiple pages
can use data from the same table, reducing the need to enter the same
information on multiple pages, which in turn reduces the amount of outdated
information across the site. For example, if a staff member's name and
department are pulled from the staff directory table and listed on more than
one page, updates to the information in the staff directory table will be
reflected on all the pages. When a table is
added to a page, the author may choose to limit which records are displayed
based on criteria. Using the table display tool, they are essentially
building an SQL query with which they may require fields to contain certain
data, be less than, greater than a certain number, be compared to a date,
etc. If the data
coming out of a table has limitations on what will be displayed, and if those
criteria result in no data actually displaying on the public page, the staff
member can be sent an e-mail message letting them know their table is
displaying "zero rows" and that they might want to go back and
adjust these limitations. The code checking for zero rows being displayed is
automatically run nightly. It is possible, especially in the situations where
a date is used in the limitations, that a table displaying content today may
stop displaying any content at a later date. Or perhaps a page author is
displaying records from another staff member's table, and the original table
is edited in such a way that it no longer displays any records on that
author's page. In situations like these, an e-mail is sent to the author,
letting them know that their table display is empty. Calendar tool After the table
tool was developed and the site was getting closer to production, a tool was
needed to display calendars/service hours on the site (Figure 11). Since many
of the departments and service points have different schedules that change
based on variables like the day of the week or the week of the semester, and
since the coordination and display of these schedules is overseen by the
Library Dean's Office secretary, a tool was created so that she could enter
the data for each department, setting date ranges that spanned weeks at a
time if needed. For example, hours could be entered for all Monday through
Friday ranges, or for a specific date range, or only for the circulation
desk. Once all this data is entered and approved, it can be changed from
draft to published status and made available to the public. The public can
see this data in a monthly calendar grid for one department, or can see a
day-by-day listing of hours for all departments at once - all pulling from
the same database tables. The calendar information can also be exported to a
PDF displayed in a specifically-formatted printer-friendly page layout,
matching the original format used for many years by all the public service
points.
Form tool Once the site
went live and all the major components were built, the team could go back and
fill in some of the gaps, such as giving staff the ability to create forms on
their web pages. So that staff would not have to ask a programmer to build a
specific data-collecting form, the form tool was created as an overlay of the
table tool. The staff may
create their own web forms, first by building a table to collect the data
gathered in the web form, and then by using that table's fields as the fields
in the web form. The web form is built in the same way as a standard text and
image area, only staff can use tags in the format: [field:fieldName] as
placeholders for the form's fields. At the time the form is displayed to the
public, those tags are converted into the appropriate field type, as set up
in the original table and with options in the form tool. The character width
(columns) and number of rows in a field may be set by the staff as well, in
case they need specifics like a small single line field, a multi-line text
area, or the like. Fields may be single line text entry, multi-line text
entry, date pull downs, checkboxes, or selection lists. Any data collected by
the web forms is stored in the original table, and the staff have the option
to have that data e-mailed to themselves as well. In other words,
after the creation of a table in the CMS, a form can be built based off of
the table (Figure 12). All fields in the original table are displayed as
options to include in the form, and may be marked as required if the page
author feels this is necessary. Required fields are marked with a red
asterisk when displayed in the public form. Fields may be pre-populated with
default values. Selection lists (created as common-delimited lists in the
original table) display as pull-down lists of options in the form. To set the
position of a field in the form, the author can copy the CMS-specific tags
into the WYSIWYG editor. For example, in Figure 12, the item:
[field:Phonenumber] will mark the place for a text field in the form. Fields
may be marked as required, may be displayed in any order desired, and may
even be chosen not to be displayed to the public (for example, the date the
form is being filled out). At this point, the form builder is the only place
in the CMS that allows staff to use HTML tables, since they are one of the
best ways to layout a form with its headers, fields, and descriptions. Page index When
constructing a page, the page author can include a section that is a page
index, a list of related links within the site. When an author chooses to
include a page index, s/he chooses words from the pre-defined list of
descriptive terms, LC subject terms, and special terms that are used to
describe every page in the CMS. When a person views this page index, a
dynamically-generated list of the pages matching the terms is provided, with
links to each of those pages. A page index may be sorted alphabetically or
chronologically by last published date by the viewer of the page. This
sorting is dependent on the viewer's session ID, so two different users of
the page could choose to sort their view of the page index differently.
Resource editor Resources are a
very important component of the new site content. Resources can include
anything from research databases to web sites. Staff decide what constitutes
a resource and add the information for the resource using the CMS resource
editor. The metadata available for classifying a resource includes: title,
description, Library of Congress Subject Headings, format (e.g. journal), URL
to content, URL to other information about the resource, access restrictions,
coverage, full text availability, catalog record number, and audience (e.g.
scholarly). Resource descriptions can also be added on a per-department
basis. Additionally, weightings (e.g. core) can be added by department or
department-course. This department and course metadata can then be used to
dynamically create subject guides and course-specific pathfinders. Figure 13
shows the resource metadata options available to a staff member in the Resource
Editor. The extensive
resource metadata description built into the system, combined with
personalization, also on an ambitious development agenda, may prove to be
core to future developments like an online reference interview function and
an option for classroom faculty to enter resources and resources descriptions
themselves to make course-specific resource pages. Resource index Resource indexes
are similar to page indexes, but instead of specifying a list of related
pages on the site to display, the staff member selects from a series of
complex options (e.g. subject, format, discipline, department, etc.) that
specify a list of resources to display. Figure 14 shows a page built with a
resource index; in this case, the resources are research databases. Recall
that a "resource" is an intellectual item like a database, a web
site, or a journal article that has been described in the system with the
resource editor. Figure 15 shows
the Resource Index editing tool in the CMS. The fact that the tool allows the
staff member to display resources that match criteria like department,
course, and weight (from "core" to "may be of interest,")
makes it easy to create pages that list course-specific resources. The CMS as it
stands today offers the staff member a rich set of tools to build pages,
build forms, describe resources, and display content in specific ways. A year
and a half past its launch date, the CMS is proving to be stable and capable
for the needs of all of the staff members in the organization. Administrative
tools Reports and
statistics From day one of
the planning, the team wanted the CMS to provide rich reporting tools as well
as rich maintenance tools. To date, the list of reports in the system is
rather extensive (Figure 16), including reports on data like broken links,
terms used, and pages per contributor.
Link maintenance Currently the
web site has more than 4,500 links, including internal and external links.
One objective of the new web site is to minimize the number of broken links.
This objective becomes increasingly difficult as the number of links in the
web site grows. To achieve this objective, two steps have been taken. First,
internal links, which are links to other pages on the web site and links to
images and files on the site, cannot become broken because the CMS prevents
pages from being deactivated or images and files from being deleted if there
are any links to them from elsewhere on the web site. Second, every
external link in the web site, including those in pages, resources, and
tables, is checked every night to ensure that it is accessible. If a link is
inaccessible, a counter is incremented. Some links will be inaccessible for
short periods of time due to network problems or web site maintenance; the
CMS accounts for this fact by simply tracking a broken link for five days
before taking any action. Once a link has been inaccessible for five days, an
e-mail message is sent to the page, resource, or table editor indicating this
problem status. A second message is sent once a link has been inaccessible
for ten days. Once a link has been inaccessible for 15 days, an e-mail is
sent every day reminding the staff member of this fact. A report (Figure 16)
of the current broken links is also available in the CMS to all staff members
who are content providers. Site statistics The following
are generated on a monthly basis: monthly hits per page statistics (Figure
17) monthly sessions per page, monthly visits duration per page, all pages
totals, and referrers list. These figures include the total of last year's
hits, and each page's percentage of a month's hits. If a visitor views the
same page more than once in a visit, each hit to the page is counted.
Month-by-month
sessions per page, including totals for the previous year, and each page's
percentage of a month's sessions are also recorded (Figure 18). If a visitor
views the same page more than once in a visit, only the session is counted. The cumulative
amount of time spent on each page in a month is tracked (Figure 19) by the
use of session cookies. Nevertheless, the total figure is a rough estimate,
since literal time spent on a page cannot be recorded if a visitor closes
their browser or goes to an off-site link. A report called
"All Pages Totals" (Figure 20) displays boiled down information
from the other statistical reports, such as the grand total hits and sessions
for a page, when that page was last visited, how often that page was the
first or last page visited in a session, and how much time was spent on the
page since its creation. This report is proving to be very valuable to staff
members as they evaluate the use of their pages. The Referrers
List report (Figure 21) counts the number of visitors from external web sites
to the new site. This report can help the committee evaluate where users come
from and therefore decide how and where to focus its efforts, for example, on
the addition of links to the site on external sites. For example, the fact
that four times as many users get to the new site from the university
homepage (www.kent.edu) than from the
faculty/staff/student portal (flashline.kent.edu)
might be important. Also important might be the fact that so relatively few
users get to the site from the online catalog (kentlink.kent.edu).
Future
enhancements to the statistics will include a report of the most common paths
through the site. This report will allow the web committee to track, for
example, the most popular links off of the home page. It will also allow the
study of how efficiently (or not) users find certain information on the site. Future
enhancements During the focus
group sessions, the team heard from patrons that they would like to be able
to personalize their interaction with the web site. Some patrons preferred a
more graphical interface while others a more minimal interface. The option of
giving patrons more control over their experience with the site is a high
priority on the project enhancement list. Because the site is dynamically
generated, creating a customizable interface will not be a difficult goal to
achieve. To date, the chief limitation has been the lack of a centralized
authentication service on campus. There is no desire to create another
username and password for a patron to remember. Nor is there a desire to use
the patron's online catalog login, as this still uses the patron's social
security number.
Recently Kent
State University has implemented a Lightweight Directory Access Protocol
(LDAP) server which could be used as an authentication server. At the same
time, work is underway to implement the Shibboleth system (http://shibboleth.
internet2.edu/)
as a single-sign-on service. A Shibboleth implementation would rely on the
local LDAP. The team plans to wait until Shibboleth becomes available on
campus and use it as the authentication method for the web site
personalization project.
Another
potential enhancement involves the Resource Editor and the Resource Index.
Since these tools are used to describe resources and to present customized
lists of resources, and since several of the variables in each are items like
course, department, weight and discipline, it takes only a small leap to
envision classroom faculty across campus being trained to input their own
resources for a page that is specific to a single course. One of the most
exciting enhancements envisioned for the system is an online reference
interview that takes advantage of the extensive resource description included
in the site. A series of questions ranging from subject, to course, to
department, to scope of assignment could be presented and result in the
display of a customized list of resources appropriate to the particular
project at hand. Combined with personalization, single-sign-on, and
integration with the university's student portal, this reference interview
could be sophisticated enough to welcome the student at sign-on, present them
the list of their current courses, and begin the interview by asking them
which of the current courses has prompted the current reference question.
Conclusion Several years
into the project, the web team at the Kent State University libraries has
built a local CMS that includes functionality that is very helpful to
libraries. One of the most important of these functions is the extensive
metadata description that is created for every resource on the site. Another
is the extensive provision for the re-use of content. Another is the rich
array of editing tools and their separation of content from HTML and site
presentation. Still another is the suite of link maintenance tools and
statistical reports for the site. Overall, staff and management feel that the
personnel investment in the project has more than paid off in terms of site
quality and efficiency.
|
