Tag Archives: Ingersoll Scout Reservation

Organizing the history of Ingersoll Scout Reservation (in Drupal)

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.


Custom content types

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.

  • Name. This is a Nodereference field that refers to the Names content type. This associates the staff record with a particular person.
  • Year. The year will do two things: (1) this record will be shown on the corresponding year's roster; (2) this record will be shown in the list of years on a staff member's bio. For example, the staff record of me in Scoutcraft in 1998 will be shown (1) on the 1998 staff roster and (2) on my staff bio.
  • Area. There are different program areas at camp, e.g., aquatics (the pool and lakefront), handicraft (woodcarving, etc.), Scoutcraft (camping, pioneering, orienteering, etc.). Each roster is organized by program area: first the camp administration, then the aquatics staff, and so on.
  • Position. This is the staff member's job for the summer, from counselors in training to assistants to camp director.
  • Camp. This is for future improvements, namely capturing the histories from former Boy Scout camps like Camp Wokanda.
  • Sort. This is an integer that sorts the records on the roster page. The rosters are organized by program areas, each of which has its own hierarchy with directors at the top and assistants at the bottom. Smaller sort numbers rise, larger numbers sink. So, a program area director will be given a low sort number and a program assistant will be given a high sort number.

Finally, there are pictures. Staff can upload photos from camp, which include the following fields:

  • Picture. This is the picture to upload. It relies on the ImageField (and, subsequently, FileField) module.
  • Year. Including the year allows the picture to be shown on the corresponding roster page for that year.
  • Staff. Same as the staff record, this is a Nodereference field that refers to the Names content type. Choosing a staff member here will show the picture on his or her bio.

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.

Image setup

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:

  • Medium. Action: Scale. Settings: 500x500. The original file would be scaled to fit in a 500 pixel by 500 pixel box; the longer edge of the photo would be scaled down to 500 pixels and the shorter edge would be scaled down to match the original aspect ratio of the image.
  • Thumbnail. Action: Scale. Settings: 100x100.

Staff biographies

Staff biography panel, take 1

To display a staff biography, I used Views and Panels. First, from the Panels page manager, I enabled the "node template" page then added a new variant.

  • Title: Staff biography
  • Variant type: Panel
  • Optional features: Selection rules
  • Selection rule: Node: type
    • Node: Node being viewed
    • Node type: Name

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.

View 1: bio_years

I called the first view bio_years, which displays years and positions on staff.


  • Node: Published > Published: Yes. A standard thing -- I only want published nodes shown, not drafts.
  • Node: Type > Operator: is one of > Node type: Staff record. I want this view to only show staff records.


  • Content: Name. This is the nodereference field from staff records.


  • Node: Nid
    • Relationship: Name. This is the key setting. When someone visits a staff bio, I want only the records related to that particular bio to be displayed. The Nid (node ID) is a unique number for a node. When a staff record is created, the nodereference field refers to a specific Nid. "Relationship: Name" allows only nodes where the Content:Name nodereference field refers to the node being visited.
      For example, my staff bio is located at isrstaff.org/node/102 -- the Nid is 102. On all staff records related to me, the Content:Name refers to Nid:102; so when you visit my staff bio only the staff records referring to node 102 are shown.
      (Maybe it's a bit overwrought to describe this, but it took me a long time to wrap my head around how relationships worked in Views. Once I figured it out, it opened up a world of possibilities. Clearly I am no genius.)
    • Action to take if argument is not present: Display empty text.


  •  Content: Year.
  • Content: Name.
  • Node: Edit link. If you were a logged in member, you would see beside each record a link to edit that record.
  • Global: Custom text. This field combines the year, name, and edit link into a single line.

Sort criteria

  • Content: Year > Sort order: Ascending. Orders the staff records by earliest year first.

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:

View 2: bio_pictures

The second view, bio_pictures, is similar to the previous view except it will find the uploaded pictures related to a given staff member.

Basic settings

  • Style: Grid
  • Row style: Fields


  • Node: Published > Published: Yes.
  • Node: Type > Operator: is one of > Node type: Picture.


  • Content: Staff. This is the nodereference field that notes the staff members in the picture.


  • Node: Nid
    • Relationship: Staff. This shows only pictures related to the bio being displayed.
    • Action to take if argument is not present: Display empty text.


  • Content: Picture.
    • Format: Thumbail image linked to node. This is the thumbnail created earlier with ImageCache.

This will show, using Nid 102 again, uploaded pictures tagged with my name:

Staff biography panel, take 2

Now we can go back to the staff bio panel and add the views. In a single column format, I add the following content:

  • Views > bio_years
    • Node: NID: Node ID. This is the context selected for the view. This is what sends the Node ID of the node being viewed to the views so that only the relevant person's records are shown.
  • Views > bio_pictures
    • Node: NID: Node ID.
  • Node > Node body. The names also have a text area for further description of the staff member.

And that is how an individual's staff bio is created. Mine looks like this:

Staff rosters

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.

View 1: staff_years


  • Node: Published > Published: Yes.
  • Node: Type > Operator: is one of > Node type: Staff record.


  • Content: Name. This is the nodereference field that connects the staff record to a particular name.


  • Content: Year
    • Title: %1 Staff. The title of the page will be set to whichever year is being called, e.g., 1972 Staff.
    • Action to take if argument is not present: Display empty text.


  • Content: Area.
  • Content: Position.
  • Content: First name.
    • Relationship: Name. Each staff record node has a Content:Name nodereference field that selects from the list of names. Each name node has a field for Content:First name. This field looks for the name that the staff record is related to (i.e., that the nodereference refers to) and then finds the first name entered in that node.
  • Content: Last name.
    • Relationship: Name.
  • Node: Edit link. Users with edit permissions will see a link to edit each record.
  • Global: Custom text. This field combines all of the previous fields on a single line.

Sort criteria

  • Content: Area > Ascending.
  • Content: Sort > Ascending. Sort by hierarchy within the area.

Basic settings

  • Style: HTML list
    • Grouping field: Content: Area. The program areas are a major division in the camp hierarchy. Instead of showing the program area on each line, putting it as a grouping field will use the program area as a sort of header between lists, as shown below.

Using 2005 as an input argument, this is what this view will produce:

View 2: gallery

Basic settings

  • Style: Grid


  • Node: Published > Published: Yes.
  • Node: Type > Operator: is one of > Node type: Picture.


  • Node: Content profile. The website uses the Content profile module for collecting profile information from users. This relationship will find the profile information of the person who created the picture.


  • Content: Year
    • Action to take if argument is not present: Display empty text.


  • Content: Picture.
    • Format: Thumbnail image linked to node. This is the 100 pixel thumbnail defined earlier in the ImageCache settings.
  • Node: Title.
  • Content: First name.
    • Relationship: Content profile. This field looks for the Content profile of the user that uploaded the file, then finds the first name of that profile.
  • Content: Last name.
    • Relationship: Content profile.
  • Global: Custom text. This field combines all of the previous fields.

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.

The end result for the year 2005 can be viewed here: isrstaff.org/history/2005. Or you can view any of the other years at isrstaff.org/history.


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:

  • Node > Field: Picture (field_picture) - File. This is the picture itself. The default for the picture content type, before creating the panel, was to display the uploaded picture -- which could be a 3000 pixel wide monster that stretched far off the page. However, when adding this field to the panel, there is an option in the configuration settings called "Field formatter." The default is "Generic files." Switch that to "medium image linked to image" and it will display a nice, neat medium-sized image that will fit in a 500 pixel box as defined earlier in the ImageCache settings.
  • Node > Field group: Picture information in Picture. This containts the fields for the year and tagged staff in the picture.
  • Node > Node body. Description of the picture.

For an example, see this photo of Andy and I.

The Banana Song

A few weeks ago I gave my introductory Toastmasters speech. I wanted to capture that speech and write it for you. I nailed the presentation because that's what I do. Instead of the whole five-minute speech, here are my notes on back of a business card1.

Allow me to step out of character (because I don't like to brag and I don't like people that brag): that business card is the only set of notes I need. I practice by using the outline, but I leave the rest open for creation on the fly. That card represents about seven or eight minutes of speaking, which I pared down to five during the speech as I figured out what the audience wanted to hear. I gave up on trying to write the speech in full here. What I said in person was a one time only event. I don't even remember most of it.

Let me tell you what it's like, even if I can't tell you what it was. On stage I am a different person. You wouldn't recognize me if you knew me elsewhere. It's almost schizophrenic. My everyday persona is awkward, ungainly, uninteresting. My onstage persona is garrulous, friendly, confident. I like him better. He's more interesting. I should hire him to be me full time.

Time slows down when I'm on stage. I wonder if that is what it feels like to be a talented musician or athlete. I wonder if Deron Williams feels the game in slow motion, giving him an advantage over lesser basketball players who feel the game at real speed. I can only wonder. In my simulated slow motion I become aware of cues from the audience and I feel like I have extra time to react. I can casually sort through different words and phrases -- like thumbing through a rack of albums at a used record store -- and come back with the one I want without losing any time. It feels amazing. All I need is a few prompts and I can construct the rest of the speech from the laughs, grimaces, surprised gapes, and hanging silences of the audience.

My speech was a meta-speech. It was a presentation about how I do presentations. The idea developed in December when I was planning to meet a few old friends from Ingersoll Scout Reservation. Offhandedly I mentioned to Joe that I talk about "The Banana Song" in job interviews. He asked how I could do that in a professional setting. As you might guess from the title, "The Banana Song" is a silly song. It doesn't conjure an image of selling yourself as a reliable engineer, does it? It is one of the many ridiculous ways we kept Scouts entertained at camp. It involves loud, stupid singing -- yelling, really -- on a stage in front of crowd of people you don't know. It involves dancing -- jumping around, at least -- and doing it with such enthusiasm that you can get a hot, humid, mosquito-filled amphitheater full of restless Scouts and stodgy Scoutmasters to dance and jump and yell and sing with you. It is a strange thing of beauty.

So, how does "The Banana Song" fit into an engineering job interview?

In a job interview for a technical position, it is customary for the interviewer to ask: Are you comfortable making presentations to other people? (It's an important question. Engineers are not noted for their ability to communicate with other humans.)

Easy. I tell them that once you've sung "The Banana Song" in front of 250 strangers, every other presentation is simple. Now you know.

1 The red "KV" stands for the invocation I like to give to start off a speech. I stole it from the opening of the Book of Bokonon in Cat's Cradle by Kurt Vonnegut: "All of the true things that I am about to tell you are shameless lies."

First Redlines for Above Cedar Creek

Finally, after a trip to Calgary and a hurricane, I finished editing the first three protochapters of a book I'm writing about my experiences at Ingersoll Scout Reservation called Above Cedar Creek.

I like editing better than writing. It feels more natural to move the pieces of this great puzzle around than to design the pieces. But editing is strenuous. It requires that you carve your creation into sometimes unrecognizeable pieces which, in this case, is entirely necessary because the original is junk. It was a first try sprint that needed to be tamed, beaten, managed, expanded, etc.

For posterity -- or an obsession with noting every mundane detail -- I scanned the copies of my first redlines:

Tomorrow I have a long train ride from Longview, Texas to Springfield, IL for Dayvo's party (posted on Dopplr). I like trains -- they're like offices on wheels. It means that I'll be more or less confined to my seat. If planned well, this translates into several productive hours to transform the red ink into electronic text.