Skip to content Skip to navigation

Moving from Static HTML to Drupal

Posted by: 
Topics: 

by John Bickar, User Services Technology Specialist, Cubberley Education Library

In the summer of 2007, we changed the website at Cubberley Education Library from static HTML to the Drupal content management system (CMS). This page details some of the decision-making, strategy, and implementation of that move. Although it describes the process for a branch library website, some of the process is generalizable to other conversions.

Why Move to a CMS?

The University of Missouri has a handy guide to the Pros and Cons of moving to a CMS.

Why Drupal?

Drupal is very well-supported on the Stanford campus and within SULAIR. It has many other advantages as well (it's extensible, it has a very active development community, it has a robust architecture, and so forth), but what seals the deal is that there's a very active support community at SU.

Background Reading

  • The Elements of User Experience: User-centered Design for the Web, by Jesse James Garret. This is a short book (~175 pages), but it provides a very clear framework for designing for the web. The "5 Ss" that I reference below (strategy, scope, structure, skeleton, surface) come from The Elements of User Experience. It is available at the Jackson Business Library.
  • Information Architecture for the World Wide Web, by Peter Morville. A bit longer than The Elements of User Experience, IA for the WWW provides an extensive background in Information Architecture. This is an O'Reilly Publishing book, available at the Math/CS Library, and online via Books 24x7.

Planning the New Site

Our (modest-but-achievable) initial goal was simply to replicate the existing functionality of our static site. Even if that's all that we accomplished, it would have been worth the work, because Drupal provides:

  • Improved search
  • Improved workflow for content authors, which means:
    • More timely, updated information
    • Less ROT (Redundant, Outdated, or Trivial information)

However, the limitation of this approach is that it can lend itself to perpetuating bad design that exists in your current site. Use the redesign process to reconceptualize the services that you provide via the web, and plan how to provide them better.

Timeline

Our website was relatively small (~75 pages), and it took me approximately ten weeks, working largely by myself, full-time, to complete the conversion. Your mileage may vary. My initial timeline had the first five weeks scheduled, and the last five weeks largely unprogrammed to deal with eventualities. I made one huge omission in my planning: actually getting the content into the Drupal site. Be prepared for that to take a couple of weeks.

Week 1

Strategy

  • Define Objectives
    • What do we want to get out of this site?
    • What do our users want to get out of this site? (Hint: Ask them!)
  • Define Who, What, Where, When, Why

Scope

  • Inventory Existing Content
  • Identify Content Deliverables
    • Links
    • Item records
  • Identify Services
    • Reference Pages
    • Tutorials
    • News

Week 2

Scope (cont.)

  • Categorize Content
  • Choose Representative Sample to Include in Mockup

Week 3

Structure

  • Information Architecture
  • Taxonomy - Controlled and Free
  • Define and Articulate Matrices

Week 4

Structure (cont.)

  • Create Content Types and Metadata
  • Bottom-Up and Top-Down
  • Apply Vocabulary Terms to Content

Skeleton

  • Navigation Design
  • Search and Browse
  • 2-Column or 3-Column
  • Wayfinding

Week 5

Surface

  • Visual Design (Theming)
  • Colors in Support of Information Design and Wayfinding
  • Consistency
    • Internal/External
    • Old/New

Week 6-8

  • Add the Content to the New Site

Week 9-10

  • Finalize and Test

Usability Testing

I like to think outside the box, so I used the book Usability Testing for Library Websites as a reference for usability testing (crazy, I know!). This was a process that we undertook after the site went live. Here is a summary and the full results.