Home

Simon Fraser University Library

Tue, 2009-04-21 19:22 — mark

Description

Simon Fraser University Library's new Drupal site. Same look and feel as previous site, but with better content maintainer tools (no more Dreamweaver), more consistent structure, and better management tools. We have over 50 content maintainers and over 1500 pages.

Modules used

Zen-based custom theme based on university's look and feel.

Contrib modules: cck, views, fckeditor, date, formdefaults, nice menus, node_clone, override_node_options, path_auto, token, token_custom, upload_path, user_import, webform, workspace.

Custom modules:

  • sfutweaks is a general site-customization module, where we do miscellaneous overriding functions using form_alter(), etc.
  • sfucontext provides content authors with a select list that allows them to place their page in a specific "context", which is a combination of URL path and breadcrumb trail.
  • sfuwidgets provides simple token-based 'widgets' that allow content authors to insert complex HTML snippets into their nodes without needing access to the raw HTML. For example, [[rss http://rss.example.com/feed.xml 5]] inserts the latest 5 items in the feed http://rss.example.com/feed.xml.
  • We also wrote a PHP script that included the Drupal bootstrap, which we used to migrate pages from our old site into Drupal.

Some features of note:

  • When we imported pages from old site, we assigned the old URL as a node alias, which means that links to the previous URLs route users to the new, shorter ones. This is a really nice technique for minimizing migration-induced link rot.
  • The migration script also used HTMLTidy to clean up some of the legacy code as we pulled pages from the previous site. We had been using Dreamweaver for a number of years and a lot of inconsistent CSS and inline formatting tags infested our pages. The new version of the site looks a lot cleaner and more consistent.
  • We have configured our subject guides, which comprise a large part of our site, using tabs (example). We have also used tabs on other groups of related pages on on our two branch home pages. These tabs are actually Drupal menus. Content maintainers must ask the site admins to create the tabs/menus.
  • We customized fckeditor quite a bit, including some custom document templates and styles. It was very important for us to make it easy to create and edit new pages, and feedback from our content maintainers so far has been very positive.
  • Homegrown services like our FAQ database and our what's new tool were easy to convert to CCK content types. We also migrated the rotating images and text on the homepage from a feature that required logging into the web server and editing text files to a CCK content type, maintained with the same familiar editing tools other content on the site is maintained with.

During the migration, which we started in November, we used a separate instance of Drupal for our project management tool. This site provided an issues and decisions tracker (created using CCK and Views), and allowed us to install and test modules we were interested in using, test specific configurations, and try out theming ideas. We posted our weekly agendas and minutes there as well and blogged useful ideas picked up from other Drupal sites. Using this instance of Drupal also allowed members of the migration team to become familiar with administering a Drupal instance. Overall, we found using this site a useful part of the project.

Comments

Mon, 2009-04-27 11:36 — Yvonne Chan (not verified)

staff & time resources

Hello Mark,
Congratulations on the new Drupal site!

At UBC Library, we are considering using Drupal as well and have started experimenting with a number of contributed modules. It is encouraging to learn that you had such a positive experience :)

Wondering if you could share with us details regarding the time and manpower required to create the custom modules and features to complete the migration project? What are some of the challenges you encountered, if any?

Thanks in advance.
Yvonne Chan, Web Technology Coordinator, UBC Library

Mon, 2009-04-27 21:35 — mark

Hard to be specific

Hi Yvonne,

It's difficult to be specific about how much time it took since we decided to spread it out over a rather long period, and all members of the team had other duties during the project. There were three people on the implementation team, our web developer Todd (who did the custom modules, theme, migration scripts, system architecture, etc), our systems librarian Nina (who mapped the migration from the old site to the new one, paid attention to user [content maintainer] experience, and performed user testing and training on the new editing tools), and myself (project lead, Drupal evangelist, worrier, and reporter up and across the org chart). The assistant head of Reference led a parallel task group that came up with the structure for our site's subject guides and Nina was part of that group as well. Several other staff from Systems assisted in various incidental ways with the project too.

We started the project in November by surveying the existing site and figuring out how we were going to map its rather byzantine structure into Drupal. Todd and I came up with the idea of the 'context' module, and Nina started mapping the old file system structure into the new URL-and-breadcrumb based context structure in a large spreadsheet which Todd later used as the input for his migration script (actually, he generated a rough version of this file by writing a script that listed every .htm file on our old site and Nina transformed this into the migration list).

We then moved on to user experience questions like how were going to implement tabs, page component templates, and styles; migration issues like how were going to handle files attached to nodes and whether or not we were going to support redirects from the old site to the new one; and organizational/political issues like how were were going to accommodate the variations in layout/navigation that our two branch sites had developed over the years (their sites are subsites on the main Library website).

During the migration work, we took the opportunity to clean up our wider web environment. For example, our old site had become home for a large amount of vendor content such as CD-ROMs full of art images, raw data files from business information vendors, and some locally digitized collections. We moved all of this content to other servers. We also cleaned up some apache configurations such as redirects that had accrued over the years. So, the estimates below include this work, which was not directly related to our migration to Drupal, although it was necessary because we were moving to a CMS and away from a standard file-systems based web site.

From December to March we had weekly meetings averaging about 2 hours. I'd estimate that we each spent 2 days a week on the project in November - February and 3.5 days a week in March and the first week in April. We migrated the content from the old site to the new on April 14 and spent pretty much the rest of the week on the last manual tasks in the migration, like setting up tabs, menus, and the branch subsites.

Those are very rough estimates but they are probably as accurate as I can be, since we didn't track our time. I'm happy to say that we actually went live three months earlier than we planned to. The timing was convenient since a lot of librarians were at the provincial library conference and it was therefore easy to arrange for a moratorium on site updates during the migration week.

One factor that decreased the amount of time our migration could have taken was that we didn't redesign the look and feel of the site. In the past redesigning our look and feel has proven to be very time consuming at our library, and not having to think about or consult on cosmetic issues or significant content reorganization saved us a lot of time.

Challenges:

  1. Management of files attached to nodes, such as images and PDFs, is awkward. You can organize files by user ID pretty easily but that wasn't going to work on our site, as subject librarians change ownership of pages fairly frequently.
  2. We couldn't find any ready-made solutions to provide our content editors, who were used to saving their pages on a file system with a directory structure, with an easy way to choose what "context" their pages go into. You will need to figure out how you want to use some combination of path auto, breadcrumbs, taxonomies, etc. to let your users organize their content.
  3. Accommodating subsites that have themes or navigation mechanisms that differ from the main site is difficult.

    4. One more challenge was that on the day we launched, we noticed that the server was being taxed quite a bit more than we anticipated. We had done some benchmarks to test Drupal's built-in caching options, so were a bit surprised that the server was struggling a little when we went live. Since our server was a VMWare virtual machine, we were able to add a second CPU and double the RAM to 2 gigs. We also turned on mysql query caching, which we believe improved response time. After making these changes, we are now seeing resource utilization that is comparable to our previous web server. We'll be doing some additional stress testing during the summer so we are prepared for the September crush.

Wed, 2009-04-29 13:51 — Yvonne Chan (not verified)

Thank you

..for the detailed and useful info. Pretty amazing to achieve all these in 6 months.
Cheers,
Yvonne

Wed, 2009-05-20 09:32 — Virginia Franklyn (not verified)

Subject Guides

Hi Mark,

Great website! I especially like your Subject Guides (http://www.lib.sfu.ca/help/subject-guides/chemistry/home). We're looking to do something like that at Pikes Peak Library District. I was wondering if you could elaborate on how you set these up? I'm still kind of a newbie, so the more details, the better.

I suspect you used different content types for the content in each tab and created a View for each content type that you linked to the tab. However, I'm not sure how you did the tabs themselves. I've been working with Quick Tabs module. Is that the way you went?

It might be something very simple to do, but my confusion mainly revolves around the tabs feature and how you did it.

Anyways, great job!

Thanks for your time,

Virginia Franklyn
Pikes Peak Library District

Wed, 2009-05-20 10:50 — mark

Tabs are just styled menus

Hi Virginia, thanks for the feedback. The tabs are simply menus, styled to look like tabs.

Wed, 2009-05-20 12:08 — Virginia Franklyn (not verified)

Thanks for your prompt reply,

Thanks for your prompt reply, Mark. Did you create a separate menu for each subject guide? Also, did you style it in the corresponding tpl.phps, then?

Thanks for taking the time to help a newbie...

Cheers,

Virginia

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <em> <strong> <h3> <h4> <h5> <h6> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <blockquote>
  • Lines and paragraphs break automatically.
  • You may post code using <code>...</code> (generic) or <?php ... ?> (highlighted PHP) tags.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Use [toc list: ol; title: Table of Contents; minlevel: 2; maxlevel: 3; attachments: yes;] to insert a mediawiki style collapsible table of contents. All the arguments are optional.

More information about formatting options

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
  ____           __  __  ____     ____         
 |  _ \  __   __ \ \/ / / ___|   / ___|   __ _ 
 | |_) | \ \ / /  \  /  \___ \  | |  _   / _` |
 |  _ <   \ V /   /  \   ___) | | |_| | | (_| |
 |_| \_\   \_/   /_/\_\ |____/   \____|  \__,_|
Enter the code depicted in ASCII art style.