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."
Reply
Drupal4libcamp
February 27, 2009, Darien Public Library, Darien, CT
This work is licensed under a Creative Commons Attribution- NonCommercial- ShareAlike 2.5 License.
Users, roles, and subject guide stresses
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."