Vanguard University: Streamlining Campus Web Publishing
In 1995, Vanguard University built its first Web site (www.vanguard.edu).
Like many organizations on the early World Wide Web, the site was mainly “brochureware.”
By late 1999, it had grown to nearly 300 static HTML pages that were infrequently
updated because the process of adding or editing pages required development
of a new HTML file and the reworking of navigation image maps. Site editors
were limited to a handful of staff and faculty with significant technical skills.
Consequently, content was often outdated and site visitors regularly e-mailed
complaints, particularly about university news and sports stats.
As the school’s newly hired full-time Web master, I spent nearly all my
time trying to keep the backlog of update requests from growing larger. I had
little time to move the site’s infrastructure forward or add critical new
features. Something had to change, and as it turns out, everything did.
After setting priorities for the needs of the site based on visitor usage,
I began by building the site’s athletics section using Microsoft Active
Server pages. I created a custom-built content management system (CMS) with
page templates that were served from a database and updatable via browser-based,
custom-built data-entry forms. Vanguard’s sports information director began
posting her press releases, game wrap-ups and stats using this custom-developed
system.
E-mails about outdated sports stats ended. Now, I had more time to build out
other areas.
While Vanguard’s custom-built CMS was a big step forward, it was not a
long-term solution. Entering content into the forms required non-technical people
to learn basic HTML skills. Content editors using the form couldn’t see
the page as it would look on the site. They had to proofread the content after
publishing it to the site, then login to the CMS again to make revisions if
mistakes were found or the page did not display properly. The system offered
no way to add tables, pictures or media without content editors learning more
advanced HTML. Code validation before publishing was impossible. The need for
content editors to have technical expertise meant the solution was limited to
only a slightly larger group than before. The university required a more user-friendly
solution.
While continuing to build on my custom ASP-based CMS, I explored off-the-shelf
options. Some solutions lacked the functionality we needed. Others had far too
many features and a price way out of Vanguard’s range. I couldn’t
find a system that was “just right.” Specifications for the new CMS
included the ability to:
- Write flawless HTML and/or XHTML
- Add tables, pictures and other complex page elements without learning HTML
- Easily add rich media
- Auto-strip proprietary HTML and MS-XML from pasted MS Office documents
- Be easy to use (i.e., no technical ability required and little or no learning
curve)
I found nothing that could meet that challenge until I came across Ektron’s
eWebEditPro, a stand-alone, browser-based, WYSIWYG content authoring tool. Unlike
other Web editors such as Dreamweaver, FrontPage, or GoLive, this editing tool
is designed specifically for use by non-technical people. It essentially replaces
HTML <textarea> fields with a word processor-like interface complete with
toolbar buttons for spell-checking, linking, tables, image upload and more.
For under $300, I got a 10-user license and added the tool to my custom CMS.
Just One Problem...
My vision for the site involved adding many more content editors. But as the
lone Web developer on campus, I already lacked the time to focus on enhancing
user experience and building out the site’s infrastructure to handle increasing
visitor traffic. That’s not to mention developing and maintaining an enterprise-class
CMS that offered workflow and versioning for a large and diverse group of editors.
I began a search for another product to meet these evolving needs. Fortunately,
my search for a solution was short. Ektron had recently launched its own CMS,
Ektron eMPower. The application incorporates the eWebEditPro tool, which was
already familiar to the content editors, along with workflow, versioning and
other features I required. The solution was also priced lower than other off-the
shelf systems I had considered.
In preparation for rollout to production, I built a Windows 2000 staging server
and loaded it with MS SQL Server 2000, ColdFusion 5.0, Microsoft IIS and eMPower.
My decision to use ColdFusion (CF) did not come easily, because I had bought
in to the stereotype that CF did not scale well. After testing CF for a few
weeks though, my concerns were gone. It scaled just fine, and more importantly,
because of CF’s approach to writing code, I found an answer to my ongoing
problem of not having enough time to write complex applications.
With a baseline staging environment in order, I built templates with Vanguard
U. graphics and other page code to hold the eMPower content blocks which would
be served from the database. I then began transitioning content from the production
site into the SQL Server database using eMPower’s GUI.
Populating a database with HTML content, linking templates to user groups with
multiple levels of user permissions, adding style sheets and tracking all content
locations can be a nightmare, but with eMPower I literally created a new page
in the CMS, then copied content directly from the current production Web site
and pasted it into the editor. Every page element, including tables, pictures
and links were rendered perfectly in the editor, and it even re-wrote the code
into XHTML for me. All I had to do was save it. The content was automatically
placed in the database and tied to the template and user permissions I had assigned.
Writing the templates, building out production servers and transitioning 900
pages into the CMS took about 3 months. When I was finished, I had a completely
dynamic site that could be updated by anyone, and the total software cost was
under $20,000.
Some Interesting Effects...
While I was forecasting Web site growth due to the CMS, I didn’t anticipate
an explosion in the number of pages, content editors and visitors. In July 2001,
Vanguard’s site had 900 pages. As of July 2002, the site had over 2,500
pages, an average of 140 new pages a month. In July 2001 there were three content
editors. A year later there were 40. And by fall 2003, I anticipate 75+. In
2000, the site averaged 15,000 visitors a month. In 2002, that number doubled,
with a recent record-high of 40,583 in April. Admissions applications have risen
35 percent from August 2000 to August 2002.
With Vanguard’s enterprise-class CMS package in place, I can now teach
university staff and faculty “how to fish” rather than just “giving
them a fish.” I have no concerns about bad HTML, rogue scripts, or someone
inadvertently changing the look and feel of the site. I can turn people loose
to build out the site’s content while I focus on building back-end and
middle-tier features to improve the site for visitors, faculty and staff. Recently,
I rolled out a new search engine and added hardware to handle increasing visitor
traffic. I’ve also developed a custom press release application that functions
seamlessly alongside the CMS.
While it’s impossible to overstate the difference to my job and the benefits
to our Web site since the transition to our current CMS, the work is not yet
finished. I have drastically reduced time spent training Web editors and the
time it takes to update the site, but some departments are already “maxed
out” with other work and don’t have time to perform routine site updates.
The idea of a Web-centric marketing plan is also still percolating through the
university. These two issues, and others, require further work so that the CMS
fits better into our particular campus culture.
Content management systems provide powerful functionality for Web professionals
to Web-enable people across an organization, allowing them to take a more active
role in optimizing the value of the Web site. I will keep evangelizing about
Web site value, while working toward a realistic content management process
for faculty and staff. None of this would be possible without the CMS at our
disposal. Everything has indeed changed.
|
Is it Better to Buy or Build?
Building may be the right answer for some, especially if there’s
concern about limitations associated with locking into a “do-it-all”
out-of-the-box product. Custom-development, however, can take a substantial
investment of time and money. If you’re considering the “build”
option — whether in-house or via contract — be sure to evaluate
the investment of time and money associated with developing a custom system
and the flexibility it will offer in the future. Some CMS vendors now
offer a “component-based” approach, where the CMS d'es not dictate
the site’s infrastructure. Instead, the CMS is a building block for
the site. This building block offers core CM functionality, then functions
with the site’s business logic and other third-party components (for
e-commerce, Web trends analysis, site/page speed, etc.).
If you’re looking for an off-the-shelf system, remember CM systems
vary widely. Carefully define the scope of what you need, then shop for
a system rather than letting the shopping experience dictate a full line-up
of “requirements.” Academic institutions often require a core
set of content management functionality. Many CMS’s include features
that you may consider “nice” but aren’t “necessary.”
These tend to inflate the cost. So shop cautiously.
|
