“LibData to LibCMS:
One library's evolutionary pathway to a content management system”
(doi:
http://dx.doi.org/10.1108/07378830610652086) records the effort put in by a team
of librarians at University of Minnesota to port their content from a data
repository over to a more active content management system (CMS).
U MN librarians looked into the advantages and disadvantages
of using a CMS. This part of the article explains that the library team
considered other options in light of thoughts that they should proceed
cautiously and not just jump on any CMS bandwagon. They also carefully
considered creating their own CMS from scratch or buying a commercially made
version from a vendor. They realized that by creating their own CMS they would
have control over source code, they would have no proprietary issues and they
could tailor the system to their needs as a group of university libraries.
Subsequently the team developed an analysis of the
requirements of the CMS, this was a terse, stripped down list of core
functions. Clearly institutional experience in their last project, which
resulted in a specification document with over 300 items, tempered and disciplined
their new requirements to a sparse but seemingly authoritative eight points or
demands for minimal requirements.
At one point in the article, Bramscher points out that the CMS
would be used to handle special content, including:
Records in databases, singly or
in sets. These produce point‐of‐query algorithmic or computed content. They may be
instantiated in the form of search results based on permuted user selections.
They do not exist as assembled content until an end‐user creates a set of conditions
such that they congeal.
Despite
that last gelatinous analogy, I like that part as it succinctly states what a
CMS does and how it acts with the databases, in this case the LibData, which
provide content for the web pages put together using the templates created in
the CMS. These webpages are created solely as a result of choices made by the
user.
The
article also details the tradeoffs between “content,” “management,” and
“system” and the inherent tensions and tradeoffs that are assumed in automating
these three areas.
The
remainder of the paper reviews how the completed CMS finally performed once
completed. LibCMS had a great and simple navigation system of breadcrumbs this
class not being focused on HCI, I won’t go into it here, suffice it to say it is both simple as well as completely. LibCMS utilized
widgets to provide dynamism in page generation (I don’t know what advantages
that offers). Being a CMS for a research library, LibCMS developed a manner of
handling foreign characters to smooth out problems from one character set to
another, a recurring headache especially in disparately created collections of
databases.
Overall
this paper dealt mostly with managerial matters in choosing to buy or create a
proprietary CMS for a library system and what might be a good set of
requirements for developing one. I guess before I started in DigIn, I was not
as interested in management perspectives, but this paper helped me understand
what goals needed to be met by creating and running a CMS for a consortium of
state university libraries.
