Vanguard University: Streamlining Campus Web Publishing

• By Andrew Kenney
• 09/26/02

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.