Building a Competitive Web Strategy for an Academic Site

• By Trent Batson
• 05/21/08

In the following fictional scenario, we examine a typical department's struggle to redesign its Web presence:

Our department is re-thinking what our Web site should do. We can't help but notice that social sites like YouTube and Facebook are awfully easy to use. We also notice that we go to Google every day and find what we want in a few seconds.

 
Why can't our academic site be more like them?

When we look at our university home site, we see that there is information that our own constituents need. We are an academic site and not a business. And, does anyone use our Web site? Why do we have it at all? This is not 1998 when everyone, seemingly overnight, had to have something on the Web. Now, that something seems to be not enough. Also, we ask, when is new stuff put up?

And what can anyone actually "do" on our departmental site?

So, we check into ways to update our site more frequently and to add some functionality. And, while we're looking at how the site works, we re-consider our graphic design, wondering if it really looks up-to-date. After some study, a tentative plan begins to take shape:

Our current site has history, and some sites we maintained years ago have been abandoned longer than we thought. We decide that our first effort is to re-claim those sites through a re-direct while making sure no information from those sites is lost. The current site is familiar, is actually comprehensive in its scope, and, even though it's pretty much display-only, represents a certain departmental presence that we don't want to sacrifice. As part of our planned new mix of Web assets, we decide to keep the display-only, "academic" site.

To maintain the currency of this site, however, we realize we'll need a simple authoring system of some sort. One option: A person can dedicate 20 percent time (we're just a department, remember) to publish to the site with an editor, FTP tool, and some layout tools. Yet, even with this improved traditional Web publishing system, the result is still a non-services-oriented site. We haven't yet answered the question, "What can our constituents 'do' at our site?"

And to go to the next step we need an actual Web content management system. We're looking at downloading Drupal, WordPress, Joomla!, or another open source Web content management system. That gets us into the open source LAMP stack, so we wonder who will maintain the Linux, Apache, and MySQL servers (though WordPress can also be a hosted solution). Which do we choose? Drupal is really intriguing for all it can do, but is a challenge to deploy. Joomla! seems easier as you start, but we're not sure Joomla! can handle our eventual departmental demands.

WordPress may be just Goldilocks perfect -- neither "overkill" nor bound by limitation. Since our libraries use WordPress already, we give some thought to this option and think WordPress could serve as a nice supplement-site for our static site. WordPress in the Pages mode is a bit more than a widget or a plug in, so now we find ourselves thinking of maintaining a growing suite of technologies. And, of course, still considering throwing into the mix various downloadable Web services.

Adding to our challenge, there are those social sites that prompted us to start thinking about our site and its limitations to begin with. If we want to be au courant, we need to add a social site or two within our site. We consider Ning as one of the options. Does it have security settings appropriate for us? Or do we need access to the code? This question seems to come up with a number of sites we look at.

Finally, we hope to develop a useful library of resources for our constituents, so we need a good archiving tool. One possibility is an ePortfolio tool such as Digication, which was designed to help students publish and manage rich media objects. Summing up, we're considering this array:

 - A static site maintained the traditional way while we work on ramping up our functionality; the static site may persist even after we add other Web capabilities.

 - Dynamic parts of the site managed by a content management system.

 - Social interaction parts of the site supported through various social sites in Web 2.0.

 - An ePortfolio system for our digital archive.

This level of commitment is justified if our Web site adds to the capabilities and services of our department. We're still talking . . .