Hi folks,
I'm following up on promises I made during the Birds of a Feather sessions at Drupalcon Boston to post a case study of how we're using Drupal at Amherst College. We've developed a module to facilitate hierarchical content creation and permission control that's also of potential interest to folks outside of the academic community.
Preamble aside - about 3 years ago the college decided to fundamentally change the way it was approaching the web, and a little over 2 years ago we started building on top of Drupal. The project had some broad goals:
- Find a way to gather together all members of the college community under a common web platform. Faculty, Students, Staff and Alumni were our primary focus, though we've since incorporated applicants.
- Change the way the college creates and manages web content. Amherst had been on the Dreamweaver + templates + department directories with shared passwords (!!!) model. We also wanted to get a consistent navigation scheme and thematically similar templates applied to the upper levels of the college's site.
- Begin dynamically building the academic portions of the college's website. Course listings, faculty listings, course enrollment listings, and more needed to all be delivered out of data instead of built manually by various academic staff and faculty.
- Amherst was disturbed by the legal action Blackboard took against Desire2Learn. We also knew that about 90% of faculty use of Blackboard on our campus was for password protected document sharing. We wanted to move away from Blackboard and replace it with other tools.
A partial list of what we've delivered so far:
Automation of curricular data:
- every academic department has a dynamically produced list of courses built from Datatel/Registrar data - example, Asian Studies
- every academic department has a dynamically produced list of faculty - example, Spanish faculty listing
- every course has a dynamically produced course website with numerous components including course rosters and e-reserves; this is delivered with granular permissions for reading and authoring content for each of the website components. Example - a recent Economics course. A picture of the permission settings for a course:
Image may be NSFW.
Clik here to view.
- every faculty member has a dynamically generated ”CV” page which lists contact info, the courses they're teaching, have taught, and (soon) will be teaching. Faculty can add to this material as they like. Example - Dale Hudson's CV
Every user gets some or all of the following depending on role:
- A customizable and personalized portal that delivers content specific to their role(s) at the college -- examples being readings and assignments for students, news from their classmates for alums, news from the college, etc. A picture:
Image may be NSFW.
Clik here to view. - personal webspace. Example - Susan Edwards' personal website
- professional “CV” webspace if you're an employee, with dynamic content inserted into it (office location, email address, courses taught, etc.). A picture:
Image may be NSFW.
Clik here to view.
- Authoring permissions on the various resources specific to their role(s) -- examples: faculty members can edit their course websites, alums can add news to their class year's news page, department coordinators and staff can edit departmental websites, librarians can add e-reserves to course websites, enrolled students can add content to the class blog, etc. There are literally hundreds of groups. A picture:
Image may be NSFW.
Clik here to view.
- read permissions on the materials specific to their role(s) -- examples: students can see the e-reserves for the courses they're enrolled in, faculty can review the faculty meeting minutes, etc.
- The ability to maintain their personal information – contact info, family history, professional history, personal interests, more (mostly for alums).
Additional features:
- e-commerce tools providing features like reunion registration for alums and gifts to the college
- a voting tool for trustee elections, faculty committee memberships, and more.
How we did it:
- Staff: We have two full time Drupal developers and myself (diplomat/project manager). One of our DBA's spent about half her time on this over the last two years. Our desktop support folks have spent a ton of time on training, representing about 1/2 of one person's time over the last 2 years. Our web designer spent at least half her time on this, and probably closer to 75%.
- Process: We opted for a phased rollout strategy, focusing our attention on one college role at a time before moving on to the next, and we've followed a “release quickly, adjust later according to user request” philosophy. Results of this approach have been mixed. We've managed to do a lot in ~2 years, but nothing is ever “complete” and we've often stumbled over unforeseen problems we would have caught had we pursued a more gradual, thoughtful approach. I'm not sure we would change though if given a do-over, because one of the goals was to quickly modernize the college's approach to the web, and a more deliberate approach conflicts with that goal.
-
Code: The main thing we needed that Drupal doesn't have out-of-the-box was sophisticated hierarchical content authoring with permissions control. To deliver this we built our own module, which we've dubbed “monster menus.” A brief overview:
-
Content is organized in one or more trees, with each level of the tree acting as a container for one or more Drupal nodes. Nodes can appear in more than one container at the same time, allowing content to be reused without the need to update it in more than one place. The user sees branches of a tree as a menu contained within a block. You can specify the depth of the branch to be displayed in a menu block, and menus can be themed as desired.
- Each level of the tree provides an element in the full URL of a given container.
- A granular permissions system:
- uses a Unix-like system of dependence, where a given user's ability to access one level of the tree depends on his ability at the parent levels; newly-added nodes inherit the permissions of their container, by default
- each container in the tree has separate settings for "who can edit its settings or delete it", "who can add sub-pages", "who can assign Drupal nodes to the container", and "who can read Drupal nodes in the container".
- includes three types of groups: pre-defined (where the member list is generated by a SQL query), ad-hoc (access to a single container), and manually edited (where one or more permitted people control the membership list). The ability to edit this last kind of group is, itself, controlled using the same groups-based permissions model. This allows maintenance of access control lists to be distributed to any number of trusted users.
- because this scheme does not use Drupal's built-in grants tables, it scales well to many thousands of users, groups, and nodes
- Menu settings, allowed themes, and allowed node types can be assigned per container, and cascade downward in the tree.
- Each user has his own "homepage" space where he can create new containers and content
- Based on user feedback, we found it best to change certain terminology, and remove a few node options, thus simplifying the interface a bit. This would be optional, were we to release the module to a wider audience.
I've recorded a ~10 minute screencast which runs through most of the features discussed above, which you can review here.
We've also done a lot of work on our own profile module (eduprofile), which draws on our backend (Datatel) to display users’ biographical, curricular, and personal information. It lets them edit various portions, depending on their role, and choose which other roles can see each portion of their data. An important distinction is that these are not Drupal roles, they're created dynamically from institutional data.
Image may be NSFW.
Clik here to view.
Areas we've struggled with:
- search. We've researched integrating with a Google Mini and, once time permits, will go that route. For now, we're not too happy with our search relevancy, and we're only searching across publicly available content.
- data integration. This has nothing to do with Drupal per se, but in terms of time spent, it's been one of the largest time sinks for us.
- We had to touch core. We have to do integration work when we adopt modules from contrib. We were able to back much of our code out of core when we ported to Drupal 5, and we're hopeful we can back all the way out when we port to Drupal 6 this summer.
What we're working on now:
- Moving the last of our old, static content into the system
- updating our codebase to Drupal 6
- calendaring for all users, built using a customized version of the events module
- quiz tool and gradebook to supplant most of the remaining Blackboard use on campus.
- migrating our library site
- enhancing our portal to incorporate more features (calendar display, profile management, etc.)
- integration with Views and CCK. When we started these tools didn't fit our needs. They do now.
At present both of our modules are tightly coupled to our Datatel implementation. At Drupalcon there was some interest in how our system worked. We also attended a session led by the Development Seed folks where they presented an alternative approach to some of the issues we worked to resolve, and were struck by one of the things they said at the end, which (paraphrasing) was, “So, we invented a solution off on our own, and now we want to know what the Drupal community thinks of it as an approach.”
We have the same question. We could work to decouple our code from Datatel and share it, but that represents a significant time investment for us, so we're curious to hear whether folks have more than an academic interest in what we've built.
Beyond this case study, after we've finished our migration to Drupal 6, we'll put up a test machine so folks can kick the virtual tires and get a sense of how this works. At best we'll get to that early this summer. In the meantime, I am happy to answer any questions folks have, and if needed I can screencap/screencast additional aspects of the system. We can also work to get a case study of monster menus with more detailed information on how it works up on drupal.org if folks would find that useful.