Skip to main content

Calendar Collaboration

Duke is working with other universities to build a better calendar

The team responsible for Events@Duke and the student calendar buzz is working with teams from similar projects at other major universities to improve the service on all campuses involved.

 

The focus of the collaboration is to provide students and others with additional features they've been requesting, ranging from better reporting of user statistics and more intuitive URLs for calendar entries to full listing of event co-sponsors, says Deb Johnson, assistant vice provost who oversees Duke's calendar project.

 

"We knew from the beginning that it would be critical to the success of the Events@Duke calendar for organizations to be able to co-sponsor events," she says. "Our schools and departments need to be able to pull their own events back out of the calendar for display on their own websites, and we saw co-sponsorship of events as the best way to accomplish that goal."

 

Jeremy Bandini, senior IT analyst in the Duke Office of Information Technology, wrote the code to make that possible.

 

Duke's requirement for co-sponsorship events and the school's approach to making that possible were of great interest to other universities using Bedework, the calendar application that underlies the two Duke calendars. Johnson and Bandini knew this because they had been involved since last March in regular conference calls with developers of Bedework applications at other schools.

 

"It was very reassuring to talk to Deb and Jeremy at Duke," says Cornelia Bailey at the University of Chicago. "We had a pretty good sense of how to implement the co-sponsorship of events, but it was important to confirm with others who had done it successfully that we were on the right track."

 

The collaboration goes beyond the software implementation, Bailey says.

 

"In a decentralized environment like the University of Chicago, we are increasingly aware that the success of a university-wide initiative like the calendar depends more and more on how it's marketed to the university community," she says. "We were very interested in Duke's commitment to the project, which includes a person who serves as the evangelist for the calendar, visiting with groups across campus and encouraging participation."

 

At Duke, that person is Meg McKee of the Office of News and Communications. She meets regularly with campus groups to promote Events@Duke and the student calendar buzz, which recently added features enabling users to import Duke events into their Google and Facebook applications.

 

Dirk Swart, project manager for the Cornell calendar, agrees that the sharing of ideas is at least as important as the sharing of code.

 

"Each of us is going to implement the functionality a bit differently," Swart says. "So the greatest value we get from the collaboration is in reducing risk. The point at which you're starting development of an application, the time during which you have to make the big decisions about your overall approach, is also the time you know the least. The collaboration allows us to get a jump start on that process. We can ask colleagues how they solved a problem, or what issues they see with an approach we're considering, and we get really important information that saves a lot of time and unnecessary effort."

 

In addition to Duke, the University of Chicago and Cornell, the Bedework collaboration includes the University of California-Berkeley, Brown University, the University of British Columbia, Yale University and Rensselaer Polytechnic Institute (RPI). The growing collaboration builds on previous work by RPI, which developed Bedework from a calendar originally produced by the University of Washington. From the outset, RPI envisioned Bedework as an open-source system for all of higher education.

 

"We wanted to encourage universities to contribute the best they had to offer to Bedework," says Gary Schwartz, director of communications & middleware technologies at RPI. "Faculty -- especially research faculty -- have been collaborating like this forever, but it happens far less frequently on the administrative side. We didn't want to be 'in charge.' We saw our role as encouraging a broad collaboration, so that further development could be inspired by and assisted by as many good people as possible, and that's been the case."

 

Diane Kubarek, director of Cornell University's office of web communications, says the user community is advising RPI about the future direction of their work on new functionality.

 

"In the last major release," she says, "RPI put a lot of effort into individual calendaring, but the user community has been advising them on other functions we'd be interested in seeing implemented." Johnson points to a matrix of Bedework functions -- both existing and envisioned -- that includes notations about whether each university views the function as "desired," "in progress" or "implemented." RPI is taking this feedback as an indication of where it should concentrate its work.

 

The user community can also suggest ways of improving the existing implementation. OIT's Bandini cites Bedework's tendency to respond slowly when Duke put "relatively high demand" on it.

 

"We developed a caching solution that resolves the issue, and eventually the caching will become part of the standard Bedework offering," he says.

 

In addition, Cornell has developed a tool for adding pictures or videos to calendar entries. The University of Chicago has one for importing calendar data from outside sources. Brown has done work on making the system more stable as it interacts with other campus calendars.

 

Schwartz of RPI says that by collaborating the group has achieved more than one team could have done going it alone.

 

"The best thing about the Bedework project is that it's given us the opportunity to meet so many creative people," he says, "and to work with all of them for the betterment of all our organizations."