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

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!

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

So it was with some delight that I read the email about Buley’s virtual seminar on the same subject that’s happening next week. It’s a bit spendy for a one-hour virtual thing, but I suspect that it will be worth it for a number of library design/IA/UX types since, I’m assuming, a lot of us work in our own, cozy 1-person teams. I’ll be there.

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!

So it was with some delight that I stumbled upon Favthumbs. Do the internets really need another del.icio.us visualization tool? Maybe not, but it turns out that this one works for me. Since most of the stuff I’m doing these days is design-based, and being a generally visual person, images tend to imprint themselves on my brain better than words. If I bookmarked your website last week because you’ve done some interesting stuff with search boxes, I can guarantee you that I won’t remember the name of your site or anything I read on your page (rendering a search of my bookmarks fruitless), but I’ll probably remember the colours and layout. So a carousel (à la iTunes) or grid display of my del.icio.us bookmarks, complete with thumbnails, is genius. It’s pretty much exactly what the visually-biased like me need.

On “scent”

• We often start with an hypothesis: people who have a lot of experience using the web will be able to find things easier. The fact? That’s not the case. At UIE, they’ve done a lot of research on why users tend to generally succeed with some sites and they’ve identified patterns (which is what the session is all about).
• The notion of “scent” is all about links that suck users in and get them to the content they’re looking for . It all happens through “trigger words”. Our users come to our websites looking for something (their “trigger words”), so if they can’t find their trigger words, they are immediately disoriented.
• The 3-clicks-to-content notion is something of a fallacy — as long as each click makes the user feel like they are getting closer to the content they need, they generally don’t care how many clicks it takes to get there. As users drill through your site, if the next click takes them to a general page, they lose the scent and they are disoriented.
• Users tend to resort to using your site’s search feature when there is not enough scent. Using the site search is the user trying to create his/her own scent.
• This is not so much the case with sites like amazon (or our OPACs), but generally true for web content.
• Another fallacy: “above the fold”. Users have no problem scrolling. The one thing to keep in mind is the “iceberg syndrome” — i.e. when users believe that everything above the fold is a representation of what’s below the fold.
• You can’t measure the scent of a page, but you can find out how confident your users are as they’re clicking through the site (with some user testing). When scent works, users are more confident.

On trigger words

• When they can’t find their trigger words, users will use the site search. The tend to type in the trigger words they were looking for in the first place, so check your site’s search logs for what those trigger words are.
• If they ask questions (desk, email, im), check what terms they are using. Those are their trigger words.

On scent blockers

• Navigation panels where labels are not easily understandable
• Navigation panels with labels that are not mutually exclusive
• Jargon (hello, “databases”, “indexes”, etc.)

On links

• The stronger the link, the better it will suck users in.
• The best links have 7-12 words in them (wow!). With 7-12 words, users get more information and therefore have more confidence.
• More than 12 words might be too “noisy”, i.e. too many words masking the trigger word(s).
• “Cute” links lose scent (keep it real, yo).
• Don’t incorporate branding into the link because users need to see their trigger words.

On navigation

• Have to use short links by necessity
• Use categories that are clear and mutually exclusive
• Make sure your subcategories give off scent about main categories (i.e. if users can see subcategories, e.g. drop-downs, it will orient them on what the main category is about).

On page length

• Short pages reduce scent.
• Longer pages include more content and that’s not a bad thing — users generally don’t mind scrolling.
• Horizontal rules are a deal-breaker — users tend to stop scrolling because they think it’s the end of the page.

On designing your website

• The link “site map” doesn’t give off scent except to say “here’s where the scent is” - if a lot of people look at your site map (like they use your site search), it’s probably because they don’t get any scent from your home page.
• Websites don’t have “sections” as far as users are concerned. We think of them as sections (as web designers and content folks), but users don’t care about sections. They just want to find their content.
• Designing from a scent-based perspective is better than a navigation-based perspective. Start at the content page and ask: what are all the pages the user needs to be sucked in from? Don’t start at the home page, build your navigation, then build your content pages (not very scent-full!).

On testing for scent

• When watching users use your site, before they click ask how likely it is that they think they will find what they’re looking for by clicking on that link.
• After they click: either they get the stuff they’re looking for, or the scent gets stronger. Ask if this page gets them closer to what they’re looking for.
• You know they’ve run out of scent when they use the back button and/or site search.
• You can’t design a great site without testing — if you don’t watch your users use your site, it’s near impossible that your design will work for them.

This is the text of James Joyce’s Dubliners, which is one of my favourite texts (snagged from Project Gutenberg). It’s also my go-to for when I’m playing with text analysis tools (when am I playing with text analysis tools, you ask? There’s a post in the works on that very topic, stay tuned). Looking at this cloud makes me want to run home, brew up a pot of tea, settle into a comfy chair on the deck, and lose myself in these stories once again (as I’ve done roughly 12-ish times in the past).

In the spirit of meme-ifying this (thanks, Jason!), I’m tagging some work peeps: Shawn, Nick, John, Krista, and Karen.