 So, thanks everyone for coming to my presentation. I wanted to start today, I went to an earlier presentation, it was by someone else who was presenting from a university and I noticed there was a lot of people from universities there so I wanted to ask, is there anybody here that's also from a university or has worked with a university maybe? Okay, great. We're also going to talk, I'm also going to talk a little bit about the freelance people that we work with. So if you're from a smaller or an external, what we call external companies, you'll have information in here that will be relevant to you as well. So my site or my presentation is called How and Why Drupal Powers 850 Websites at McGill. I was surprised when I mentioned the title of my presentation to some people, they thought that McGill only has one site. If you're one of those people in the room, it does seem like that way sometimes because our URLs are McGill.ca slash something. But actually all of our slash websites are managed individually within the departments that we work with and there's 850 of them at McGill. And that's just websites that are on our centrally supported Drupal system. There's probably thousands of sites in total that are produced by the university altogether. So my name's Joyce. I have worked in higher ed since 2002. McGill is the fourth university that I've worked at. And at McGill, I'm working in IT communications. Prior to moving to the IT department though, I was also in communications on their centrally supported communications team. So I've kind of flip-flopped back and forth throughout my work history, communications IT. I've worked with Drupal since 2010, but McGill is the first university that I've worked at where Drupal has been our centrally supported CMS. And I'm really happy about that. I've worked with Drupal at the other universities that I've been at, but they've been for small standalone sites. So it's really exciting to be able to work at a much broader scale with Drupal. So this is the agenda, the things that I'm going to talk about today. When I initially started doing this presentation, it was in tandem with our senior developer. If you looked at the picture on the Drupal North website, it was a picture of him. He couldn't make it here today in case you're wondering why I don't look like that guy. But I'm going to go through his talk. His talk was more the technical side of things. I'm going to go over it at a high level. I don't understand it as in-depth as he does, but I should be able to answer your questions if not, then I can take the questions back to our team if it's really important. So I'm going to go through the then and now of McGill's website. I'm going to talk a little bit about our technical architecture and deployment infrastructure. And then I'm going to get into the support, documentation, and training part of our process. I'm going to get into the how, but I feel like taking a look back at McGill's history that our web history really explains the why. So this is a look way, way back. This is from 1997. So it's an example of from 1994 to 2000, McGill's websites were a decentralized collection of standalone HTML websites. And this was what the homepage looked like. Our manager was around when this site was in existence. And I don't know if you can see this McGill University treasure hunt. I don't know if you were around during this time, but you might remember doing these kinds of things to get people to go to your site. The prize for this, it was like a treasure hunt where you went through the site and you tried to follow a set of clues. And if you found the treasure, you could enter a draw to win the prize. They were computers and they were $5,000 each and there were five of them. So some of the things we did, I mean now we'll spend that money on an ad campaign. But back then we did it kind of this way. So from 2001 to 2006, there was a custom CMS that was introduced. And it was pretty successfully rolled out throughout a broad swath of the sites at McGill. So this is what it looked like back then. You can see it starting to look a little bit more like we expect sites to see today, that we see today. This is another version of that custom CMS from 2010. And then here is when we migrated on to Drupal. So this is what the Drupal website during most of the time it's been in Drupal has looked like. It's been in Drupal since 2001. In 2006, we migrated to Drupal 7, not Drupal 7, sorry. In 2006 we migrated on to Drupal 6. In 2010 we started migrating into Drupal 7. And that's when I arrived at McGill. When we finished the Drupal 7 migration I was actually happy to not be part of that process. I hear that it was pretty painful. But this is what our site looks like today. And we're in the process of doing a revamp right now of our homepage. And we're working with an external company to do that. The name of the company is M. Stoner. And they're taking us through a lot of user mapping, UX testing, design sprints to come up with the look of our new site. So here's where we're at today. We have 850 Drupal sites at McGill. We get 8 to 10 million page views per month in Google Analytics reported in Google Analytics. And our Alexa rank is 115 in Canada, which is pretty good. I was interested to hear when we attended the keynote this morning that they also get roughly the same amount of hits as us, which I found kind of interesting. Government Ontario McGill homepage, interesting. So our project goals and scope. We have a tool that is available for no cost for all of authorized McGill users. That's unique to McGill. It's the other universities that I've worked at. It's been a paid service. So there's a department on campus that provides the tool that and if people want to use it, the departments that are using it have to have to pay for that service. But at McGill it's free, which is really nice. New features are added only when they're relevant to most of our user base. So as you can imagine with 850 websites and a really diverse set of needs, we get a lot of requests for customized tools and we can't do them all. Some of the custom work is done by external providers. So if you have a use case that you feel as a department you need to have, sometimes those departments will go outside the system and will work with an external company. So our core team, we have 10 people on our team. We've got a manager and product owner. We've got four back end and two front end developers and three support and communications people of which I am one. We also have a much larger extended team. So we work with a group of people in IT services that provides training and creates documentation for our user base throughout McGill. So when you look at the total number of people on our team in IT, there's about 20 people all together. We also partner a lot with the communications and external relations team. And they're the people that decide on our content standards. So our style guide, our brand guidelines, our writing guide, that all gets generated from them. And the two of us will work together to help the teams that we're working with to create really great websites. So basically we're trying to produce like a square space for McGill. Something that we've got tons of users that are using our tool. They have a very diverse skill set. They all need to be able to create websites very simply. And some of them with more advanced skill sets might want to do more interesting things with the sites as well. So now I'm going to get into the technical architecture and deployment infrastructure. I won't speak to every point on these slides, but if you have a question, just feel free to ask. So our sites are a shared multi site Drupal 7 code base with a single theme for common style. So all of our websites use the same theme with some variations, but they're all basically the same theme. But we do have a few custom themes for our homepage and a few special websites. They also have a shared top level navigation that can allow site visitors to navigate across the websites. In addition, we have an emergency message system. So if something happens at McGill where we need to push a message out across the websites, we can take over the websites and either push out only an announcement or we can put an announcement at the top of every page if need be. And we have a separate Git repo for our external developers as well. So our code overview. So there's a look at the number of contrib modules and custom modules we have. Matt, our senior developer often says that we are a very productive team. So we've pushed about 600 commits since Drupal 7 was implemented in 2012, which I understand is a good number. So all our contrib modules plus several contrib modules are posted on Drupal.org. And we have no core patches, which our developers are very happy about. So here's a look at what our web management system architecture looks like. I'm going to get more into some of the integrations that we have and how I feel there are benefit to our system. But basically, so the incoming requests go through our load balancer. We've got a pool of eight web servers. We've got the three Apache solar servers there. And those are for searching within each website. We have two Google search appliance servers for searching across all websites. And then we have the public and private user files, the shared files. So it's a file repository. And there's the MySQL master plus a slave for read-only requests and redundancy. So our search is also changing. We're in the process of upgrading it right now. And that's a big project. And when it comes to how we manage how our system works with these servers, our team doesn't actually manage all the servers. But we are colleagues of the people that do manage the servers. So that works really well for us. Because if something goes wrong or if there's something coming down the pipes that we need to hear about it, we're in very close contact with them. We can contact them just by walking over to the next part of the room, which is nice. So here are integrations. And to me, I feel these are the real benefit of having the RWMS or CMS so integrated across campus, so well integrated across all our departments. And the fact that it's available and managed on in-house. So there's the possibility to have integrations with a lot of our other systems. So these are systems that aren't in Drupal, but we integrate with these systems. And that helps our content to providers to be able to push the information that's already stored in some system across campus onto their website. So they don't have to recreate it. And I find that in every website that I've worked at, that's been a huge kind of a difficult thing to keep on top of. Staying on top of content updates is almost impossible. So the ability to be able to do this is really great. So the ones that I really like the best is the course calendar integration. So as you can remember probably from going to university, your course information, courses would change from year to year. When I first started at a university, I was a faculty secretary. And I remember what it was like to have to manually update course information every year on your websites. And it was difficult. And to be able to pull that into your website dynamically is really great. And we provide the opportunity to pull it in three different ways. People can pull it in a short version, a medium version, and a long version, depending on how much information they want to display on their site. There's the class schedule integration, user profiles. This is really great too, because it's biography information. So we have our banner oracle-based ERP. It stores biography information. So there's no need to recreate biography information for your website. You can manually import it onto your site. And the nice thing about this tool is if you use it, you can then turn on the page, the individual page, so that it can be edited by the person whose biographical information is on the site. So they can manage it themselves, which is nice. And we also have integration with our campus building data, which is helpful too. There's integration for Documentum, Destiny One, some custom internal APIs. And then we also have some social media and new sites, external RSS, Twitter blocks, Facebook and LinkedIn campaign trackers. Our course data is also exposed to external providers to allow people to pull that information into their website, external websites. And then there's a few other things that we have, special tools that we have on our site, on our sites. So these are our content types. So we've got restricted page or basic pages, restricted pages, profiles, channels, news and events, web forms, and template blocks for call to actions. The one that might be that it might be kind of different from what you're used to seeing is the channels, news and events. This is a channel system that we built in our for our departments to be able to not only post information about news and events locally, but to easily distribute it throughout the sites. So if you are someone in a small medical department or sub medical department and you wanna pull information that everybody is posting about medical research, you can pull in all of that news to your event feed. You don't have to go looking for it and then republish it on your website. So look at our methodology. We have an agile flow or workflow. We work in two week sprints. Our user acceptance testing is done by selected stakeholders but only for special projects. We have no release branches. Deployments are done during the sprint when they're ready. Database changes are deployed via features and update hooks. And our high impact changes are reviewed by a cross impact change advisory board. So that's when there's something that we're doing that's gonna affect a large swath of the university. We have to present that to a committee and they have to sign off on it. Great, so that was Matt's part of the presentation. Now we're gonna move to the part that I'm more familiar with, which is the support documentation and training. And I'm going to start by looking at what our support goals are at a base level. So what we wanna do, we do a lot of great work, producing the tool itself and creating a tool that works really well for our audience. But we found in the past that we didn't effectively communicate all of the updates and features that we were creating so that people could use them in a way that they were really making the most of their website. So we're really kind of focusing, I focus actually on that part of the equation. Matt calls it the human side of what we do. But I think it's all human. So we wanna make sure our users are using the CMS effectively that they can envision the tool's possibilities and that they're assessing audience needs. So a lot of our site managers, and there's 1700 of them who are managing websites at Miguel, they are people that have a ton of things on their plates. They're not dedicated web staff. They're admin support people. They're research students. They're people, sometimes they're assistant professors. They're people that have other things on their plate. And so when it comes to doing a web redesign project, they don't know often about the latest techniques. They don't know how to do user testing on their websites. So that's when we come in, we work with them on the project and we make sure that they best understand the needs of their audience so that they're really creating a site that works well. So here's some pictures of some of the user testing that we've done. We do card sorts. We do tree testing. We do usability testing. All those good things that I know people do these days. And there's quite a few people actually at Miguel, not quite a few, but they're starting to be more people that are getting hired within the departments to specifically do UX testing, which I'm really happy to see. So we're trying to work on compiling our information so that there's a stored wealth of that knowledge for everybody to share. So some of the support challenges that we deal with, I'm not gonna go through all of these. If you work for a university or a large institution environment, I'm sure you're familiar with these. They have to do with the fact that you're having difficulty often communicating with your user base. And a lot of them are turning over regularly too. So new people are always coming in. And that makes things a little bit more complicated. The one thing I wanted to mention was this last point, because it's something that we recognized recently was a problem. So most of the site managers that we're working with don't have the authority to make strategic decisions. So they're people that we can communicate with effectively and help them to understand the tools and to make sure that they know how they can apply them to their site. But often they're not in an authoritative position where they can say, we're gonna make this change on our website. It's a strategic communication change. So we're doing a much better job of not only working with our site managers, but also working with decision makers in the faculties, especially the larger faculties, to make sure they can empower their site managers to be able to make these changes. So I wanted to show some pictures from our community. This is from one of our presentations. We have presentations a couple of times a year to our wide community. And they're pretty well attended. We usually book a room for about 150 people and it usually sells out. It's kind of fun. We do it like a little bit like a release party kind of thing, but obviously a lot more low key. So here's some of the groups that we have are some of the roles that we have in our CMS. You're probably familiar with the first three, the channels, news, and events. I already mentioned that. So there's some people in the system that only have access to create news and events. They don't manage websites. They just produce that content. And then we have site sponsors, site reviewer, and beta tester. Sponsors are kind of people in authoritative positions that can make decisions about access, site reviewers. That's obvious. Beta testers, this is our group of super users and we're finding that we're really doing a lot of great work with them. They're really keen to connect with us and they're people that give us a lot of great feedback when we initially roll out our features. This is good. So, we did a kind of look back when I looked at the website. So I wanted to kind of look back at the way we used to communicate. So this is an example of how we used to tell our users what we were working on. It's from our blog. We called it the beta blog. This down here that you can see is a snapshot of our sprint board. So what we would do every few weeks when we worked on a new sprint is we would copy the sprint board and we would post it on the site. And it was in language that works for us because we're an internal development team. And if people wanted to know what we were working on, we would point them to the site. And as you can imagine, they had difficulty connecting what they had asked for with what they were seeing on the sprint board. But that's one of the ways. Some people actually really liked it, but not everybody. It wasn't effective for communicating with everybody. We also would have occasional meetings with a key group of site managers, not a very big one. And we'd send out emails to communicate updates to them. So that was the way things used to be. And this is kind of, well, it's a look at where it is now, but it's always evolving, of course. So this is our new-ish, new-ish digest. We send it out once a week. It features articles from our blog. They're articles that we posted on our website. They're more kind of inspiration posts, kind of best practices, how to do things. We show examples of other people's WMS site. So we give best case examples. For example, when we roll out a new feature, we might show some of the work that our beta testers have done to help kind of get to people's ideas going in their heads. So I have an example of how we used this process to effectively communicate one of our changes. So we fairly recently decided to update our Twitter poll block so that it was more in line with Twitter standards. So Twitter introduced their standards where they wanted their content that was being dynamically pulled to people's sites to look more like it does in Twitter, because that's the expectation of users. So we implemented this change. We didn't think it was gonna be a huge difference. We rolled it out and there was difficulty. People didn't understand the benefits of the tool. They didn't understand why we did it. They didn't like the fact that it had changed their navigation or their site layouts, even though it had done it in a minimal way. So we pulled the update back. We don't always release things without making announcements, by the way, but we felt like this was an announcement that was fairly minimal, but we needed to take some extra steps. So we wrote an article about why Twitter had made these changes, the benefits of it, how it's gonna affect people's layouts and how you might need to adjust your sites to accommodate the new change. And then we sent out a couple of announcements to advertise that post, and then we rolled it out again a month later and it went well. So sometimes you have to be very in-depth, I think with the amount of communications you have with people. So this is an example of some of the more in-depth site review consultation support that we provide. This site actually has the same content on the left as you see on the right. So when we worked with this client to begin with, we identified that they really had some great content, but they hadn't updated the layout in a long time and they weren't utilizing the new tools that we had introduced. So we worked with them to just relay out their pages and we did it in a way that it's more scannable and easy to read, but yeah, it's exactly the same content on both pages. This site manager also had a limited skill set, so we needed to introduce something that was very easy for her to update on an ongoing basis. The other example I'm showing, it's also the same content on the left as on the right. This is our engineering department. This was a very early version of it. If you go to the engineering site now, you'll see that there's more of a kind of a sleek design look to it. The site manager who's taken over the site has a design background and he's done some really interesting things with it that's kind of taken it a step further. And I just wanted to include it as an example of how the tool can work for people that have different skill sets because I think that his use case is really exemplary. So one of the most important resources I think that we've got is our knowledge base. And our knowledge base articles are part of the larger IT services and our knowledge base at McGill. But I found out that we actually produce more knowledge base articles than anybody on campus and have more updates than anyone on campus. So every two weeks when we have an iteration, we have a whole slew of updates that we send and we have about a hundred articles in our database or on our knowledge base and it's the IT communications team that updates them for us. So our training is really important too. These are our training courses. So we've got our site editing, site management, our drop-in lab for site managers and editors. There's two of each of these every month. And over the past year, we've trained 600 people. All together since we've migrated onto Drupal, we've trained 4,000 people to use our Drupal WMS. But right now there's 1,700 active site managers. So yeah, lots of people. To me is the really, I think the really human aspect of what we do and that's how we connect with our community and how we create community in our user base. So these are pictures of our events that we have. We hold them one or two times a year. Down here, I'll share these links or these slides. You can click on these if you wanna view the presentations. They're really well attended and they're aimed at building awareness and fostering knowledge in our community. But I think the great thing that happens at these is we also showcase a lot of the work that's being done by our site managers and it allows people to connect with each other and I feel like we're making some progress with developing a sense of belonging and connectedness within our community. I see our site managers are connecting with each other outside of, without our influence and I think that's really great. Oh, that's the last slide. You can contact me at those links on the right or you can view the slides here on the left if you're interested. I'll take any questions if anybody's got any. I don't know if anyone's curious. Yes, in the back. This is a bit more practical question but at least for our organization our Google search appliance license expired and Google was not renewing. Yes. The appliance or what do you guys are gonna migrate to? Yes, but it is in progress right now and I'm not part of that team. So I do know that that project is in progress but it hasn't been, it hasn't been, we haven't been brought into the process yet. So, but it is happening. I can find out too if you're interested in knowing what it is. Anybody else? Yes? You mentioned that you have some data as part of an app system like Oracle database application. How do you, do you have a middle tier like create a web service to pull that data or did you save another set of data in your Google site or you just dynamic? It's dynamically pulled. So you didn't say that the second copy of data in Drupal? No, well, no, it's not, it's dynamic. So there's, it's not stored in Drupal, it's pulled into Drupal. Yes? How are you letting the different departments actually customize their teams? Like I saw you having them do blocks and stuff but obviously their blocks are going to different places. How are you giving them or how are you managing that? This is the conversation that we're having because we feel like if we can share those blocks across our user base so that different people can use them on different sites, that would be really helpful. So right now they can't. They each create separate blocks for their websites. In terms of customizing their themes, that's kind of the height of what they have available to them unless they work with an external provider to introduce more advanced customization into their template. So it's a pretty set base of tools that people have to work with but they can, there is some room for them to kind of put a little bit of an extra touch of their own personality within those blocks but we're talking about allowing them to share the blocks across sites because we're finding that people are repurposing a lot of content or duplicating a lot of content that doesn't need to be duplicated or that a site in particular would be best managing that content. For example, admissions information could belong to our admissions department. It could be shared as a block across all of our websites. So those kinds of things. Anyone else, yes? Is the course registration built in to the WMS? The course registration, no, it's not. That's a separate system. There's no integration with the course registration system. It's a very complex system. Yes? Yeah, you're obviously playing heavily in Drupal 7. Yes. So any tiers expected to go into Drupal 8? Yes, we actually created some Drupal 8 tickets to start the investigation process. So that is our radar and we are going to take those steps. But as I mentioned, well, I guess not fairly recently, but I feel like we're just settling down from the Drupal 7 migration. It was a bit of an experience for everybody and so we're waiting to move on to Drupal 8. So it looks like it's all one giant multi-site, but you also talked about having for individual sites having external vendors coming in and passments to individual sites. How do you set that up in a way where the vendor doesn't come in, create something and then you are left with the burden of maintaining or making your future changes to the website, work with whatever customization that you have done? One of the things I think that discourages but maybe makes external people think twice about going with external providers is that they won't have ongoing support if they go with a very customized site. So we do have some sites in the system. Those teams worked with the IT services team to create the website, but we won't manage those customizations on an ongoing basis. So they will always have to find an external company to help them manage that content on an ongoing basis. And it's not just the site itself but the integrations with the other systems and it's kind of a big kettle of fish for people to take on. So there has to be a very strong use case for it really, for it to happen at all. But I think we're starting the process of allowing people to work more independently with external providers outside of our WMS so they won't be able to use our system then. They'll have more of a choice of not being on the system and not having access to those integrations. Does that answer your question? Great. Anybody else? Yes? That question comes up over and over again, especially when we do our projects at a higher level. People often talk about what content should be owned by which department and which content should appear at the top level and which content should appear further down. And every department has that conversation. And I think when we're in the process of doing a big, there's a big shift. It's not just on the homepage, but it's throughout our entire web space. It's gonna affect the way our web teams are structured at McGill. And it's going to involve having that discussion and talking about how are we going to better manage the content so that we don't have those issues where people are unnecessarily duplicating content. So yeah, that's the step we're taking. Anyone else? I think there was another person over there that... Updating with Google courses. How much of what is it? Is it hierarchy or is it signature? We do the updates as part of our sprints. So that all of the module updates, the core updates that's handled by our team. So unless they've gone with an external provider, then the external provider will be responsible for upgrading whatever special tools that they've created and ensuring that their tool is in the right place. So that's what we're doing. And ensuring that their tool, the site that they've created works within our WMS system. So they have to test it. I can't authoritatively answer that question. So I'm not gonna, I'll leave that. I can get back to you if you wanna come see me after. And I'll give you our contact information. But I feel my sense is that it's a single code base because I know even our external sites, we have to, when a change is made to the sites that are created by external providers, we have to help push those code changes. So it's all done by us. Anybody else, yes? Are there any special security issues on your best updates, are there? What's that? There are. So as you can imagine with our web forms, especially people have a tendency to ask for personal information, which is against the law. Sometimes they'll ask, especially because we're talking about registration for events or registration for classes. Sometimes people will ask for even credit card information, social insurance number information. So we've developed better tools for scanning. We don't ask every site manager to pass their web form by us before they publish it. But what we are doing now is scanning for problematic words in web pages like social insurance number or credit card. And we're contacting those site managers after. There's also a special team in IT services at McGill called Info Security. And it's really their job. We often work with them to talk about what's wrong and what's right and for them to give us guidance in terms of where we should draw the line. Yes? Confidential information? No, there should not be confidential information. Yes, these are the public websites at McGill. That's right. There are systems at McGill that are accessible online that are protected. They're authenticated systems. But these ones are all, these are all the public facing pages. Yes? So you mentioned you actually may have thousands of sites on another day, 150. So would it be so? When I look at the infrastructure diagram, it looks like the servers are all being managed on premise. Do you have issues scaling up, being getting more and more sites created? Are you picking up the cloud by any chance? Well, that doesn't, it doesn't affect us really because the other sites that I was referring to are outside of our system. So you wouldn't add the sites are, some of them will be stored. Some of them are stored in the cloud. Some of them are external. Some of them, but they're managed on servers that are outside of our WMS. So they're not managed by our team. Okay, so for those sites, your console called Common Cold Base can actually be applied there. Exactly, that's right. Yeah, they're separate. Anybody else? Yes? Do you have a dedicated QA person in your team to run the QA? No, we all do QA testing. So when the juror tickets go into QA, whoever has time to pick it up is the person that picks it up. So, and it's something we all share with. Mostly it's handled by the support and communications people, but the developers will also participate in QA testing. Yes? Any content editors do have any, like, you know, content editors tend to like to write content like a word and paste it into a book all and like do you have issues around that or do you have strategies for dealing with that? Yes, well we have a paste from Word option in our WYSIWYG editor, but we upgraded it recently and we noticed that it doesn't work well. So we're in the process of fixing that because a lot of people do generate content in Word at Miguel. And I, we don't really push them not to. I suppose we could, but the paste from Word option seems to work pretty well. Like a tip that we might tell them if it's problematic on their site is to put it into like some kind of text editing software first and then copy and paste it from there, but, but yes, we're kind of relying on the paste from Word. Yes, the better paste from Word. Anyone else? Great. Well, thanks everyone for coming out to the presentation.