APS12: One Calendar to Rule Them All

Tina Coleman 
Associate Director, Creative Services, College of William & Mary

Andrew Bauserman 
Senior Web Architect, Creative Services, College of William & Mary

The audio for this podcast can be downloaded at http://2011.highedweb.org/presentations/APS12.mp3

Announcer: This is one in a series of podcasts from the HighEdWeb Conference in Austin 2011.

Tina Coleman: Hello, everybody. Thanks for coming to the last official presentation slot. It's nice to see so many people this afternoon. As you've probably read in Description, as you can see from the slide, we had a goal to have one unified calendar on our campus, the public events calendar, for all of our faculty, staff, students and then external audiences as well, alumni, friends, neighbors, parents, prospective students and their parents.

So I'm going to go right into this, to tell you what our goals were. First of all, unified,we already know that. You can see we wanted it to be easy. That's both for the visitors coming to the events calendar and also for the people who were going to submit events and manage their own calendars. We want them to be able to share events with each other. I'll explain that a little bit more. And we also wanted a simple integration other systems.

So this is what we had, and this is just a brief list of what we had. And you're going to see that it's a mixture of both good and bad. We had many sites that featured events. That's good and bad. The bad part is that there were a 125 separate calendars.

The majority of them were in our CMS, which I know somebody's going to ask, it's Cascade. But we sort of jimmied Cascade to work for events. It's not inherently meant to manage events.

So it was great because each department could feature their events but they were separate. You didn't have a way to share an events with another department if you were co-sponsoring it. You did have the ability to borrow an event but you had to know that another department was having that event. So you literally had to visit a 125 calendars to know that there is an event going on that you might want to borrow within the CMS.

We did, this is a plus, have a Listbox feature. So each department could place anywhere on one of its webpages on the right column on the Listbox that featured their upcoming event.

The last bullet here, which is a good thing, is that we got a directive from the President and the administration to create an unified calendar. We didn't have to go to the top and say we really need this. They knew. They understood the problem. Everyone recognize that this was a problem, that we didn't have a one place to find out what was going on at the campus. .


And part of the reason that was really important for the administration is there's been a real effort to collaborate with the local community to improve visitors' experience to our area. So if you are not familiar with where William and Mary is, we are at Williamsburg, Virginia, in southeast Virginia. We literally sit next door to a living historic museum which is called Colonial Williamsburg. And you can walk from one to the other and not necessarily know you've left the other. It's all about red brick there. So brick buildings, brick walkways.

So we're very integrated in that way, geographically. So if somebody's coming to visit the campus, whether they're here to see CW or they're to visit the campus on a tour, or they're alumni coming back for homecoming, usually people stay there probably at least overnight and may want to experience other things in the area. So we're trying to improve the visitors' experience to the general area.

So it was really nice for us because we had buy-in from the top.

I'm going to turn you over to Andrew to start talking about ways we did that and what we ended up with.

Andrew Bauserman: All right. So the first thing I want to look at is kind of what we had and goals that we were trying to achieve. And Tina listed the goals just a minute ago which basically boil down to one unified calendar and we want it to be simple.

And those are great goals but they're not necessarily measurable or tangible. So what we wanted to do is figure out how are we going to measure success at the end of the project. And I think that's important to do before you get to implementation or you've been choosing product to figure out how do you know you're successful when you get there. And that will help you kind of guide the other decisions.

So what we had was a 125 calendars that are simplified here. And there was the capability that Tina allude to that we could borrow an event if we happen to know that there was one and we went and tried to find it. It's a very manual process which we admit, it didn't happen very often.


So we wanted to be able to define success and here's the criteria that we came up with. Now the important thing here is not necessarily to lose the criteria that we came up with because that maybe different for the institution. I went to a presentation yesterday where a criteria was fully bilingual front end and back end. Well, that was not one of our criteria, but it may be for you.

So it's not important necessarily which criteria we chose but the process we went through to figure out what was the correct criteria for our institution.

So the first thing we desired was to make a integrated, unified calendar. So my theme here is going to be what does it mean to be unified. The goal is to have a unified calendar.

The first thing is that we are all in the same playground. We already sort of had that with the 125 of our calendars within Cascade. We worked for three and a half years to bring together the College of William and Mary, Arts and Sciences, Administration, Virginia Institute of Marine Science, Law School, Business School, and School of Education all into Cascade Server. All into a single CMS.

That was an achievement. We worked really hard for that. We're proud of that. We're not going to have false modesty because that was a lot of work. We're not going to go backwards, right? We want to have all of those that we got into Cascade into a single event system, whatever it's going to be.

So we need it all to be in the same playground. But we also want better interconnections which mean being able to get those events and display them where they make sense. Not every event, of course, makes sense with all the calendars. We wanted something to make the process possible.

The first criteria we had was to have a single playground where everything's going to be. The second criteria was to have, still have distinct calendars just because of the nature of our situation. So we needed a separate calendar for Physics, for Math, for Dance and for the Registrar.


One of the things you see, I think in websites, we kind of struggle with this as well is how much does your Web structure mimic your org chart? You don't want it too from the end user's point of view but from the point of view of the person in the Registrar's Office who has content to edit, that's exactly how that person looks at it. "This is my content. I need to edit this".

The trick is to have the capability to say the career center has their events here. And they want to see them together, and at the same time be able to do things with it because it's all in the same system.

We wanted to go beyond that though. So we decided a little bit bigger. What we represent here is we wanted to take this beyond just a single playground and separate calendars. And we know how to measure success with that because it's all in the same system. We have at least 125 that we started with and in the new system, maybe more. That's going to be great. But we wanted to be able to go beyond that and have some interconnections.

And I'm going to refer to this as kind of a loosely coupled joining of calendars. And there are three ways that I kind of look at this, as loosely coupled.

One is, that we have some events that, I say, don't belong to any entity. They're not in an office or department. For instance, there's no Department of Homecoming. There is no Office of Commencement. But these are real events, they happen. So we need some way to loosely couple these events around the reality of our campus.

That's one type of loosely coupled. The second is hierarchy. We need to lose hierarchy. Because it's pretty simple to say, "Oh,Math" and "English". These are all parts of Arts and Sciences or these are offices or these are part of the School of Business or School of Education. But what happens if you have for instance, Biology Program in the Undergraduate Arts and Sciences School that is co-sponsored by your Graduate School of Marine Science?


You can't have a strict hierarchy. Our reality is strict hierarchy didn't work. It may work in another institution. So again, to be able to look at your own reality and figure out success at the end means we can deal with the reality that we have.

So loosely coupled with these events that aren't sponsored by specific entity, loosely coupled between the hierarchy, and then loosely coupled in a third way that was a little bit hard to get our head around, quite honestly. We knew there was something else we needed to specify to say we'll be successful if we can do this. We couldn't quite figure out a term for it.

So being Creative Services we used that creativity and called them 'buckets'. And we said what if we have a bucket that we can put events in that kind of make sense together. And we started kind of brainstorming what it meant with what we're talking about. Because we all kind of knew what was missing but we had to come to terms with what was the goal in order to be able to measure it at the end. And in fact, even to be able to say that the product is going to be able to do it, but what is It?

So here's an example. Let's say, hypothetically... This isn't a real example but it's certainly possible on our campus. Let's say a sorority has philanthropy as one of its goals, had sponsored a 5K run for bone marrow or breast cancer or whatever. OK? How am I going to see that? If it's a busy time of the year, the chance of it showing up prominently on the list of all events, much less making it to the very smallest on our homepage, is pretty remote. .

If I'm not a member, and certainly you can tell by looking at me. I'm not a member of the sorority, how am I going to see that this is happening if I'm interested in supporting that cause or doing a 5K run? Let's say we had the opportunity to group the events by the type of things which is called a bucket.


But what would these buckets be and how could we organize this? We didn't want to go as far as every single tag. This is something bigger than just a tag. Tags are like your hashtags in your Twitter. It can just be pretty much anything arbitrary. We wanted something a little bit more universal that would fit our campus.

So we came up with some buckets. We don't advertise them as that. But internally, while we were at this process, we're trying to figure what to call them. We came up with one called 'Service'. Service is big on our campus. A lot of groups have service organizations as part of their sorority, fraternities, whatever.

Cultural Arts is big on our campus.

Sports and Leisure, not just tribe athletics which is our varsity sports - intramural sports, other things that would have to do with being outdoors during activities.

And then we have...

Tina Coleman: Academics and Research.

Andrew Bauserman: Academics and Research. And I can't remember which one I've made.

Tina Coleman: University Life.

Andrew Bauserman: University Life. So those are kind of buckets we came up with. You can go to our site and see where they are. But it's not necessarily important which buckets we came up with. We look at the reality of what we have, how would organize this so that somebody would find this information if they found those types of events important to them.

So over here you can see I kind of... These are organized more like the org chart. So these are Art and Sciences, Offices, Business, Education. This is Service and Culture. They're just in separate independent little buckets but they're useful to us.

So the process we went through to figure out if we would be successful with the first goal which is a unified calendar, we really looked at kind of capabilities we needed not in terms of technology, not in terms of product, but in terms of how would we know when you get there, will you be able to make use of these types of things.


OK. The last two, points that I have here about the success. How do we know, can measure, that we got to the end and were successful in having a unified calendar?

One of the things that I've mentioned all along is that we have our Graduate Professional Schools. Our graduate and professional schools have unique identity and yet they're part of the College of William and Mary. And one of the things that's important to them is to be able to have their brand and their identity. One of the things that's important to us is to for them to look like the College of William and Mary.

And so when we implemented the websites and got them all together in the content management system, we came up with an idea along with mStoner who is doing some of the design for us at that time of sibling look, a family resemblance. So that when you go between our Law School and our Business School and our main campus, you can still navigate. There are similarities. You can still find things between them and yet they have their own independent look.

Likewise with the calendars, is we need to take that sibling relationship in two directions. And so we want to be able both to have the events for the main campus and the events for the Law School to look similar so that you can tell you're within our event system. We also need the School of Business events to become to be complementary to the School of Business' website. So we're trying to take that family relationship in two directions.

Just for mock-up, actually this is a screenshot because we're done now, but at that time we're doing concepts of what would it look like to have a sibling look. So this is for instance the Events page at the College of William and Mary where you can just see everything that's coming up this particular screenshot. And you can see kind of the color scheme that's here.


When you switch over to the Mason School of Business, the colors, it looks more different on screen. It's more of a gold than yellow, but it matches more the look of their website in terms of the photography and the colors. And yet, navigationally, it's very similar. And so we were able to have the same capabilities, the same system and yet some identity within us.

So those were criteria for measuring success in terms of having a unified calendar of events. We got to the end.

All right, so we turn you back over to Tina to talk about all the other goals.

Tina Coleman: OK, I'm going to move in showing you a little bit more about the public side of our events and dig down a little bit more into an individual department, for example, and show you a calendar. What that would look like and an individual event and some of features that we have on there that we didn't have before that sort of contribute to what our goals were and all.

So we took the History Department. And this is an example of what it would look like if I had drilled down to the History Department. They had, at the time I took the screenshot, two upcoming events. The things to point out here, similar to what Andrew is talking about, is that it's similar navigation. Regardless of which calendar I'm on. I always have my little calendar widget over at the top. Navigation is very similar.

Some things that we added,because we took them outside of the content management system and now put them in a separate system. We wanted them to be able to get back to the History Department so really it's small down here, I don't know if you can see it. It says "This calendar presented by History."

And so, the calendar administrator have the capability to put in a home link which can take you to the History homepage. The History events is actually now clickable to come back to Events if you start digging out, back to this calendar if you start digging down into their individual events.

The top right, if you can look to the left of the sign in links. It says Arts and Sciences Events. We also thought it was important to have a way to get to what we considered an umbrella above each of these calendars. So History does fall under Arts and Sciences. And it wasn't meant really to show our org chart so much as you might be interested in all Arts and Sciences events and it was an easy way for you to get there.


So I'm going to go... One more thing we'll show you, sorry. So what we did not have in Cascade, right next to the Upcoming Events title, there says an iCal link. We did not have a way for you to push out your Event information from Cascade. So we thought wit was important to keep up the Joneses and have things that you see everyday available with Events as far as publishing the event information.

So if I click through one of those individual events, I'm now on an Event page. Again, my navigation has pretty much remain the same. I know this is small and you probably can't see this very well. But it's basic event information - date, location, summary, event type and so forth.

Couple of things I want to mention at the bottom that we've done again. This is all part of being integrated and just making this more dynamic. This event also appears on and it says Academics and Research, Arts and Sciences, William and Mary Events. So it shows you where this event also, what other calendars this events also appears on. We're going to talk a little bit more about how they get those there using recommendations. But it's quick links to get over those calendars if you're interested.

We provide the Share bar so you can email these events, put it on Facebook, Twitter, etcetera. And then we provide the iCal and Google links at the bottoms if you want to adjust that one individual event to your calendar.

This is a History homepage within the CMS. And the events list box I mentioned earlier is this little widget on the right side here. This is what they have before we launch this event system. We did not want to take any functionality away. So we managed using RSS which is pretty standard these days to pull our events in from the new system here. And for the user and for the administrators of the calendar, nothing changed.

It all looks almost identical to what we did before. But we're obviously using what we had available to us by being able to us by being able to pull out the Events information from our new system.


Another place that we were interested in integrating was our mobile site. So on the left is just a screenshot of our homepage of our mobile site.

Third row down, first button is the Events button. When we did our inventory of what we wanted to include in our mobile site, what was going to be important for people walking around on campus if they were on their mobile phone. Events was huge and we didn't have that till we launched the system. So we were really excited that we could add that there.

The right side just shows you a screenshot at the time that I took that of the upcoming events should you select the Events. Now this does show you all of the upcoming William and Mary events. So everything that filters up to that top calendar. So at any given day this could be, I think the first screenshot I did for this was all athletic events just because there were lectures going on that day. So I managed to get another one. It was a little bit more of a variety right before the conference.

And the last place that we are very interested in pulling in using RSS was our homepage. We feature three events here in the bottom-left corner. This was a very manual process before we launched this. If you wanted something on the home page, you had to fill out a web form. It got emailed to someone on our team, who'll then copied and pasted the event information if we deemed it worthy of the William and Mary homepage. Pasted that into fields in the CMS so that it would show up on our homepage.

So it's still somewhat manual process in that we still filter and decide strategically what to place on our homepage. Because you saw what our screenshot was from the mobile site, we don't want two tennis events showing up, you know, the next two events on our homepage.

Knowing that this is a marketing tool for us, we wanted to be sure we include a variety of things here, both a lot from our buckets. Let me say, we want to show that we do service, we have athletic events. We have academic events. So we strategically place the things that show up on those top three. It allows us the ability to feature things especially when we have like homecoming or different things we can push things up to top, take things down.


So there is someone monitoring that but at least it's all in one system and we can grab and pull those events from that one system. We don't have people manually doing double work. So the people who are filling out the form to get something on the homepage had already filled out an Events page in Cascade to have that event on their own department page. So they were doing double duty.

Therefore, most people weren't even doing it. So we had bare bones on our homepage of interesting events unless we will not look for them and put them there ourselves. So this was a huge improvement for us, for the events that we could feature here.

OK. So I wanted to get into the back end of it a little bit to show you one of our goals was to make this easy to use from the back end.

One thing that changed with this is that our user base for the event system grew by thousands. Because prior to this, the only people that were really creating events were people who had department websites and had access to the Cascade CMS. So by launching this, we opened it up to anybody with a William and Mary user ID and password. So students, obviously, they became a huge audience for us.

This screenshot shows you what it looks like if you manage calendars. So a department, Web administrator would see this kind of page if they manage more than one event calendar. Students, let's say if they log in to this would never even see a 'My Calendars' button. They would see any events that they have created. Because anyone can create an event.

But I wanted to show you how easy we've made it on the back end. for the people who administer calendars. So like I said, most people would only have one here but I wanted to just show you, you obviously can be an administrator for as many calendars as you need to be.

So if I already click through the run of my calendars that I manage, again, the whole idea is to make this easy. We made it very visual and big buttons. The right side features easy to navigate calendar options. The middle shows you the events that are on this calendars. I picked Parents and Families as a calendar example.


You see three buckets : Pending, Approved and Ignored. Anything I create if I'm an admin goes into the Approved automatically. But I have the ability to control what shows up if people recommended events to me. And every calendar can be open to recommendations or close to recommendations. But it lets me manage the ones that are there.

As an administrator, I also have the option to get an email every time somebody submit something. So that's a nice a feature for them that now we are allowing sharing. We did not want to push it to them, force them to get email but they have that option to turn that on if they want.

So our goal is easy to navigate, easy to use. And we think we've met that with that.

And that's Andrew's scheme, to talk a little bit more about the back end.

Andrew Bauserman: All right. Thanks, Tina.

Tina Coleman: Yup.

Andrew Bauserman: OK. So when we're talking about the goals, and Tina's kind of showing some of the simplicity aspects of both the front end and back end., also is simplicity of moving content around whether it's by RSS or iCal or to external systems. Another thing that we wanted to be able to do was those interconnections aligns between the calendars, the moving of content around. And so, I'm going to show three ways that we've done that because our goal was to be able to deal with these loose couple of links.

So first of all, when you create an event, as soon as you hit the Submit on the event itself, if your calendar administrator, it puts it in your calendar. If you're a student, it just creates it as an event that's nowhere. The very next screen you see is a recommendation screen. So this is to really encourage the re-use of content. So if you think this content that you've created belong somewhere else, this is your opportunity to tell us.

There are basically two different places that you can push content to. And this is something a student could do as well as a department that thinks another department would be interested.


If we have calendars we manage they would be up here. These are the buckets that I was talking about. And so were calling them Top Calendars. This particular event that I'm recommending has been posted on to the Academics and Research events. If you can't see this, it's basically the Cultural Arts, Service, Sports and Leisure and University Life that we're talking about before.

In fact, we often, if it were not posted to any of these, there's actually another option that says that you don't want to share it with another calendar. It's something that's internal to your club or organization or department. You don't think it really belong anywhere else.

So that's a possibility but we don't really encourage that. And in fact, once you recommended it somewhere else, that choice doesn't make sense just to have that as an extra option. So we toyed with requiring this. And then we said, "Well, there's going to be some things that don't fit in one of these." But we tried to push it as hard as we could that your content should be shared.

The second thing we did was we have all of what Tina called the umbrellas: Arts and Sciences, Law, William and Mary departments, offices, programs. You can see the different opportunities that you have to share here. And actually, when you click Arts and Sciences, it expands. It won't fit on the screen. There are 40-some programs within Arts and Sciences, whether they're majors and minors or whatever.

And so, if you have something that you want to share across departments -- an example would be, for instance, in Mathematics colloquium that the Neuroscience folks might be interested because that's heavy math these days -- so you could suggest it to them. It does not put it on their calendar but it will show up on that screen. Thinking about the screen that Tina showed here with the Pending. It would become Pending for that organization.


So again, we wanted to really have... One of our measures of success is that there more lines connecting after we're done. We have just as many separate entities but more connections between them when we're done.

OK. That was one way we can move content is, as I create it, I can recommend it.

We also chose... Before I get this slide, let me go back to the stuff here.

We chose a permissions model that is not really tight in terms of forcing people into boxes. Any student can recommend. Now, they can't make it show up but they can recommend to any department that accepts recommendations. There's a few who don't want to accept them so we gave them that option but most are open and you can recommend things to those departments or organizations.

I lost my train of thought, I'm sorry.

So right, you can recommend the event. And oh, the permissions between the departments. If you recommend an event to another department and they put it on their screen, you actually shared ownership now. There is a trade-off between complexity and simplicity. That's very real. And in terms of security, that really gets to the complexity side.

We're going with the assumption that most of the people we deal with are adults and they can play nicely together. And wer're trying to raise the bar and most people actually will step up to that level. So you always have somebody who will play devil's advocate and says, "But what if I put this in here and then share with that department and they go in and change it?" OK. You change it back and you tell them please don't do that.


You can believe a system that is so structured with workflow and if you need that, then that's the choice that you need to make. And we've chosen to kind of go with a looser structure. It still has security. Students can't post something to the history calendar. But if something is cross-listed between Neuroscience and Math and the date changes, one of them and the other can change it. They can also recommend it to another calendar.

This isn't a place you put your secrets. If you don't want that to show up on other calendars you probably shouldn't put it in the system. The system is meant to have calendars that are shared. Not all events end up on other calendars. But this isn't a place for your secret meetings of some society you don't want anyone to show up to.

So that was kind of a trade-off that we made. So one way we can do is we can share and people we share it with can actually share it as well.

And then, we have basically push and pull. So these are two other ways that we can share events. So the one was the manual were I say, "Recommend this somewhere." With push and pull, we have basically the idea of subscriptions. And the way subscription works is for instance, the Arts and Science calendar subscribes to Physics, English, Dance, Geology, all of those.

So if you put an event on the Geology calendar, it automatically recommends it up to Arts and Sciences calendar. Now the Arts and Sciences calendar has two choices. One is 'Show Everything' and the other is 'Let Me Approve It'. And depending on, the School of Education might require approvals; the School of Arts and Sciences may just show everything. And that's up to each school.

But one way is to do subscript ion, which says for instance, School of Education events is going to list...These are two programs within the School of Education. If you put things on there, they're going to go up to that calendar and in this case, they're going to automatically approve them.


OK. The other way we can do it is pull. So we talk about if you have an individual event as a creator, you can try to put it on other calendars for approval. If I'm a calendar owner that I want to subscribe to other calendars, I can do that and have it basically pulled, And then the final kind of push is...

Sorry,I'm talking faster than my brain's going today. Oh, right. If I own calendar and... I'm sorry, this is the pull. If I won a calendar... Yeah, it's the manual. Man, it's on this third one.

If for instance we're talking about the homepage calendar. Where the homepage calendar works is, we have a list of all the events on campus. But that's not what we featured on the homepage. We only featured three. And so we can go in and manually bring over to our own calendar the things that we want.

So I can go in and pull from individual calendars events that I would like to focus on my calendar. So even though you put it on your calendar and you didn't recommend it to me, I can go find it and bring it on to my calendar. So you can send it to me or I can find it on your calendar and bring it into my calendar. Or you can do a subscription, where it's kind of a super set of subset.

So these are kind of the ways that we tried to bring these loosely coupled pieces together. Hopefully that made sense.

So how it plays out in reality within our site? At the footer of our site, we have one of this big footers that's kind of trendy, maybe, at the moment. The top calendars which were kind of the buckets that we're talking about, all of the events in the Academics, Culture, Service, Sports, University Life.


We have Featured Calendars. This is basically our organizational units. So we have each of our schools, Marine Science, Law and everything here. As well as the Tribe Athletics because that's a big calendar.

In addition, the Sports and Leisure which is all sporting and outdoor type of events, just at the varsity-level athletics and the Alumni Association are featured here.

And then over on the right , these are outside of our system. But there are things that people who've come to our events calendar may be interested in, as Tina referred to, Colonial Williamsburg is right next to us. It's very big. We want to be able to get over to things that they offer.

OK. Kind of the perks. Once you do something that kind of meets your goals, a lot of times, there are things you necessarily say were explicitly goals but there's certainly something you wanted to have as an outcome.

Searching, we can break out our search by dates, by keywords as well as certain types of events. And this is a different notation. It's not the bucket that it's in, it's not the department that it's in. But it's a type of event. Is it a colloquium? Is it a ceremony or an award, festival, things of this nature? So we have multiple ways to break out this information, that we can then allow people to bring it together how they would like to see it.

OK. That takes us to actually implementing.

Tina Coleman: OK. So rolling this out. First of all, when we talk about what we use, I want to get props, I don't know if they're her, but University of Nebraska - Lincoln was the open-source calendar that we landed on. We did some research and we found many. But this was the one that seems to meet most of our needs. We did tweak it to work with what we needed to do. But it did seem like the one that was most extensible. Obviously, it didn't cost us anything, And they feature a lot of the things we needed already.


So rolling this out, the second bullet says, "We informed the CMS Web editors." Well, that's what we did. We didn't ask anybody they wanted this. We decided to do this and we told them we were doing it. We informed them about two months before we were going to roll it out to say, "Hey, there's going to be this great new calendar." And we set the worries to rest that they weren't going to lose any functionality but it was going to offer so much more.

And then, again, I guess two weeks before we launched -- three weeks before -- we informed them again, remind them of the date we were launching. We told them that we are going to have a couple of open demos for them to come to.

So one week before the launch, we did hold two demos where they just came to our quick little demonstration and kind of ask questions. I think it was fairly attended. But most people, I mean this is such a simple system to use by the way we built it. We weren't too concerned. We did create ahead of time help pages. Again, kept it simple but very descriptive of how to do things if you couldn't figure it out. So all that was ready to go.

We launched, I believe it was actually, literally, February 28th. It was the last day of February. We call it our March Launch. But on that day, we had everybody sitting around the table. We grabbed people from our team, we sat around the table and we just cut everything over.

So let me back a little bit. Before that day, we asked the CMS editors who did have the bulk of the event content to not put any more events in the old system. Except for anything urgent that was coming out within the next week or two.

So we had all of the event information. We duplicated every event in the CMS manually in the new system for them. Because again, buy-in from for all those users was a whole lot greater if they didn't have to do a lot of work to make it happen. So for them it was just, "Oh I'm going to here now, and create events." They didn't have to worry about moving over stuff they had already done.


So we had that moved over. And on that day of cut-over, we changed those Listboxes to then pull the RSS so we didn't have to touch every Listbox. Not pull from Cascade events but to go grab that RSS from that particular calendar, put it in the Listbox settings and so. Literally, I think we had it done within a few hours and we were cut over.

As far as pot-lauch communications, we sent out an email to all the Cascade editors letting them know that it did happen. We actually made it so that they couldn't create any new events that day to let them know it was there. "Here's where you go to create your new events."

We used a couple of other internal listers. We have a daily digest that goes to all faculty and staff. We had done a little bit of pre-launch communications to let them, that list, know as well that something was coming. So we sent out an email to that.

And then we have something equivalent for students that doesn't come out daily. But it comes out twice a week, called Student Happenings. Because this was a brand new thing for them. We wanted them on board. We wanted them creating events. So we also communicated to them about this new system. We did that probably two or three times in their email.

We used social media. We used Facebook, Twitter to advertise the new events system. And we place prominent links on our homepage. Or at all of our webpages there in the CMS, it's prominently featured at the top. Our campus portal feature there well and of course, on the mobile site.

So Andrew had a slide earlier that he called 'Dream Big'. And this is one that is rollout part two and I call it 'Dream Bigger'. Looks just like Andrew's except as you notice there are two calendars outside of the oval.

Just like with website, everybody, even if you have a unified Web environment you don't have everyone in it. So we had the same problem with our event system. We had two websites in particular, two domains, suffer from our CMS that featured events that we thought were really important to include in our new system.


Anybody wants to take a stab at what those two are?

Alumni and Athletics. They're never in your CMS usually with you, which is fine but they do have events that are very important. I mean, I can't imagine someone coming to campus and looking at what's happening today and not knowing that there's a basketball game or some alumni-related event going on.

So obviously, two huge entities at the college that we wanted to feature events in our system. But of course, they're not interested in doing double duty and creating their event on their website and creating them in our system. So it took us about a month. But about a month after we launched, we were able to successfully bring in their events using the RSS.

Both were unique and different and both offered their own challenges and quirks. But we were able to work it our so we could pull in at least basic information offering a link back to their website so that everything was in one place.

So in conclusion, what we got. We got our one calendar, what we wanted. We kept it simple, both for the user and for the people creating events and managing calendars.

And we do want to say that we can measure that success. I used the months of March and September as examples because the summer doesn't really count. There wasn't a whole lot going on so they're pretty insignificant as far numbers of events.

March was the full month of events when we first launched. And we had 380 events on that month. September was the first full month of this semester and we had 679. So obviously, the usage has increased and I do think students had contributed a lot to that. And then as far as analytics go, you can see it increased by 2,000 as far as the number of visits and somewhere between 4,000 and 5,000 on pageviews. So we know that it's increasing. People are using it. We see that daily.

I don't think I mentioned this at the beginning, but our office, Creative Services, does moderate the events. So anything submitted, we do moderate those and decide whether to approve them on the recommended top buckets or not. So we can see just daily the numbers that come, that it's definitely increasing.


OK. And we have five minutes. I got the big sign in the back.

Question? Right here.


Audience 2 : Why is that?


What's your question? What's the noise?

Audience 1: What content management that you're using? And then what kind of team you have to make these decisions on the homepage, what pieces go up?

Tina Coleman: Cascade is the content management we use. As far as what goes in the homepage? You're talking about the events that go on the homepage?

Audience 1: Yeah.

Tina Coleman: It is.

Audience 1:You have to make decisions and then what kind of ...

Tina Coleman: Well, we have one person who's dedicated to doing that. Of course, there's back up system in place. But one person, it's her job to look at the upcoming events. It's something probably she does every two few days to look at what's been submitted and what's sitting there as upcoming events.

And she'll recommend them up to the William and Mary homepage calendar. It's a special calendar nobody sees except our team. We've told her basically think about those five buckets and mix it up between those really, more than anything. And of course, if there's something like homecoming or some really important event, some distinguish speakers coming that we really want a lot of publicity for, we'll go to her and say, "We need this on the homepage."

No. In fact, we work really closely with the University Relations. And occasionally, they'll know that something that we really should publicize, it would be helpful if it's there and they'll ask us if we can feature it. But that happens rarely, that they ask us even to do that. So I think we're doing a pretty decent job of featuring a mix of things.

Audience 1: It's not very often those pop out.

Tina Coleman: That's true. We haven't had a problem with them.


OK. I think you are first. Yeah. Or one of you.

Audience 2: You mentioned you're using UNL. You said you tweaked. Was that a misnomer? I'm curious how long it took you.

Tina Coleman: I'm going to defer to Andrew for that one.

Audience 3: We're trying...

Audience 2: Because it seem to me, you changed the admin quite a bit and...

Andrew Bauserman: We totally replaced the admin. That was the tweak we did.


We tweaked the admin side by replacing it.


Andrew Bauserman: We aren't quite ready to release that back to the community but we do plan to, basically, finish what we did so that it make sense. Because when you take a system and you tweak it heavily, it doesn't necessarily make sense for anyone else. So our plan is to finish kind of teasing that out to where it still make sense.

But it's not going to be the same product. It's not going to be joining back in with their product. Because, their institution is not going to want the changes we made. But if someone else does want the changes we made, we are interested in releasing that back.

Audience 2: I don't know if you want to say or not, but is there like a rough estimate of how many man hours you put in to that? Or would it have been easier to build from scratch or to modify UNL?

Andrew Bauserman: So that's always the decision is, we have many calendars on campus. And because of that we didn't have a budget to buy another one because the administration would say, "Well, we have blackboard and luminous and EMS and... "

Tina Coleman: Outlook.

Andrew Bauserman: "...Outlook. All these thing have calendars in them. Why do you need another one?" So none of them did exactly what we wanted. So we found an open-source.

We were thinking about building it. The advantage we had here is that when we get done, it may not be much different than having built it ourselves but we could get it going faster. The people who are entering all these duplicate events from the old system could start before we finish making it all pretty. So it allowed us to work in parallel which is something we might not have had.

So again, that's a decision every institution makes is, do we buy or do we build or do we modify something? And that's just what we ended up with.


Audience 1: I'm not familiar with what Cascade. So which one is the software that actually?

Andrew Bauserman: The UNL released a calendar product that's open-source that we modified. Cascade Server is one of the vendors upstairs that like we update in Cascade and those guys who make content management systems. So our Web server is in Cascade.

And three and half years ago when we launched that, we didn't want to get sidetracked off that project by saying, "Let's include an events calendar at the same time." We made a page type called Event and we could list the pages in chronological order. And so that was in our CMS, not in event system. But it was a list of pages in chronological order that we call Events.

Tina Coleman: We had a home-grown CMS prior to that, that had Events feature. Again, we didn't want to lose functionality so we made it work in the Cascade. We quickly obviously realize the limitations as far as events go.

Audience 4: But there's calendar stuff.

Tina Coleman: UNL is a college that built an event system in an ... Oh, yes. We're using it. Yeah, yeah, yeah. Sorry, it's not a product. Yeah. Yeah.

Any other questions? OK.

Moderator: One. One last question, anybody?

Audience 5: The permission and when you pull and then, do you email a vendor that content and of this was shared? And with main calendar, can someone change the title as well? And is there any board?

Andrew Bauserman: Right. We have some permissions. In Calendar, we have overall admins. We have calendar admins and we have calendar editors. And then we have just anyone with an ID can submit something but it doesn't have approval yet.


The calendar admins can modify events that have been pulled on to their calendars. The person who brings the things like into the very top calendar is actually like a super admin. So a super admin can actually pull any event from anywhere to anywhere. Whereas, a regular departmental person would have to either push it or request that the other person push it.

So there is some level. But there's also some level of openness. Once you do that sharing, you are both. If you're an admin of either, you are an admin of that event.

Tina Coleman: And just for the top level, if somebody that we've approved... Something had shown up, let's say on the homepage, on where there's top buckets, those top five buckets and somebody changes something, the date, it goes back into pending.

Andrew Bauserman:Yes. Yeah,

Tina Coleman: We have to approve it again. Yeah, it changes the status.

Andrew Bauserman: Yes. True.

Moderator: OK. Thank you.

Tina Coleman: Thank you.