Back in January, I had the pleasure of presenting at the OLA Super Conference with Catherine Baird, our Marketing, Communications and Outreach Librarian at McMaster, and Greg Senemma, Electronic Services Librarian at Wilfrid Laurier. Our goal for the session was to cover 3 different uses/installations of drupal (our library website and intranet at McMaster and the Laurier Library website). The three projects all differered in subtle ways, from our experience with different versions of the software, to the parametres we were working with for each of the projects, which lent itself to some fruitful comparisons and discussion. Our slides for the presentation are here. If you’ve been following along with the recent series of drupal-related posts on this blog, you might want to have a closer look at the last couple of slides, which effectively cover everything I said I’d cover in the final post of the series which never ended up getting written (lessons learned & must-have modules). Forgive me?

The other cool drupal-related thing that has gone down in the last couple of weeks was, of course, drupal4lib camp! Part of my excitement for the day was, admittedly, about being in Darien’s fabulous new building, which is decked out with all sorts of technology goodness, like the digital signage you see in the image on the left, but also the fun-to-watch self-check-in machine. It is obvious that they put a whole lot of thought into getting things right at Darien — from the technology to the staffing model and services — and walking through the building, witnessing the patrons interact with the staff, collections and space really illustrated just how right they got it.

The camp itself went quite well. I had some excellent conversations with other library drupalers during the course of the day that confirmed that people were learning good things and making important connections. I think the general feeling at the end of the day was that the camp should become an annual event, and I take that as a sign of success!

Right. Sorry about the delay in getting back to this series of posts. You might remember that in part two, I talked at length about the wonders of CCK. The one thing I wanted to pick up on in this post (to round of the CCK discussion) is how CCK makes site administration a lot easier.

If you’re already sold on Drupal, I probably don’t need to tell you how advantageous it is to separate your site’s content from other elements like design, architecture, and navigation. Indeed, this is the promise of most content management systems. CCK facilitates that by allowing you to build input forms that your content folks can use to create pages really easily. So, when a content editor logs into the site, he/she sees a form with clearly defined fields to fill in, which is so much better than being confronted with one large input box in which to dump the entire contents of a page.

The other neat thing about CCK is that it works with Drupal’s permissions to allow you to control access around content type. To pick up on the subject guide example I used in part two, you could grant your subject/liaison librarians permission to create and edit the subject guide content type (and any other content type that is pertinent to their work). Setting up permissions around content type means that when your content folks log into the site, they will be able to edit and create just the content types you have given them permission to edit and create (nothing more or less). At my library, this comes in particularly handy since almost everyone is responsible for some content on the site (for real).

Now, it would be remiss of me not to come clean about how long it took me to come up with this little scheme to manage permissions on our site. I won’t tell you how many sleepless nights (seriously) led to such a revelation, but suffice it to say that this did not fall into place seamlessly for me. Which is not to say that I invented the notion of controlling permissions based on content types (I, most certainly, did not), nor is it to say that this is the only way to control permissions on your site (it isn’t), but this is what I’m using for our site (along with the Account Types module) and it is working fairly well. If you’re administering permissions on Drupal using some other method, I’d love to hear about it.

OK, next up: a final wrap-up post on other must-have modules and some overall lessons learned. It shouldn’t take me another month to get around to it (as it did with this post), but, you know, no promises.

If your answer is “yes”, you’re going to want to attend the drupal4lib camp in February! It’s conveniently scheduled the day after Code4Lib ends, and is generously being hosted by Darien Library which, I hear, is a quick train-ride away from Providence. Props to Karen Coombs for taking an idea we came up with in the hallway during Internet Librarian and making it happen. And a huge thank you to John Blyberg and Darien for stepping in and offering to host it. Here’s the official announcement & link to sign up (note: it’s filling up fast so register soon if you’re planning to join us)!

So, say you want to create subject guides on your drupal-powered site. You could use the standard “page” template that comes with the basic install. A page is pretty simple and looks something like this (on the back-end):

Nothing fancy really, it’s pretty much like any other form you might expect to see in a CMS. In our subject guide example, you’d put all your content in the “body” field and that would be that. Which is just fine, but wouldn’t it be better if your subject guides had fields that matched your content? If it did, it might look something like this: (again, on the back-end):

Creating templates like this is what CCK does. With CCK, you’d create a new content type (call it “subject guide”) and then define what fields you’d like to see on that guide. While it probably looks like a lot of work to create custom content types when a simple page template might do the trick, I’d say it’s worth it for a number of reasons:

• custom searches: with the example above, your users can choose to just search your subject guides (or any other content type you define).
• feeds: you can generate RSS feeds for any (or every!) content type so your users can choose to subscribe to the feed for just your subject guides (for example).
• content display: because your content is pieced out into different fields, you can choose to display the data from any of those fields in different ways. For example, if you’ve created subject guides for every subject in the Humanities, you can generate a list of all the article databases in the Humanities by creating a view that lists the content in the “article databases” field. With the Views module, you can customize the way your pages display just about any way you’d like.
• admin: CCK makes site admin easier for a lots of reasons, ranging from making it easier for content contributors to add content to your site to making user permissions more manageable.

I’ll pick up on the admin stuff in my next post, but for now, I’ll leave you with a list of the custom content types we’ve defined for our site. This might be of limited value since some of these are pretty specific to my library, but I would have loved to have seen similar lists when we were developing our content types (and when I went hunting for them, I came up empty). So, here you go!

• Archive Exhibitions – for “exhibits” pages for Archives & Research Collections
• Classrom Directory – for records that file into the Classroom Directory
• Classroom Audio/Visual Services updates – blog-style posts on the CAVS pages for ‘Professional Activities‘ and ‘New Technology in the Classroom‘
• Collections – for new pages in Collections Services
• Collection Policies – for new collection policy pages
• Department Contact – for new department contact records
• Equipment Information – for pages detailing a piece of equipment for the Computers, Copiers, etc. section.
• Event – for new events that will be added to the Library Events calendar
• FAQ – for new FAQs
• Find Articles – for article databases
• Geospatial Data – for new content for the digital geospatial data section of Maps/GIS
• Government Publications Guide – for gov pubs guides
• How to Find Page – for new pages in the “how to find…” collection of guides
• Library Committee – a page for library-related committees
• Library News – for new posts to the library news & events blog
• LSSD – for new pages in the Library Services for Students with Disabilities section of the site
• Page with image header – for pages with a large image header
• Page with multiple images in header – for pages with refreshing images in header
• Policies and Regulations – for new pages for in the Policies and Regulation section
• Staff Page – for new staff pages
• Study Space – for new study spaces
• Subject Guide – for subject guides
• Webform – for new contact forms or questionnaires

Next: on drupal, part three.

Drupal modules are little (and no-so-little) add-ons that extend the functionality of the CMS. You could happily run a solid website with Drupal’s vanilla install without a single additional module (which I’ve done), but my guess is that if you’re building even a moderately complex website, you’re going to want to explore your module options. When I first started exploring those options a few months ago, I found myself going down an all-familiar path when it comes to new tech: so many cool bells! such pretty whistles! I want it all! But wait? Which of these do I really need? Here’s what I’d recommend: sit down and make a wishlist of everything you want your site to do, in terms of functionality. At first you’re going to want to blue sky it (think everything is possible!) because you’ll have plenty of time later to cull and prioritize that list. Once you’ve got your wishlist firmly in hand, you’ll be ready to turn to that list of modules and figure out which ones will get you there.

When I hit the “which of these do I really need?” stage of module selection, I turned to other library drupalers to help me out. I figured that if another library had used a specific module on their site, I could probably use it on ours. The drupal4lib listserv was especially helpful here, but apart from that, I found little online documentation on what other library drupal sites had used. In the interest of filling that gap just a little, here’s a complete list of all the modules we’re using on our site:

• Active Menu
• Captcha
• Collapse Text
• Collapsiblock
• Comment Mail
• Contemplate
• Content Construction Kit (CCK)
• Custom Breadcrumbs
• Aggregator
• Comment
• Devel
• Devel Node Access
• Elements
• Event
• External Links
• Faceted Search
• FCKEditor
• Frequently Asked Questions
• Google Co-op CSE
• Heading Anchors
• Help
• Iconizer
• ImageCache
• IMCE
• Insert View
• JavaScript Tools
• jQuery Update
• Lightbox2
• Links
• NeighborForge
• Menu
• Nice Menus
• Node Field Indexer
• Node Import
• Panels
• Path
• Pathauto
• Poll
• Profile
• Search
• Search404
• Service Links
• Statistics
• Table of Contents
• Tabs Example
• Taxonomy
• Upload
• Views
• Webform
• XML Sitemap

Yes, that’s a lot of modules, but that list is actually relatively short compared to what it could be (there are thousands of modules out there, folks). Next up: more module-goodness, specifically CCK!

Update: continue to on drupal, part two

I had to skip out of the second half of the session to present in a project management workshop (“Project Management in Practice”) with Helene Blowers and Macrina Williams, moderated by the awesome Mary Auckland. Let me just tell you, Helene Blowers is the best ever person to present in that dreaded post-lunch timeslot — she energizes the room like none other! It ended up being a really fun session with a lot of good conversation around the challenges we all face working on projects in our libraries. Not surprisingly, we all shared a lot of the same challenges, regardless of what type of library we work in. The angle for my part of the session was the “one-person project management team” and my slides are here.

The last official thing I did at IL was a little session called Drupal 101. When you click that link you’ll see a bunch of intro slides on Drupal (fulfilling the “101″ part of the session title), but I pretty much skipped over those and spent my 15 minutes imparting some lessons I learned from working with the software over the last 8 months. I was pleasantly surprised that over half the attendees raised their hands when I asked if they had already installed/played with Drupal, so I thought I’d capitalize on that, skip the basics, and talk about the things I wish I’d known 8 months ago. Since that session, I’ve remembered a few more things I should have mentioned, so I’m working on brain-dump post on that. Anticipate!