Commentaires 0

Retranscription du document

The Charge:

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

The Need for Change:

While Joomla was a viable solution at the time of implementation, it is no longer capable of supporting ourincreasingly complex site. Furthermore, starting fresh with a new tool will allow us to implement workflowsto take full 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. Somebenefit could result from waiting to hear what system UTC chooses; however, since the University does nothave a specific timeframe in mind, we have to press ahead with our selection in order to complete our site intime for the opening of the new building. The library website also has different needs than any otherUniversity department, and

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

BriefLiteratureReview:

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

issues.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 torise 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 modules for common needs / actions / uses

Security

Open source

+ active user base

Internal Survey Results:

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

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

benefit their department’s audience. The secondquestion yielded the most useful information for our decision making. The open ended question garneredlots of input that will be useful when the actual design phase of the new website is begun. The chart belowshows 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 evaluating a CMS, we determined that characteristics could begrouped together to represent three different but overlappingbroadperspectives: technical requirements,back end management, and front end capabilities.We investigated each of the selected systems using thesame 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 arraywas truly staggering and it was quickly apparent that we could not realistically vet all of the potential systemsout there. Using the many of the criteria listed above–

in particular the open source options with an activeuser base in libraries–

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

Our choices for consideration included:

Drupal

Although Drupal is complex and carries a steep learning curve, it is very widely used and has perhapsthe most active library user base of any open source CMS.

WordPress

The Library already has a multi-use install of WordPress. The literature shows that WP is increasinglyflexible and powerful as a fully 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 wasrecommended by local consultant AaronGustafson as a potential solution that offers some of thefeatures we would need.

Technical requirements

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

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

There is existing technical knowledge within the Library on the maintenance of WordPress, while Drupal andExpression Engine would require some skill acquisition and research to appropriately support. Drupal isperhaps the most flexible overall, but would require the most oversight and effort in setup to ensure futurecapabilities. Expression Engine is the only non-open source option. EE does come with support as a part ofthe cost, but both Drupal and Wordpress have robustfreely shared knowledge bases andusercommunities

available at no cost. In addition, should we need extra support fora special use case or acustomenhancement,commercial supportisavailable 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 softwarepackage 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.Depending on the final form of the site, themes and plugins should be chosen carefully so as to avoidincompatibilities that can be created if a theme or template uses version-specific hooks. This is a known issuewith Drupal updates, where modules can become out of sync with the main install, necessitating fallingbehind 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 help or documentation; drafting and review capabilities; familiar editor for pages; easy login; fastloading and updating system; and easy navigation. These six characteristics were the basis for Question #2 onour user survey.

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

Engine are comprised of modulesthat power everything from the WYSIWYGpage editor to public facing to calendars.

Notably, WordPress 3.0 introduced custom post types, which allow users to define different types of contenton their sites and exercise fine grained control over how those different types of content are displayed. Thisdevelopment helped to move WordPress from a blogging platform to afull-fledged

CMS. The language is stillsomewhat 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 managemost of our different content types effectively using post types and categories.

Front end capabilities

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

Design templates are available in all 3 platforms. Drupal is the most difficult to use in this regard because theentire system, both the front and back ends, requires custom development from the ground up. There is anactive user base andthere areexisting templates to draw from, but the process is more complex than withother platforms. Expression Engine also has some readily available design templates and implementing themis simpler than with Drupal,

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

and therewould still be a steep learning curve there. WordPress has many free or low cost themes to choose from andinstalling 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 base is also a great source for informal designsupport.

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 ability togenerate complex forms, but it makes up for it by allowing users to create basic forms both simply andquickly. Drupal has the built-in capability to collect user data such as surveys and registrations, whereasWordPress and ExpressionEngine require add-ons to do this. They all have plug-ins that allow for the displayof advertisements, calendars, and news.

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

it is acommercial product thatcarries

initial outlaycosts to

implement. EE does offer many common features thatcould be useful to a library website, but there are issues that might prove to be potential stumbling blockssuch as the difficulty in changing theme or design once the initial decisions are made at install. In addition, EEdoes not integrate well with Active Directory and manyof the plug-ins,

modules and add-onscould only beimplemented if we absorb the

extra costs associated

with purchasing them

individually

(they do not comewith the initial product).So our first decision point was to conclude that the two open source options aremore viable for

our needs.

In evaluating the two remaining open source options, weconsidered their user bases among libraries as wellas their power andflexibility in addressing our website needs. In looking specifically at the features desiredby 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 customback end interface that is familiar and easy to use, but

it literally has to be built from the ground up usingmodules. 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 frontpage templatesand

back end

interfaces

that will accommodate their unique and individual needs. But the construction of basically anentire CMSfrom scratch to meet local needsis a difficult proposition without substantial knowledge at theoutset.Unfortunately, no one here currently hasthat knowledge. Unless the new Web and InstructionLibrarian comes in with an existing familiarity with Drupal, it does not seem feasible that we could accomplishthe necessary learning curve to implement Drupal given our small staff and many competing demands.

Of course theeasy to useback end interface is only part of the equation. The front end template, design andappearance as well as integration of our content from many different sourcesare

of primary importance indeveloping a library website.

Drupal certainly offers the most flexibility,

but thedifficultissue of learningcurve gets in the way of our taking advantage of it. WordPress offers hundreds of themes (most of themfreely available and adaptable) that would allow us to develop a cohesive, flexible and visually appealingdigital face for the library. While WordPress initially began asa blogging platform, the wide array of plug-ins,tools and modules currently available have moved it much further in the direction of beinga full-fledgedonline publishing platform able to handle blogs, subject guides, dynamic pages with database links, tableswith policies and hours, etc. The recent introduction of specific post types for specific purposes will allow usto create workflowsfor these various functions (for example, a post type for policies, a post type for subjectguides, a post type for hours, a post type for database links, etc.)

The only tool we currently useheavilythatwouldn’t be well replaced bya totalWordPressoverhaulis the wiki,

but that content could certainlyremainwhere it is andbe 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 ALAE-course focusing on WordPress as a library CMS have appeared lately and the consensus is that the platformoffers most of the features and flexibility that libraries need to create and maintain attractive user friendlywebsites.Our library is already an

experienced user of WordPress and we have numerous faculty and staffwho are already familiar with its interface and tool boxes. Migrating to a WordPress site would not be a steeplearning 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 choicefor a new website based on its

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