For MM mailing list

Hey folks,

 Peter's asked me to share the major projects we worked on this summer in case there's anything of interest to you all. It's taken me a bit to get to it but here goes:

 1) We rebuilt how we handle course 'ereserves' using the Drupal Biblio module and a fair bit of custom code. Librarians, Faculty and academic staff can all add bibliographic records for items required in courses to a shared 'pool' of reserve items either by hand entering the bibliographic record or by importing them from tools like Zotero or Endnote. Items can easily be 'attached' to courses where only enrolled students can access them. Reserve items can be 'pushed' to student portals now that we have structured data about them, though we haven't done that yet. I've attached a few screenshots, and there's a screencast here:

https://www.amherst.edu/mm/120100

click to enlarge

That was for internal users and so not very polished, but it will give a sense of how it works if you're interested. This project was part of an effort which allowed us to retire printed 'course packs' in the library.

2) We created a Roster content type which uses Monster Menus groups to build a 'roster' of users for use in places like rosters of members in student organizations. Several presentation styles available, and various data elements about users can be included (things like email address, profile link, personal webspace link, etc). Obeys profile module permissions so you can have a roster with email addresses but if you're looking at it and are a role that I don't share my email address with, you'll see me in the roster but won't see my email address, whereas other roles can.

3) We built better email tools for our course website rosters. Faculty and academic staff can mass email all members of a course or a single section of a course, they can email students individually, and they can build persistent ad hoc mailing 'lists' to support things like labs and workgroups so they can then mail the labs/workgroups/whatever whenever they need.

4) We wrote a piece of middleware to sit between drupal and a google mini. This allows us to tailor search results to individuals' Monster Menus permissions. Basically the mini indexes all content on the server, public or private. Queries are passed to it and it passes its results to the middleware, which says 'ok out of this results set, what is this user actually allowed to see,' which is then passed to the user. In the past the mini was only indexing public content.

5) Course catalog data/curricular data maintenance and creation tool. We used the workflow module, CCK module, and Views module to build a tool the community uses to create and maintain curricular data. It replaced the paper driven process that was formerly used. Courses begin life as proposals at the dept level, get promoted to the Chair of the dept for review, then work their way through the committee process, get reviewed by the Registrar and a copy editor, and ultimately show up on our website and in the printed catalog via an xml dump of the data for print, and a somewhat manual import process by the registrar into our registration system. It also allows maintenance of the rest of the printed catalog data. I've attached a few screenshots to give a sense of how this works. It's a big, complex collection of code but it's been (mostly) a big hit and it's definitely saved the college time and money.

6) Course scheduler. We're moving to online registration. We rebuilt the tool the students use to build schedules for themselves that they then work on with their academic advisors. You can actually see this yourselves:

https://www.amherst.edu/course_scheduler/

If you're logged in the system allows you to save the schedules to a calendar and is date/time aware, will recognize conflicts, can find courses on the basis of available timeslots, etc.  It also uses Monster Menus permissions - saved schedules can be 'shared' with other users, ie academic advisors. Advisors use these schedules to grab the courseID's of the courses the students are going to enroll in and dump them into the registration system.

7) Lastly - it's not quite done but should be within a month - calendaring. Calendars are a content type which obey MM permissions. Calendar event objects and calendars are subscribable, so for example, I can have my own personal calendar on my portal and visit the athletics calendar and subscribe to the entire calendar which will then put every athletics event onto my calendar, or I can pick an individual event from some other calendar to add to my calendar. We'll also be able to push institutional data onto the portal calendars, so for example all student enrolled course times will show on student calendars.

We've got a few more things coming down the pike this fall (replace the existing tree browser users use to insert media into nodes, replace the college's existing web staff directory) along with the calendar stuff. If there are questions let me know. Hope things are going well for you all,