APS5: Engaging Your Campus using a NextGEN Calendar of Events System

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

A little bit about the University of Ottawa. We're located in Ottawa, Ontario. It's Canada's capital. It is much colder there right now than it is here. There are about 40,000 students, 5,000 employees and 170,000 alumni. We have over 450 programs in 10 different faculties in both undergraduate and graduate schools.

We're among the Top 10 research-intensive universities in Canada, so there's a big focus on research at the university and it's an important aspect of what we do.

One of the biggest challenges, though, is we are a fully bilingual university, French and English. A student can choose to study in the language of their choice or a combination of the two, so we try to offer almost every program in both languages. This means that all of our systems have to be fully bilingual, so in terms of going out and buying systems, that often makes things very difficult for us.

It's not only the front end that needs to be bilingual. A whole lot of our staff is Francophone first, Anglophone second, so the back end or the administration side of this system has to be bilingual as well, which always causes problems. And we'll discuss those later on.

One of the other things that's important to note about the university, and we'll get into it a little bit more, the actual physical location of the university is right in the heart of the city. We're fenced in by a canal that's really nice. It runs through the city. In the winter they freeze the canal, they flood it, you can skate on it. It's really good.

But we're in the middle, we're fenced in between this canal, a residential area, and a commercial area, so it's really forced us to become part of the community. So we're not separated off. We've really ingrained ourselves into the community, and that will come up when we talk about the calendar.

So what are we going to talk about? Well, we're going to talk about project initiation. We'll take a quick look at the old calendar and just see why we needed to change.

We'll talk a little bit about our new Vision 2020, which I've just launched recently, and how this project fits within that vision.

How did we get there? What were the steps that we got there to start this project, do the development, and hopefully get it out? We'll show you the calendar.

We'll talk about some of the features and functionality. We'll briefly talk about technical, how long the project took, what it means to push this into production, plus, as with any project, what did we learn? What did we do well and what did we not do well?

And then we'll have some time for questions.

So how did all of this start? About 10 years ago, we had a nice, shiny new Calendar of Events tool. Like a lot of universities, I suspect, it was good. It showed the events. It was very list form. I could tab through, I could choose a day, I could see the events that were on that day.

But there was no real pizzazz to it. And after four or five years of it working, it started to break.

It was a third-party application that we had bought, fully bilingual, but when we negotiated it, or whatever people negotiated it, there was no maintenance agreement or service agreement. Anytime a bug was fixed, we would have to pay extra to have that bug fixed, or if we wanted new functionality, we'd have to pay to get that functionality fixed or added.

So what started to happen is, people, as the Web evolved and as other tools evolved, they went out and developed their own tools and said, 'Oh, I don't want to use that other tool anymore. Every time I go and ask to have the calendar updated, they always tell me it's a budget issue, and I don't want to do that. So I'll use it until it's not convenient, and then we'll go off.' So at the university, we ended up with a bunch of different tools all over the place.

What really happened, though, is our student groups started to complain. They had a calendar, especially our student federation, they had a calendar which wasn't meeting their needs anymore. They investigated having one built, and then they wised up and they said, 'Well, wait a second. The university itself has a calendar. We should be able to use that. But it's no good, so we don't use it.'

So like the mobile presentation that was in this room earlier, it was actually the students that got us, they raised enough complaints, and they got us in front of the people that make a decision and made them realize that, 'Hey, yes, we do need to do something about this project. We do need to do something with this new technology and change it and bring it into present time.'

So you really can't see that. It would not be very accessible, is what I have to say. Our calendar can't be that. It is that bad. It is really, really bad. It had not scaled at all to the growth of the pages and the number of people trying to access it here at the university.

It can't feed any mediums. One of the other tools that I use is, I own mobile stuff and the student portal, I can't even put a version of the calendar within my portal because I know the load that the students will generate on the calendar will kill it.

It's got poor back end management. It used to have some semblance of a workflow to promote events and stuff. No longer. It doesn't work anymore. If you want to get events promoted, it doesn't work. It's all done manually now. And it hasn't been meeting our needs.

There's no pizzazz. You can see that...well, you can't see it, but it's not pretty. And it's slow. It's really, really slow. If I was to try to load it, it would just sit and we'd wait.

So this is great. The students got together, we agreed, and then we presented it as a potential project to the director of Student Services.

One of the selling features of this was that the university at the same time was working on its Destination 2020 strategic plan and we were able to show how this project would actually fit within this plan. Two key points of this plan was to offer students an unparalleled university experience.

So, yeah, it's great, we do the best that we can in academic, we do the best at some of our administration tools, but there's more to university than just going to school. Students want to be part of the community, and this is a means to give them a way to see what's going on in the community and see the events. There's a lot more at our campus that we offer than just the academic side of things.

The other side of things, and this goes back to our location, is we really wanted to expand our fingers out into the community.

So we're very active in the community, again, based on our location, but we wanted to have a tool that is not only promoting university events but would have the ability to promote non-university events or community events. This is really important to a lot of people at our university because where we are a bilingual institution, they see us as one of the primary promoters of the French culture within the city. So it's a good way for us to get events out there.

So they were convinced. They said, 'This is great. You know what? It aligns with our strategy. Yes, the current tool is no good. You really need to do something about it, so go for it.'

At this point, I want to stress that this is not an IT problem. IT was certainly part of it, but it was a lot more collaboration that was involved in this. IT, Web Services, Communication, Marketing all got together and worked as a team to kick-start this project and find out the directions that we wanted to go.

Just getting started, there's a lot of collaboration upfront. As the project moved through, we trimmed the number of cooks down a little bit as we got our focus, and then were able to go through on a much more streamlined team.

The overall team, once we did this initial collaboration between all these groups saying, 'Yes, we agree. Let's go,' the final team ended up really being Student Services, Communications/Marketing, and IT. From that point on, we had a core team that could go forward and move this project.

'Frankencalendar'.

What we did is we went out first and we had ideas. People say, 'Oh, yeah. Well, I need a calendar to do this, I need a calendar to do that,' and some of the students had seen calendars that they liked.

But what we really did is, as a group, we went out and we spent a good time a couple of weeks going to all sorts of different calendars, finding stuff that we liked, finding stuff that we didn't like. I apologize if anybody's calendar picture is up here. We went out and we took all of those features around and put it together to start building our initial set of requirements.

In essence, this was the initial requirement-gathering. It wasn't the final requirement-gathering, though, for us, but it gave us something and it helped shape our vision in saying, 'Well, it needs to be high-accessibility. It needs to have these features. It's got to integrate with social media. It's got to be current. It's got to be intuitive,' which leads us all to talking about the overall vision of the project.

So all of the bells and whistles are nice, 'Yeah, it's great that I can like an event on Facebook,' or 'Yeah, it's really cool. I can send it. I can tweet out an event,' but if the site's down, it's no good. If I can't consume feeds into other devices, it's no good to me.

So all the bells and whistles are nice, but it really had to have an overall vision. And the overall vision that we were looking at was a unifying tool, an intuitive look and feel. Something that isn't too far out there, something that when you surf to it or end up on it, you'll know how to manipulate it and get the information that you want out of it. It's got to be Web-based, it's got to have modern functionality, and it has to have high availability and fast performance.

What we've seen, as our web community has grown from mobile, portals, other websites consuming our old calendar, like I said, it really slowed us down, this calendar, we have to be willing and able to accept and feed a whole bunch of different items and consume. And we'll talk about the feeding and consuming later.

Sorry. Just one thing.

One other thing as well. We go back to the 'Frankencalendar' comment. Yeah, it's really good, again, to take all the good pieces from everything, but as we all know, when you put all of the good pieces together, it doesn't necessarily make a good whole. And again, that's why this overall vision was really important to us.

Let me help you help me. So we've talked about all the bells and whistles. We've gone out there, we've grabbed little pieces from the Web, we've built a real portfolio of the ideas and concepts that we like, we have an overall vision, we have support from the upper echelons saying, 'Yes, this is something we need to do,' we have student involvement, but, again, none of this works unless the community itself buys in.

Yes, we had web people involved, we had Communications, we had Marketing, but we need faculties, we need the services, we need the other student groups other than our student federation to get involved and want to be on board. Unless there's events in your calendar, it doesn't work for anybody.

So we really set out and did a lot of community engagement, and this involved taking the concepts that we had going to specific sites, going to websites and showing them, 'This is what our calendar's going to be. This is what we like. What do you need?'

We listened to a lot of feedback from our web designers. 'What do you want to see in a calendar?' They all came back and said, 'I don't want to do much work. I want something that I can embed easily in a webpage,' or 'I want something that will open in RSS for us' so they can manipulate their events themselves. Again, we took all of these and finally built our requirement document.

Once we had our requirement document, it takes us to the age-old question: Do we buy, or do we build?

If we buy, everybody knows, there's requirement gaps, so you have to take a square peg and fit it in a round hole sometimes. Some products out there were very, very good and it was hard to make a decision to go against them or for them either way.

But in the end, we decided to build because we had requirement gaps in the products that we looked at. We weren't keen on the annual maintenance cost of it. Lately we've been in the habit of doing a lot of stuff in-house, having that expertise here so we can make the changes ourselves.

It wasn't bilingual. It's very, very hard as a bilingual university to get bilingual products. A lot of companies say, 'Yes, our product is bilingual,' until you start getting into it and it turns out to be far, far from it.

We didn't have any code ownership if we bought it and future development is uncertain. You're on somebody else's development schedule with a new project. Of course we're going to miss requirements. Needs are going to change. We wanted to be on our own schedule to get a product out and continue to maintain it.

So that's really why we made the decision to build, so we got to direct the technology choice, it's hosted on-site, the code is ours, we own the code, we can change it as we see fit, we'll the full administrators of it, we can address any requirement gaps, and we can plan for second, third, fourth phases of this. Plus, most importantly, we can make it completely bilingual, and that's the front end and the back end of it.

So what does it look like? It's pretty nice. I think we've done a good job.

Just back up one second about the buy-in build. Internally, we do not have all of the resources necessary to do all of the development work ourselves, so we worked in collaboration with an external company on this. But it was based on their pitch. Their technology that they chose was what we wanted to use, and we've done other projects with them.

At the end of this, we do end up with all of the code ourselves. We own it. We can change it. We can do whatever we want with it after this fact.

The big reveal. What does it look like? We'll talk about the front end, we'll talk about event details, and then we'll talk about the administration dashboard.

Before I show you the final picture, and I'd like to say I'd love to show you this live, but like another presentation earlier this morning, we've been delayed. By this time, when we pitched this several months ago, we thought we would be in prod. We are about three or four weeks away from going into prod, but we're very, very close on this. And we'll talk about timeline later on.

Some of the front end features. We have a campus map-Google map integration. Again, the old calendar had none of this. It didn't integrate. It was very static content. I typed in my site information and then it was up to the user to figure out where that site was. Now we've integrated it, it's all latitude-, longitude-driven. I can click on it. I can get directions to the event and stuff like that.

We have event notification feeds and action, so I can push events out into the cloud, into the social network, which is very, very important, and we'll talk about that later why we wanted that.

A full keyword search. So I just don't have to search title, I've got a full keyword search of any text within the event details or description.

I have featured events.

One of the things that our old calendar did not do was just a list. The new calendar is not only a way to show students what events are on campus, but it's also a marketing tool. You really want to get to promote what's going on on campus. You get to highlight events. So we have featured events that rotate through.

I have a search events page, I can add to my calendar, and we do some really neat things with event filtering.

The front end. Recently, we've gone through a redesign of our website, bringing everything into, or are in the process of bringing everything into this 960 template. The new Calendar of Events will fit within this template.

Some of the quick features that we see is we have our 'Featured Events'. This rotates through. At any point, I can click on an event, get more information about that event. I can choose how I want to see the event, whether I want to see a day, week, or month view.

I have a current search. The search I do is a faceted searching, so the university defines a default search. At that point, I can then start removing or adding items and narrow that search down and get to the items I want. Any search that I do will then let me export an RSS feed or embed a widget into my own account.

So if I'm very interested in sports, theater and lectures about Biology, I can build that search myself, embed a widget right into my own account, and then I have my own personal calendar of University of Ottawa-type events that will only display up for me. It's really interesting.

One of the other things that we wanted to do is, again, because this project was initially initiated by students, we really wanted to promote student events. So right now, yeah, the corporate events, the lectures, the special speakers, the President's Day, that's all very, very interesting, but going back to 2020, we wanted to show that this was a tool to involve our students into our community.

You'll notice here we have a special pre-defined filter called 'Student Events'. I could go in myself and I could narrow down the default search to show student events, or as a student I can just click on 'Student Events', it will show me all events run by students for students and university events that are for students as well where the intended audience is students.

It's just a way for us to give a quick way to search. This way, it also pulls some of the less desirable student events off the main page, because, again, this is a marketing tool for the university. We really don't want a featured event being a keg party or we don't want a tuition protest or whatever one of our main events, but we still need to provide a service to our students, we still want to give them the right and the ability to highlight their issues and concerns and events, so that's why we've created this special filter.

The details. Clicking on any event gives you a certain amount of details. We allow the embedding of images with any event. We allow the adding of extra media with events. So if you want to attach a video to an event, that promotes it further.

Main details are stored up right in iSight when the screen opens up. This includes location, time, the type of event, the audience. Other, I'm going to call, secondary information about the events such as registration, additional media is stored in its own little blocks right underneath the event.

Again, it's very clear. It's not overly fancy, there's not a lot of stuff happening on the screen, but we feel like it's a really easy way to see what is going on with that event.

At any point, I can switch between languages in the calendar, both events. If an event is not fully bilingual, though, the event itself will stay in English, but it automatically inserts a note saying, 'This event is English only,' but it says it en Francais.

Some of the other features. I can then mark my calendar. By clicking on the 'Mark my Calendar', we get another window that opens up. I can add to Google, I can add to Yahoo!, Outlook, iCal. I can tweet the event and embed it or I can 'like' it on Facebook.

This is really, really important to us. So it's great that all of the events are in one central location, we have a nice tool, but unless you start pushing stuff out social media-wise or to the cloud, it doesn't really promote it. I want to be able to follow somebody's Twitter feed and say, 'Hey, yeah, John's coming to this event, too. I'm going to go. That's really interesting.'

So it's not only a service to our students and our people who want to attend these events but it's also a service to the people giving the events. Again, it's promoting the event, it's getting it out there, and getting it visible.

What about the back end? Front end's nice, it's nice and clean, it's simple, there's not a ton of stuff going on on it, we think it's quite user-friendly. Back end, again, is another problem with our old calendar. It was very, very cumbersome. Creating event, you would publish it. You wouldn't even know if it got published sometimes. It wouldn't show up. There was some sort of weird caching thing that was going on. Sometimes events would show up after they actually occurred.

So we really had to nail this down. This is great for people who want to see the events, but unless the back end was nailed down and it was easy to put in events, you aren't going to end up with events in the system. So we really focused a lot with the internal community and the main groups within the university that create events and focus on this piece.

We have a user dashboard. It's highly configurable. There's a whole workflow associated with creating events and managing calendars that we can talk about, plus I mentioned the widget for website integration.

Logging in. First, the log-in problem. It wasn't really much of a problem for us at all. We integrated with our existing LDAP. So if you have an employee account, you have access to the calendar or to the back end of the calendar. It does not necessarily mean that you can create events and post events, because you have to be set up as one of three roles, whether you are an event creator, a calendar owner, or the calendar administrator. We'll talk about those roles in a minute.

But some of the first things that you see when you log in, you see all of your currently published events. They're all separated up. I can see it. I can edit it at any point. If I have very similar events, I can copy those events and create copies and publish existing events based on that.

I can remove my event very easily, so if the event has happened, I can get rid of it. Or, actually what happens when you create your event, we set a 'published on' and an 'unpublished' date, so a lot of that stuff happens automatically. But if an event gets cancelled, it's very, very easy to remove.

You see your organization membership. This goes back to the roles. As I said, when you log in you can be an event creator, a calendar owner, or an administrator.

If you're an event creator, you belong to a calendar organization. So I belong to the Biology Calendar, which is a sub-calendar of, say, Science. All I can do is post. The only thing I have permission to do is post events to the Biology Calendar.

Based on certain settings and roles and responsibilities within that's assigned to my user and my role type, that event may or may not get published up through the ranks. So there are certain types of events that we remove automatically.

For example, one of the things that shows up on our calendar right now is thesis defenses. So, yeah, that's really interesting if you care about the life cycle of a frog, if you're in Biology, but at the top level, that's not something that the university really wants to put on its front page or main calendar of events. So that by default would get filtered out of our main filter but still show up on the Biology and maybe show up on the Science calendar.

Everything's controlled. It can be tailored. All roles are predefined, but you are not limited to having hybrid of those roles. It's a matter of going in and saying, 'Well, John, he's an event creator for Biology, but every so often he does some stuff for the Chemistry department, so I can take a button and give him access to the Chemistry Calendar as well.'

At the next level is the calendar owner. The calendar owner is the manger of that calendar. They can create events that, again, go for their main calendar or are pushed down to calendars. So if I'm at Science and I want everybody to know, I can push events down to my Biology and my Chemistry calendars. I can also block events from coming up.

If by default I allow thesis defenses to come up from the sub-department calendars into my faculty calendar, I can say, 'Yeah, the thesis defense on the life cycle of frogs isn't really something I want to put on my calendar today because I have enough events.' I can block that and deny it and then push it back down.

As a calendar owner as well, I can create events. I can also create events that go up. And again, they follow the same sort of rules. If I create an event that doesn't fall within our predefined search, it won't flow up, but I can make special requests for events to flow up. So if I have a really good thesis defense coming on that I want, I can make a request, and that request will follow through a whole workflow process to get to our calendar administrator.

Calendar administrators are the overall omnipotent people who manage the whole calendar. These are people that are the Marketing and Communications group. They have full editorial rights on any event that's posted or pushed up to them. They can remove events. They can also promote events that they see. So if they're going around and they see a specific science event or a sports event that they want to promote and feel should be highlighted on the university calendar, they can.

They also manage events that are requested to be featured events. If you remember back at the front end of the calendar, we had these four rotating events. Any time I can create an event and request that it be a featured event, there has to be certain requirements for that featured event. It's got to have a picture, certain details, it's got to be vetted for languages, go through translation services, linguistics. But I can click a button and request it.

As an administrator, when I log in, I will see my events, my organization membership, but I'll also see any requests that I have to approve. Anything for me to promote it, I tick a button and it gets promoted up to the calendar.

We've tried to make it as simple as possible. This whole process before this tool was all managed by email. Requests would be sent; they may or may not be answered. Now we've integrated it within the tool.

Serving and consuming. I've kind of talked about this before. We've had a lot of times where, in the past, and tools that I've worked on myself that we've really wanted to pull in the calendar. We have a mobile site, we have the student portal, and we've tried to pull in the calendar, but the load that these sites, for example, were putting on the existing calendar would actually take it down. So it was no good for us.

So one of the key requirements of this tool is it really had to go out. We really wanted this to go to social media. We wanted it to be easily consumed by a mobile site and displayed.

We mentioned the personal calendars. It's got to go everywhere on the Web. But not only the uOttawa Web, which we mentioned here, but like I said before, I can create my own specific search tailored for the interest that I want and embed a widget in a webpage that I have, for example, and we need it to go to our portal.

The other thing that we really needed to do is, so, it's great, we've designed this calendar, there are other groups on university that have gone off and are well-ingrained in their own Calendar of Events, and specifically I'm talking our business school. They got tired of the old calendar. Our GG Sports, our varsity sports got tired of the calendar, so they've gone off and had their own tool.

And that's great, and they're very, very happy with these tools, but what we needed to do is I still want that varsity game in there, I still want to see when that business speaker comes in there. These people don't want to enter 'Events' twice.

So what the calendar actually does, it can consume RSS feeds from other Calendars of Events, we can program those ourselves, we map whatever that feed is into our fields, and then we can display it. They may not get a picture, they may not get 100% mapping, but we'll do our approximation the best.

If they want things to really work out nicely, the plan is for the sports guys, the business guys to modify their RSS feed to us a little bit so we can consume it a little bit better.

We're going to talk about the community side as well.

So the tool is nice, I have access through my LDAP, all the employees in the university, if they're given any membership into a calendar, can access it or not. The long-term goal, the next phase of this is to turn this out to the community. We want to be able to create non-university accounts for different community organizations so they can start using this calendar as a way to promote their events around the university and ingrain us more in the overall community.

By having the pre-defined filter, we get to keep those events off our website. They may not jive with the university mandate or anything like that, but we still provide a tool to our community that can start promoting their own events and stuff.

Where are the events coming from? I've kind of talked about this a little bit earlier.

It's really a hierarchical structure. Events, I like to say, flow up for this one. If you look at Science, you can have any number of individual sub-sub-calendars. In this case, we have Biology, we have Chemistry, we have Physics. Each one of these calendars have their own calendar owner, they have their own event creators.

People, they manage these calendars, they're embedded on their pages as they see fit. As the Science Calendar owner, though, I can pick and choose what events I want to come up from Chemistry, Physics and Biology. Or I can just bring all events up. It's up to me. The same thing happens with sports.

Some organizations, and I'm talking about the student federation, may or may not have a sub-calendar. You don't need to have one. It just flows up. There is an unlimited number of sub-calendars and sub-sub-calendars. I think some groups even have sub-sub-sub-calendars. But it all flows up, it's all available.

One of the really neat things about this tool is, I may start here at Biology, and that's fine, I'm a Biology student, I go to the Biology page, I check things out. When I get into the event details, it will actually take me into the uoCal, into the main structure. So I'm starting at Biology, I'm ending up in this main tool, which could potentially lead me to events that I may not see if I'm only looking at Biology.

Again, as an event creator or someone who wants to promote what's going on in the university, it can really push your events out there and expand your audience and who you're contacting.

The technical slide. I won't talk long about the technical slide.

We are built on the latest version of Drupal, Drupal 7. There was a discussion of whether we go 6 or 7, and we went 7, and we'll talk about issues that we may or may not have had.

It's an extensible framework, meaning that we can build on it. We're not stuck with this. At any point, I can create any number of new groups. Right now, I can create new roles. I have three roles. If in the future we decide that we need a new role, it's very, very simple for us to create new roles. We're not stuck in this structure.

We have Apache Solr back end driving our searches. Drupal, we have a Drupal 7 optimized search engine. We do authentication through our existing LDAP.

Looking at high availability, we have a VM installation with multiple VMs, two or three right now, behind a load-balancing ACE. Those VMs are easily cloned. If we see load coming up high on the servers, we can clone a VM and add it in very, very quickly.

The whole goal is, as this goes out more, we're definitely going to have to expand our infrastructure underneath it, but with the VMs, it's very easy for us to expand and get that rather than having to get a physical piece of hardware in place.

There's a lot of work. How long did it take? Right now we're approaching five to six months' worth of work.

Project was first brought up, let's say, eight months ago by the student federation, who were very, very active and very good to work with. You get lucky sometimes with the student federation. Sometimes they're very activist and very oppositional. The current group that we had at the time when we started the project, they really, really wanted to work with the university.

Project Commit. When we do a software project at the university, we talk about Project Commit.

Project Commit is when we have our resources lined up, when we have our requirements complete, we've made our technical decision, and everything is in place and we have our project plan to go forward. So project to get all the requirements, build 'Frankencalendar', go out and set our vision. It took four weeks.

Development and unit testing. It's been about 16 weeks now. This will go a little bit longer, but we're into the last stages of the issues that we're having.

Product verification. We've done most our development by an external company. We've worked very closely. We have very regular meetings with these. They've really become part of our own team.

We have our own product verification team. I have three or four software testers that sit and use the tool as a user. We had test plans written by them and they follow through that. All bugs are tracked and then reported on or retested as they're fixed.

Finally, after product verification, so it's great IT, we can say, 'Yeah, the product is fine,' we give it to our client acceptance where our end users, the non-technical, the Communications, the Marketing people, the people that are going to use this day to day take it, run it through its paces, and make sure it does everything that it's supposed to do. That final client acceptance, installation and hand-off is going to be about four weeks.

Aren't you worried about launching? Yes, we are worried about launching. It's one of those things. It's been a big project. There's been a lot of people involved. There are definitely people out there, again, when you do any project, there's somebody out there that thinks, 'Oh, they shouldn't be doing it this way. Why did they choose Drupal? Drupal's no good,' or 'Why are they building this thing? Why don't they buy it?'

It's definitely on our minds, but I think we've done a lot of stuff to de-risk it. And some of the things that we're going to do to de-risk it is we are not doing a full launch right off the bat, we're not cutting from the old calendar to the new calendar right off, but what we want to do to build up the traffic and see things that are working, we're going to give it to services, we're going to give it to faculties and departments and let them go with it first.

So the main calendar, it's going to be live, it's going to be sitting there at uocal.ca. There won't be a direct link to it. The only way to get into it will be getting through one of the smaller calendars that go up. This way, we have a slower adaptation.

The timing of the launch actually worked out very, very well. Initially, when we launched the project, we were supposed to be live by this time. With some delays and some issues that we've had, the project's been pushed. Right now, we're looking at a mid-November launch.

So a soft launch mid-November. We're going to get events in there. It's going to be up, really it's going to start getting used in December, which is a nice, slow time on campus, people are focused on exams. So we're really looking at, come the beginning of January, we'll have a full launch.

Sounds great. Were there any problems? Yes, there were problems.

We tried to do everything, including the kitchen sink. It's very, very functionally rich. By having so many features involved, it's made development difficult. There's been a lot of tweaks, there's been a lot of different stuff going on. We've had a lot of requirements. The requirement document is huge. We tried to get everything in.

Drupal 7. The decision was made to go with Drupal 7. That decision actually has slowed down some of our development a bit. There's been a lot of modules that we needed that weren't as far along in development as we expected or as the company that we worked with expected. They've had to do a lot of custom work themselves.

I think in the end we're going to be safer by having Drupal 7 because we're on the newer version. There's some really good stuff in Drupal 7. But it's slowed down our development.

User adaptation. With any project this big, to get it out there is going to have to take a bit of a cultural change and to get people on board and realizing that this is something good.

Plus, the bilingual. It's always a problem for us. Events have to be translated. All of the work has to be translated and it always makes life hard.

I've talked really quick for the last slide because I was being shown numbers.

That's it. Any questions? Yes.

Audience 1: [Indiscernible]

Robert Sawler: That would be really good. Unfortunately, our LDAP doesn't have that information in it.

Ideally, our LDAP would know that when you sign in, you're a member, you work for the Department of Biology, but it doesn't. So what we have to do is we have to set up the accounts to start.

In the future, the plan is the calendar owner will receive the request for an account and be able to manage all of their own accounts within their own little bubble.

Audience 1: [Indiscernible]

Robert Sawler: Yeah, you can log in right now. That's right, that's right. Yes?

Audience 2: [Indiscernible]

Robert Sawler: Phase two, yeah. Everyone wanted to say, 'Oh, you need to do e-commerce.' The structure, the architecture is set up for it; we haven't implemented it. And a lot of it is because, it's really weird, we've been a slow university to adopt a university-wide e-commerce solution, and I think that held things up a little bit. There's a lot of, like our Alumni Office has one thing, Donations has another, Sports has one, but I think they really have to get a unified tool in place. We can provide a link to the registration and payment, but it's not one tool.

Yes?

Audience 3: [Indiscernible]

Robert Sawler: Yeah, maybe. Yeah. It's still too early now.  A lot of the custom stuff is ours. A lot of the non-custom stuff that the company has done in terms of faceted searching, I think some of the translation stuff they release, so they're very big active members in the Drupal community. So anything that they do that will benefit the community as a whole, they have put out.

One of the things that we were interested in is having this as a product and perhaps doing something with it in the future. We are building a Drupal team ourselves. Our portal, we're looking at doing in Drupal. We're doing our CMS in Drupal. So we're building that expertise and it's something that we're looking at managing in the future.

Audience 4: [Indiscernible]

Robert Sawler: OK.

Audience 4: [Indiscernible]

Robert Sawler: Oh, yeah.

Audience 4: [Indiscernible]

Robert Sawler: Yeah.

Audience 4: [Indiscernible]

Robert Sawler: Yeah. Campus Rec could make a request to...or maybe Physics, for example, is doing the physics of a soccer ball going into a net. Yeah. They could request it to go that way as well. This person would have to accept that request and then promote it to their calendar. That's right.

Audience 4: [Indiscernible]

Robert Sawler: That's right.

Audience 4: [Indiscernible]

Robert Sawler: Yes, they check it. Yeah.

Audience 4: [Indiscernible]

Robert Sawler: OK.

Moderator: One more question.

Robert Sawler: Yeah.

Audience 5: Actually I wanted to, could you describe what kind of staff you have dedicated to this moving forward, because you're going to launch this? And then, what are the system admin requirements and then contents in the administration requirements?

Robert Sawler: That's right. As a sys admin on the technical side, within my team there are three Drupal designers. I will have one guy who acts as my sys admin and handles the bugs for this.

On the overall management side of this, the business owner of this tool is going to be Marketing and Communications. They have one person who is dedicated to the university website promoting events and ideas within that website. They are going to manage that. They'll be the first point of contact, so as a user, if I'm having issues creating an event or posting on an event, they're going to be the first contact. If we find that it's a technical problem, then it comes to my team.

Audience 5: So you can escalate it from...

Robert Sawler: That's right. That's right. I'm lucky because I have infrastructure guys with me, too, that manage VMs and stuff like that, so on that side of the technical, we can manage as well.

Audience 5: So it could take up to three, four people to actually manage the Events System for uOttawa?

Robert Sawler: Yeah. Not full-time.

Moderator: Thank you.

Robert Sawler: Thanks, guys!

[Applause]