Drupal - UTC Library

yieldingrabbleInternet και Εφαρμογές Web

7 Δεκ 2013 (πριν από 5 χρόνια και 2 μήνες)

222 εμφανίσεις

The Charge:

Web Team 1: Investigation and Selection seeks to recommend a Content Management System (CMS) for the
new UTC Library website that will organize library information and policies, promote materials and services,
and allow for easy upkeep and rep

The Need for Change:

While Joomla was a viable solution at the time of implementation, it is no longer capable of supporting our
increasingly complex site. Furthermore, starting fresh with a new tool will allow us to implement workflows
to take fu
ll advantage of the collaborative editing capabilities of a CMS.

The University at large is also in the process of selecting a new CMS to manage the UTC website. Some
benefit could result from waiting to hear what system UTC chooses; however, since the Un
iversity does not
have a specific timeframe in mind, we have to press ahead with our selection in order to complete our site in
time for the opening of the new building. The library website also has different needs than any other
University department, and

is best served by a system that addresses those unique needs.


The Web Team reviewed a number of sources to inform our work. Among them were several articles and
blog posts focusing on general content management system concerns a
nd library specific
and us

A list of sources appears on the wiki page that houses this report.

To summarize the basics of what we learned in our review, the following selection considerations seemed to
rise to the top in most articles

we read

about CMS choice in libraries

Flexible site design / templates

/ back end interfaces

Conformity of style and appearance

Ease of content creation (separate from design)

Integration of and with existing content / providers.

Readily available modu
les for common needs / actions / uses


Open source

+ a
ctive user base

Internal Survey Results:

We chose to distribute an internal survey in order to solicit early feedback in what will be a highly iterative
and collaborative web redesign process.
We asked library faculty and staff to answer three questions, one of
which just asked them to state their department.
The second question asked for
feedback on
features they
look for in a web design or management tool. The third question was open

ended and asked
what they would like to see in a new website that might

benefit their department’s audience
. The second
question yielded the most useful information for our decision making. The open ended question garnered
lots of input that will be usefu
l when the actual design phase of the new website is begun. The chart below
shows the features our staff and faculty find most important in selecting a web site platform.

Investigation and evaluation criteria

When considering the various criteria for e
valuating a CMS, we determined that characteristics could be
grouped together to represent three different but overlapping
perspectives: technical requirements,
back end management, and front end capabilities.
We investigated each of the selected sys
tems using the
same criteria for each of these perspectives.

Defining The Choices:

After reviewing the literature and compiling our survey, we examined the matrix of available CMS’. The array
was truly staggering and it w
as quickly apparent that we could not realistically vet all of the potential systems
out there. Using the many of the criteria listed above

in particular the open source options with an active
user base in libraries

we set about narrowing our choices.
Our reasoning was that with literally hundreds of
CMS’ out there, we would be best served in choosing one already proven to be effective for library purposes.

Our choices for consideration included:


Although Drupal is complex and carries a steep l
earning curve, it is very widely used and has perhaps
the most active library user base of any open source CMS


The Library already has a multi
use install of WordPress. The literature shows that WP is increasingly
flexible and powerful as a fu
lly integrated publishing platform and its usage as a CMS is growing,
particularly in libraries.

Expression Engine

Expression Engine is a commercial CMS solution that used locally by Girls Preparatory School. It was
recommended by local consultant Aaron
Gustafson as a potential solution that offers some of the
features we would need.

Technical requirements

The technical requirements for each of the choices are roughly similar. Each will require a dedicated web

which in the UTC case will be a vir
tual server, given the campus networking setup.
Each option runs on
the standard LAMP (Linux, Apache, MySQL, PHP) stack, and installation and server maintenance will be
similar to our existing Joomla, Mediawiki, and WordPress installations.

There is exis
ting technical knowledge within the Library on the maintenance of WordPress, while Drupal and
Expression Engine would require some skill acquisition and research to appropriately support. Drupal is
perhaps the most flexible overall, but would require the m
ost oversight and effort in setup to ensure future
capabilities. Expression Engine is the only non
open source option
. EE does come with s
upport as a part of
the cost, but both Drupal and Wordpress have robust
freely shared knowledge bases and

available at no cost
. In addition, should we need extra support for
a special use case or a
commercial support
available from vendors

on a short term or case by case basis

In each case, the ongoing technical maintenance would

require monitoring for updates to the main software
package as well as any extensions to the central package. These extensions can be called many things
(themes and plugins in Wordpress, templates and modules in Drupal) but all require regular updates.
pending on the final form of the site, themes and plugins should be chosen carefully so as to avoid
incompatibilities that can be created if a theme or template uses version
specific hooks. This is a known issue
with Drupal updates, where modules can becom
e out of sync with the main install, necessitating falling
behind on security updates in order to maintain functionality.

Back end management

When assessing back end management, we identified six characteristics that we deemed most important:
online he
lp or documentation; drafting and review capabilities; familiar editor for pages; easy login; fast
loading and updating system; and easy navigation. These six characteristics were the basis for Question #2 on
our user survey.

The motto for this investigat
ion turned out to be, “there’s a plugin for that.” WordPress is fully functional out
of the box, but it is not nearly robust enough to power a library website without a long list of additional
plugins. Drupal and Expression

Engine are comprised of modules
that power everything from the WYSIWYG
page editor to public facing to calendars.

Notably, WordPress 3.0 introduced custom post types, which allow users to define different types of content
on their sites and exercise fine grained control over how those d
ifferent types of content are displayed. This
development helped to move WordPress from a blogging platform to a

CMS. The language is still
somewhat confusing, because “post” does not necessarily refer to a “blog post,” but rather means just a

piece of content.

Despite the confusing terminology, we feel that WordPress does offer the means to manage
most of our different content types effectively using post types and categories.

Front end capabilities

Each of the three choices allows users to
design visually pleasing and usable websites. However, they vary
considerably in the amount of time and technical skills that are necessary to create the desired look and to
enable patron interactivity.

Design templates are available in all 3 platforms. D
rupal is the most difficult to use in this regard because the
entire system, both the front and back ends, requires custom development from the ground up. There is an
active user base and
there are
existing templates to draw from, but the process is more c
omplex than with
other platforms. Expression Engine also has some readily available design templates and implementing them
is simpler than with Drupal

but the user base is not as large or active as the other two options

and there
would still be a steep le
arning curve there
. WordPress has many free or low cost themes to choose from and
installing them is relatively easy. Most also include simple to use options for tweaking colors, fonts, toolbars,
menus and other design elements. The active Wordpress user b
ase is also a great source for informal design

Drupal and ExpressionEngine are capable of creating complex forms, but they make the task difficult.
Customized programming is required and can be time consuming. WordPress is not as robust in its ab
ility to
generate complex forms, but it makes up for it by allowing users to create basic forms both simply and
quickly. Drupal has the built
in capability to collect user data such as surveys and registrations, whereas
WordPress and ExpressionEngine requi
re add
ons to do this. They all have plug
ins that allow for the display
of advertisements, calendars, and news.





Used very widely. Many existing templates to draw

Extensive array of modules for specific func
tions (ie
calendaring, advertising, directory, forms)

Could theoretically provide integrated replacements
for existing web services (wiki, blogs)

Has a strong existing library user base and support

Allows for complex workflows for publication ba
Complex to configure

Steep learning curve to get started for those
unfamiliar with web development

Too geeky

ie every single thing has to be tinkered
with and created from scratch

Updates to pieces of install often aren’t synchronous,
resulting in difficulty in moving instal
lation forward.

Workflows and permissions are difficult to initially set

Simple mobile theming

on user roles

Can integrate with Active Directory authentication
(with module)

Library specific development is underway (including
integration with ILSes and digital collections

Integrates well with third party systems




Very powerful commercial CMS

Many specific modules to choose from

Good support for differing roles (admin, page


Initial set up is not as complex and demanding as Drupal or
other CMS

Migration of existing content is supported

Does offer customer support

Good security and stability

Can create workflows with plugin

Easy to design for without use of a programmi
ng language

Many first
party plugins that are maintained

Not widely used in libraries

No one here knows it

Steep learning curve


Smaller developer community / forums

Does not have highly developed WYSIWYG

ifficult to change
theme after

Upgrades can be time consuming

Difficult to integrate Active Directory

Requires FTP access to add plugins

Some plugins require paid license

Requires additional plugin to create drafts

Mobile site solution not fully developed

tion to Expression Engine 2.0 + Review, Scriptiny Developer Resources





Already in use at Lupton Library (existing comfort
and knowledge)

Increasing number of libraries using it

Wide array of themes

Comes with management tools ou
t of the box,
such as WYSIWYG editor

New custom post types allow for highly
customizable templates

and page types

Familiar interface

Supports roles and levels of access

Migrating content would be relatively easy

Plenty of plugins and modules to address spe
features (ads, calendars, news)

Can integrate with Active Directory authentication
(with plugin)

Allows for drafting and previewing

Simple mobile theming

May not be fully developed as complete CMS platform

Not a good candidate for wiki, but should

be able to
handle blogs and main web presence

Workflows are difficult to initially set up, require
numerous plugins

Requires knowledge of PHP to take full advantage of

Few existing plugins are library specific

Summary of recommendations


the 3 choices above, Expression Engine turned out to be the least viable option. First of

it is a
commercial product that

initial outlay
s to

implement. EE does offer many common features that
could be useful to a library website, but the
re are issues that might prove to be potential stumbling blocks
such as the difficulty in changing theme or design once the initial decisions are made at install. In addition, EE
does not integrate well with Active Directory and many
of the plug

es and add
could only be
implemented if we absorb the

extra costs associated

with purchasing them


(they do not come
with the initial product)
So our first decision point was to conclude that the two open source options are
more viable for

our needs.

In evaluating the two remaining open source options, w
considered their user bases among libraries as well
as their power and
flexibility in addressing our website needs. In looking specifically at the features desired
by our library faculty

and staff via the survey, a familiar interface (similar to Word) ranked the most highly,
followed closely by easy login and drafting/review capabilities.
Drupal offers the ability to create a custom
back end interface that is familiar and easy to use, but

it literally has to be built from the ground up using
modules. One of the main reasons Drupal is so powerful is the fact that it is basically an “empty framework”
to begin with and Drupal developers have the option to develop both front
page templates

back end


that will accommodate their unique and individual needs. But the construction of basically an
entire CMS
from scratch to meet local needs
is a difficult proposition without substantial knowledge at the
Unfortunately, n
o one her
e currently has
that knowledge. Unless the new Web and Instruction
Librarian comes in with an existing familiarity with Drupal, it does not seem feasible that we could accomplish
the necessary learning curve to implement Drupal given our small staff and ma
ny competing demands.

Of course the
easy to use
back end interface is only part of the equation. The front end template, design and
appearance as well as integration of our content from many different sources

of primary importance in
developing a lib
rary website.

Drupal certainly offers the most flexibility

but the
issue of learning
curve gets in the way of our taking advantage of it. WordPress offers hundreds of themes (most of them
freely available and adaptable) that would allow us to d
evelop a cohesive, flexible and visually appealing
digital face for the library. While WordPress initially began as
a blogging platform, the wide array of plug
tools and modules currently available have moved it much further in the direction of being
a full
online publishing platform able to handle blogs, subject guides, dynamic pages with database links, tables
with policies and hours, etc. The recent introduction of specific post types for specific purposes will allow us
to create workflows
for these various functions (for example, a post type for policies, a post type for subject
guides, a post type for hours, a post type for database links, etc.)

The only tool we currently use
wouldn’t be well replaced by
a total
is the wiki

but that content could certainly
where it is and
be linked effectively from a WordPress main site much as we do now.

The user base for libraries and Wordpress is also strong and growing. Several recent publications and an ALA
course focusing on WordPress as a library CMS have appeared lately and the consensus is that the platform
offers most of the features and flexibility that libraries need to create and maintain attractive user friendly
Our library is already an

experienced user of WordPress and we have numerous faculty and staff
who are already familiar with its interface and tool boxes. Migrating to a WordPress site would not be a steep
learning curve for most of our content creators and maintainers.

So based

on all of the above, the Web Team 1 recommends that we consider WordPress as our best choice
for a new website based on its

template features, plug
ins, back end interface and overall ease of use as a
platform. As a part of this process we would need to m
igrate our existing WordPress install to a new server
and re
architect the way we handle our existing blogs. Once that is accomplished, we could then begin the
process of planning and framing out the new website.