blogwithoutalibrary.net libraries, technology, UX, &c.

on drupal, part three

[Start here. Then go here. Then come back here.]

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.

want more drupal?

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)!

from the “celebrating our failures” dept

This is from a design/marketing/communications company’s website. I love how they’re not afraid to showcase ideas that didn’t fly:

Think of this as the final resting place for ideas that - for one reason or another - lacked sufficient postage. The road to change is littered with them.

You can’t have innovation without failure, right? I’d love to see libraries celebrating their failures more. If you know of a library that does this, let us know in the comments!

on drupal, part two

If I had to pick the single most useful module out of that whole list, it would be an easy choice: CCK. It’s a super-powerful module that allows you to define content types across your site and create custom fields for those content types.

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.

on drupal, part one

If you want the basics on Drupal, you could do no better than to spend some time combing through the project’s website. Actually, scratch that, the one thing you could do better than combing through the website would be to grab the software, install it, and mess around with it for a bit. It’s easy to use, robust, and super-highly configurable. Once installed, it’s pretty easy to get a feel for the software (especially if you have some familiarity with CMSes, even simple ones like WordPress), so I’m not going to spend any time on the basics. Instead, I figured I’d jump right into how it worked (and how I forced it to work) for me. As I’ve mentioned more than once over the past few weeks, I built my library’s redesigned website on Drupal and I have more than a few things to say about the experience, so I thought I’d piece it out into a series of posts. First up, let’s talk modules.

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