Creating, editing, and managing content for the new site

As Patrick works on building and testing the site, I’m thinking about what will go into it. A clean, usable architecture is great, but not if you fill it with clunky, cludgy words. Since these prototypes represent a relatively dramatic shift in how we present content, finding the words to fill our pages isn’t going to be a cut and paste kind of operation.

I had several things to consider:

  1. Who to involve.
  2. How to involve them.
  3. How to manage the data generated.
  4. How to share the information appropriately.
  5. How to do it all without making myself batty.

In the end, I decided on Basecamp as the tool that we’ll frame the whole project around. For a relatively low monthly fee, anyone can use Basecamp to manage an extensible number of proejcts for an unlimited number of users, and it has all the classic features of robust project management software: To Dos, a Calendar, a message system, file sharing, and most important for my purposes, collaborate WriteBoards.

To make this all happen, I’ve done the following:

  1. Set up a Basecamp project around the idea that each page of the website will be written by the person/team/department who oversees that work. This involved, essentially, creating the project, naming it, and inviting all stakeholders as participants.
  2. Created a To-Do item for each page (ie, “Write: Borrowing Policy”) and assigned it to the lead person for that area.
  3. Held a meeting to introduce the project to all stakeholders at once, and explain the goals and the tool.
  4. Asked each leader to create a WriteBoard for their individual tasks, using our existing documentation as a springboard, and then coordinating their teams to edit the text collaboratively. WriteBoards track versions, and authors, in a way that makes collaboration dead simple.
  5. Created a set of To-Do items for the editing phase — “Edit: Borrowing Policy” — and assigned them largely to myself as the editor of the project. (The exceptions are the pages I am writing; they will be edited by a librarian with a great eye for detail and tone.)
  6. Asked that each writer use the “email this person” feature in Basecamp to inform me when their writing tasks are complete, so I can begin editing, using the versioning in the WriteBoards to indicate which version is the final one.
  7. When I am done editing, I will use the same feature to notify Patrick that the content is ready to be inserted into the finished site.

That multi-phase approach has a few different reasons behind it. First, the single-editor approach ensures that the content will have a coherent tone and approach, will adhere to whatever stylesheet we agree upon, and will make it less likely we make dumb grammatical errors. Second, the multi-author approach ensures that all the facts are true — no one knows our circ policy like the circ staff, so having me write that section is foolish. And, third, using BaseCamp to do the entire project streamlines the information flow for me as the editor, and Patrick as the one who has to process all we create. This way, we each only have one place to consult for content, rather than a slew of emails, shared files, Google docs, and scribbled-upon sheets of paper.

I have high hopes that this will go smoothly, or at least that the speed bumps will be interesting ones. Here’s to rewrites!

Soliciting volunteers

Patrick is ready to run card sorts with our community to begin our information architecture work, and the first question in any volunteer enterprise is “how do we get people to participate?”

Well, by asking.

Then by begging.

Then by arm-twisting.

Also, try offering incentives. Like coffee or pizza.

(I haven’t been forced to the Pizza Extreme. Yet.)

As the Voice Of The Library, I took two initial approaches to finding volunteers for the card sort. First, I sent an email to Dr. Tom Baker, the head of our Honors Program, and asked if he would solicit student volunteers for us. We, as The Libraries and as members of the campus community, have a strong existing relationship with Dr. Baker and with the Honors Program, so this was an easy way to reach out to several hundred students to ask for help. I offered a gift certificate for free coffee at the cafe to any student who volunteered, and before the day was over I had 3 volunteers.

Then I sent out an email to our faculty liaisons to the library. This group consists of one faculty member from each of our academic departments, with whom we work on Collection Development and libraries’ communication issues. And, when needed, I use them as a sounding board, informal advisory group… and pool of potential volunteers. (I also offered them coffee.)

If these two solicitations fail to get us enough volunteers to fill the three card sort sessions, we will move on to the next step: Begging. This means asking for volunteers personally, from amongst our friends, colleagues, coworkers, student workers, students in classes, library regulars… and offering coffee.

If that fails, arm-twisting is next. That means I, as Director of Libraries, start calling in favors. I try to save these for stuff that matters, but this project counts in that category.

(Or I offer to buy pizza. We’ll see.)


One of the first decisions that the project team — Dan Newton, Patrick Patterson, and me — had to make was about infrastructure. The College CMS is one of our options, as are a standalone CMS or a template-driven standalone site.

After a brainstorming session with the library staff, and then with Patrick and Dan, about our functional requirements for the website, and there were two things that came out as key necessities for our website infrastructure: The availability of a sandbox server so that we can experiment with new approaches and do usability testing, and the ability to make immediate changes for instruction and service purposes.

Neither of these are possible with our current campus CMS setup of a staging server that is pushed live twice per day. Given that, we are planning to move forward with creating a site outside the campus CMS. Given our expectations about the complexity of the site, and the variables still in play regarding the setup of the campus CMS, we also decided not to immediately implement a standalone CMS. It seems like more than we need right now.

However, I want to work as closely as possible with the campus Public Affairs web team to make sure that we’re following the visual style of the college site, so that we don’t stand out like a sore thumb in terms of identity and brand, and to take advantage as much as possible of the work our very creative PA team has done in creating a beautiful design. We have also agreed to build a site that is migration-ready — we’re already intending to streamline a great deal, but we want to build the site in a way that will allow us to transition it, in a few years or when necessary, to a new campus CMS or an internal CMS or whatever it is that our next step needs to be. Whatever the case, we want it to be flexible and ready to transition from day 1.