drupalib A place for library drupallers to hang out

Users:

Subject librarians in my library are responsible for providing general reference desk service in addition to their subject duties, which include managing the collection in their areas, coordinating with central collection services, providing subject-specific reference service to faculty and graduate students, providing training sessions in research in their areas, and coordinating with departments and individual faculty members on library-related issues. These duties are probably typical of those performed by subject librarians in other academic libraries.

Tasks:

1) Create and maintain subject-specific research and resource guides. In my library there is no "template" for these guides but most librarians focus on identifying important and useful resources in a subject area, including abstracting and indexing databases, fulltext journals databases, quick reference information, type-specific resources such as maps, raw data, statistical sources, image databases, government information, etc. Some guides include information on research assignments for large undergraduate classes, information on style guides, and detailed coverage of popular or recurring research topics/issues.

Specific user tasks: In addition to creating and maintaining the textual content of these guides, subject librarians want to include aggregated news feeds in their guides, dynamically generated (i.e., from other parts of our website) lists of databases, dynamically generated lists of new items from our catalogue in their areas, and contact/social networking tools such as meebo and other IM/contact/networking tools into their guides. The guides can be large, complex, frequently update, and can contain tables of contents and other types of internal navigation.

2) Create and maintain workshop/course-specific content. As part of delivering training sessions and workshops, subject librarians often develop content that describe and organize the resources used in the session, provide sample topics and possible research strategies, and provide exercises. These sessions are sometimes tailored to a specific academic course at the request of the faculty instructor, often at the graduate or advanced undergraduate level. In many ways this content is a type of highly focused subject guide as described in section 1.

3) Create and maintain detailed resource- or tool-specific guides. Some subject librarians maintain how-to guides and other types of procedural or explanatory content dealing with specialized databases, client software, and complex print resources (although the latter is becoming far less common as these print "databases" move online). This type of content can contain a lot of screen snapshots, numbered lists, decision tables, and other explanatory aids.

4) Maintain subject-specific blogs. Many subject librarians maintain blogs on their subject areas, where they post brief entries on new resources, links to news items of interest to researchers, announcements of training sessions, new library services and events, conferences reports, etc. Most standard blogging applications suffice for these blogs, but one feature that has been requested in my library is that users should be able to select whether they search only the blog they are currently browsing or search all subject area blogs.

I work at an academic library, and we have moved our subject guides (formerly static html pages) into Drupal. I am the Drupal site administrator (though not a subject guide author). Here are my notes about different types of users.

Drupal Subject Guides - Users:

a) Drupal site administrator - responsible for site configuration, organization and design. Limited responsibilities for creating/maintaining content.

b) Subject guide author - responsible for the factual content of the guide.

c) Subject guide maintainer - responsible for editing content within the Drupal system -- writing HTML, categorizing & linking content together, etc.

Most subject guide authors and maintainers are responsible for multiple guides (around 2-10).

With our Drupal-managed subject guides, the subject guide author (a public services librarian) sometimes does (and sometimes doesn't) act as their own maintainer. In some campus libraries, a library technician acts as the maintainer. In these cases, the guide author will send emails/ms word documents listing their content changes, which are then updated to the website by the editor. Many of our Drupal users (who have input & ideas about how Drupal should manage and display content) never "log in" to Drupal.

When I configured Drupal to work for publishing Subject Guides, I put a lot of effort into reducing the need for 'duplicated' content. For example, subject guide metadata, librarian contact info and research database information are stored as nodes that are reused on multiple subject guides/pages. This attempt at efficiency later presented some problems:

1) It makes more a more complicated system that is difficult to master... maintainers sometimes have difficulty figuring out what node they need to edit to change the content on a given page (e.g. "Where do I go to edit the 'librarian profile' information that is displayed on this page?")

2) It makes for a more restrictive system, with less flexibility for intentional content variations (e.g. a librarian can't have different contact information for different subject guides... in rare cases this is desired).

3) When the author does not serve as the maintainer of the guide, they do not directly experience the benefit of reduced duplication of information. They never had to do the work of keeping their email address up-to-date on 40 different web pages. Instead, they only directly feel the restriction of having slightly less flexibility over the factual content of their data (e.g. now they're restricted to keep their contact info the same for every guide).

As the project lead for implementing Drupal for Subject Guides, I experienced many headaches when negotiating the different needs of different types of users (including my own needs as a the 'site administrator' user). While discussing Subject Guide content management at a library tech conference, one systems librarian chipped in -- "We just went ahead and got them [public services staff] LibGuides, so that we [systems staff] don't ever have to worry about Subject Guide content again... they can just go off and do their own thing."

We maintain a nifty kids' website built for us in Drupal that lets young-adult members of the library post book reviews, create word mazes, quizzes and write imaginary "lost chapters" about their favourite books. Each user can create a book club and link to the book clubs of others to keep track of what people are reviewing.

For library staff, the roles and tasks are:

Book club owner: exactly the same Drupal permissions as a child member, with the ability to post reviews and other book club content. A reviewer begins by searching for a title, which if it has been reviewed before will have an existing node linked to the title's ISBN (which pulls in cover art), which in turn links to book club content nodes for that title. If new activity has taken place around the title a new ISBN node is created. Unfortunately, for a staff book club member who is also a content moderator (see below), the admin link "create content" is also present, which I haven't been able to disable. A staff person who creates a book review through that link will receive an error because they haven't linked the review to an ISBN first. Another symptom of Drupal's flexible architecture but inflexible interface.

Content moderator: Staff who are designated to review all content before it is posted. (This is an important factor for us, because the site is designed for kids and web safety is paramount.) We recently switched from the native Drupal content review process to the Moder8 module, because the latter decreases the amount of clicks moderators need to be actually able to read the content. As far as I'm aware, moderation functions have been going smoothly. The system includes a word filter to prevent posts with obscenities from making it into the moderation queue, which makes the moderators' task somewhat easier.

Book list creator: In theory, staff are also able to create lists of recommended titles, but this task has so far always fallen to a few of us in the Web Systems department who are reasonably comfortable with Drupal's admin interface. Up to now this has mostly been because we've needed to create bilingual lists, and the handling of French titles hasn't been as good as it is now with a recent set of improvements. I'm hoping children's and acquisitions staff will be able to take over this task in the near future, although I suspect we admins will continue to manage this, because the task crosses the threshold from relatively straightforward text entry into the minefield of Drupal's admin interface, albeit with the relatively benign tasks (to us) of searching for titles and pressing some radio buttons. Again, this function has been built on top of the Drupal architecture, so there are extra clicks where there really shouldn't be, but which have been adapted from Drupal's native content handling.

In general I've had to get around some vagaries of the Drupal system by telling people "don't use that link" in the case of "Create Content" and taking on tasks as the site admin that staff don't have time or patience for, namely recommended reading lists. We urged our developer to build using Drupal because we planned a switchover of our main website and wanted both sites to eventually play well together. And the usual proviso: we love Drupal! It's a bit like a St. Bernard -- lovable and eager to please, although with a bit of a bladder problem that gets embarrassing in polite company.

In our new site planning, I'm hoping to use Views and CCK to build custom content forms for staff, although I can foresee similar issues of an efficient but inflexible data model that Wendy speaks of above, and can envision some staff wanting to manipulate feeds via blocks in a simple way in the manner that Mark describes. Overall, we've successfully sold Drupal as the platform of choice to our decision makers, but these sorts of detailed functionality questions are going to come up. Ideally, Drupal should have a complete usability makeover, but in the meantime perhaps we as developer/admins should be managing expectations about what the platform does and does not do well.