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.
Reply
Drupal4libcamp
February 27, 2009, Darien Public Library, Darien, CT
This work is licensed under a Creative Commons Attribution- NonCommercial- ShareAlike 2.5 License.
Moderation roles in Drupal site for kids
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.