Since 1998 I have been maintaining an online history of Ingersoll Scout Reservation -- specifically, a history the staff who have worked there every summer since 1965. It's an impractical obsession -- both the maintenance of the history and the summers at camp.
Sometimes I wonder why I do it. At the outside, only a thousand or so people -- all of the staff since 1965 -- could possibly be interested. What use is my time investment there? What does it matter?
But what the hell? I learned most of what I know about leadership and communication and responsibility there. I tend to latch on to that experience as a fixed reference point from which I can measure my progress. Ultimately I don't justify my work on that website in terms of productivity or utility or page hits or any practical measure of success or failure. For good or for ill, that is my tribe, and my goal is to celebrate them and keep them in contact with each other.
In April I was going to write a story here about how I organized all of the staff rosters from 1965 to 2010. It was going to be an arcane story about the wizardry I performed with MediaWiki, how I linked each staff member to the years they worked at camp, and each year to the staff member who worked there, and each staff member to the various program areas where they worked. It was a maze of wiki templates and taxonomy. It was thorough to the point of being clinically obsessive. It was elegant and massive.
I did the bulk of it in one day. I woke up irritated one Saturday morning, 4am, then worked until 2am transcribing the old rosters to the wiki, then creating individual pages for each staff member.
It felt good to complete it. It felt good to sit down, decide that it was going to be Done, and then do it -- even if it was covered in the strange rime of total social inadequacy that is demonstrated by sitting immobile on a couch for nearly a full day.
The wiki was wonderful, but it was inflexible. To change the layout of the rosters or the individual pages would require changing every... single... page, all one thousand or so pages. What I wanted was all of that information to be stored in a database so that I could mix it whatever way I wanted.
I had no idea how to do this. I needed to break down the information into fields. My first thought was to make this all happen on a single page, that is, that each staff member page would have enough fields to store info about each of their years. The information that needed to be stored for each summer camp consists of a program area, a position, and the year itself. That's only three fields -- not so bad. But someone who worked at camp for 10 years would need thirty fields. Ranger Kevin would need over 60 fields. So this all needed to be decentralized somehow. How?
Then I had an ah-ha moment. Each year at camp was a separate event. One table in the database could be just these events. Each record would have the previous three fields (year, program area, position) plus the name of the staff member in another field. Then the database could be queried to show the records for a certain staff member or a certain year. Now I could deal with a maximum of four fields instead of 60 or more.
This is an intensely dull thing to get excited about. But I'll take it where I can get it.
I created a mockup. I tested it. It worked. And I jumped in for another round of Total Immersion to transfer information from one place to another. Thousands of nodes later I got the job done. I wrote more about that at isrstaff.org/node/2695.
Now I'm done with the structural elements of maintaining the staff history. There remains the task of finding missing rosters, collecting photos, and getting the old I mean former staff to share stories, but this is the fun part. It is a limited history -- limited time, limited place -- but the people and the experiences are rich when you get to know them.
What follows from here is how I set this up in Drupal. It is not interesting to read. I post it here in case someone out there finds it useful.
The history relies on three custom content types: names; staff records; and pictures. Each of these content types uses the Content Construction Kit (CCK) module to define extra fields.
First, names of all staff members must be added to the database. Names have two fields: first name; last name. Names come first because the the other two custom node types refer to names.
Staff records note the details of one person's experience at one year of summer camp. Staff records contain six fields: name; year; area; position; camp; and sort order.
Finally, there are pictures. Staff can upload photos from camp, which include the following fields:
After creating these three content types I copied and pasted the data from the wiki, creating nearly 1,000 names and nearly 1,500 staff records. This was as much fun as it sounds.
An uploaded photo could be large, over 2000 by 3000 pixels, which is too big to be useful in screen displays. I wanted a medium size image to display on screen, plus thumbnails to show on other pages. To accomplish this I installed the ImageCache module, which depends on ImageAPI. ImageCache requires installation of either GD or ImageMagick toolkits. I used ImageMagick because GD tended to choke on the full size picture uploads.
In the ImageCache settings, I created two new settings:
What this means is that anytime someone visits a staff biography (remember: a name content type) this panel will be shown. What I want to show on this panel is a staff member's years of experience, pictures, and a text biography.
The text biography is simple. This is the standard "body" of a node. I pull it into the panel via Add content > Node > Node body. I pull in the other two -- years, pictures -- with views.
I called the first view bio_years, which displays years and positions on staff.
To test this view I used 102 as the argument for Nid. What is displayed is the following, a list of each of the years and positions I worked at camp:
The second view, bio_pictures, is similar to the previous view except it will find the uploaded pictures related to a given staff member.
This will show, using Nid 102 again, uploaded pictures tagged with my name:
Now we can go back to the staff bio panel and add the views. In a single column format, I add the following content:
And that is how an individual's staff bio is created. Mine looks like this:
I wanted a page for every year of summer camp from 1965 to 2010, each with a list of the staff and their positions, each with a custom /history/YYYY URL. I did this by creating a custom panel page called staff_years that pulls in two views, staff_years and gallery.
Using 2005 as an input argument, this is what this view will produce:
The finished view, using 2005 again for the argument, looks like this:
To create a single panel that would serve for all years, I created a placeholder, %year, to be derived from the URL: http://isrstaff.org/history/%year. I assigned the context for the %year argument to be a string.
I added the staff_years and gallery views as content to the panel. In the configuration for both views, I set the context for Content: Year to "Raw string." This means that the year derived from the URL will be used as an argument for the two views.
First -- and I won't explain this because it was an easy view to set up -- there is a gallery that shows all uploaded pictures.
Second, I went back to the Panels page manager and created a variant of the node template for picture content type. In this panel, I added content for:
For an example, see this photo of Andy and I.