 So if you visited our presentation page, you'll have seen Matt's picture, Matt Quirk's and I are presenting, I'm not Matt, I'm Joyce Peralta. We work on the web team at McGill University. It's a Drupal development team and we're located right on campus. Our presentation, How and Why Drupal Powers 900 Websites at McGill University is something that we've done at a few Drupal camps in Drupal North over the past year. So we've refined it. I think we're going to add a little bit of extra content for anyone that's seen this presentation in the past. But I guess we'll get started. If you want to download a copy of our slides, here is the link. We'll show this again at the end of the presentation. But if you're interested in seeing it now, you can follow along. And here's a little bit about us. My name is Joyce Peralta. I'm a web analyst on our development team at McGill. I've been working at universities for over 10 years. This is the fourth university that I've worked at. And I flip-flop back and forth between communications and IT. So I've kind of seen things from both sides. The other universities I've worked at were the University of Victoria, Western University and Keynes University College. And I'm co-presenting today with Matt. Yeah. I've been using Drupal since Pluto was a planet, as I usually put it. And I've been at McGill for a little under two years. So our core team is made up of right now nine people. We've recently lost a person. And we're going to talk at the end. We're actually looking for a developer. So just a heads up. We'll have the information later about how you can apply for our position if you're interested. But right now we have a manager. We actually have four back-ended, two front-end developers. And we're down a support staff person at the moment. But we're going to be adding a development position instead. We also have a really great extended community of people that contribute to our web process at McGill. These are people in IT communications. So we work very closely with them. We develop our strategy, our branding and the look and feel policies that guide how we develop our template. And then we have also on campus, which is really great for us, trainers and writers, technical writers, who we work very closely with to keep our documentation up to date and to make sure that our content managers are being trained in the way they need to be trained to best use our tool. So here's the link. I didn't realize it was going to be here. You'll get a copy of these slides afterwards. So if you're interested in applying for a position or if you know somebody that might be interested in working and developing Drupal in higher ed, you can encourage them to apply. So without further ado, I'm going to turn this over to Matt. I'll do the second half of our presentation. But Matt, we'll start with the technical specs. So Joyce, as we've been calling it, we'll talk with the human side, but I'll start with the technical side. So we have, just in terms of scope, we currently have laws of March or April. We write 900 sites. So that's one multi-site instance, 900 databases on a pool of web servers. So the homepage is one site. Each faculty and department has their own sites. There's various little research labs. So the sites are different sizes, but they all have the same tool. The homepage has a special theme and one or two other sites do, but they basically all have the same themes. It's the same look and feel and user experience. We're running somewhere between 8 and 10 million pages a month, and our Alexa rank is a little over 100 in Canada. So it's a pretty big site. It's popular on campus because different universities have different policies about this, but departments at McGill don't pay anything if they use our system. They're allowed to go external, but then they pay, and they manage working with an agency or whatever. So they prefer our system. The goal of our system, since we're working for so many people, is if you want something special, we say no. If everybody wants that thing, then we'll say yes. The rule of thumb is we figure about 80% of the users have to want it, and then we might build it. This is the rule that WordPress uses, for example. That's a good rule of thumb. We have built custom things for people in the past. That was a bad idea. We regret it, and now we do our best to say no. That doesn't scale. In short, it's kind of like a Squarespace specific to McGill. Quick trip down memory lane. Who was making websites back in the 90s here? Yeah, a few hands. We built things by hand at that time. CSS hadn't been invented yet, so there was a lot of really ugly HTML. There's just not a lot of content here. The web was kind of an afterthought. It wasn't the primary communication tool for universities or anybody at the time. So a lot of websites look like this then. This is just flat HTML being pushed manually to a couple of servers. Around 2000, McGill started to use CMS. There weren't a lot of good CMSs. There was very little on the market open source or otherwise at the time. The fancy thing to use was something like Dreamweaver, but that was just published to flat HTML. Like many people, McGill built a custom CMS. In our case, it was PHP and Postgres. That ran from 2001 to about 2010. Again, a lot of people had to do this at the time. You can see there's a CMS. For example, there's a search function. You're not going to get that when you're building flat HTML. There's some syndicated events. In general, there's a lot more content on the site. There's a lot more to manage beyond what, sorry, that door is really loud. If you come in, can you just let the door shut quietly, please? Thank you. Now I have to save it to every single person, I guess. There's just a lot more going on on the site. Writing our own CMS, that didn't scale either. By 2010 is about when that ended. The team who was there at the time realized they needed to leverage some existing CMS to make it a more complex tool. By 2010, the site is looking a bit more modern. It's starting to resemble more what you'd see in our website today. But then everything moved to Drupal 6. Now, instead of everyone who's coming to you and saying, I'm really important and I need to be on the front page, there's actually some strategy and some communication. More thought is going into this and only a few things are there. The things that we think might be the most interesting to users. But there's still syndication now. By now there's a link to Facebook, etc. This is Drupal 6 and it was actually earlier this year that we finally rebuilt that look and feel and the website became responsive. Yes, responsive has been a thing for more than a few months, but we're there now. By now this is all in Drupal 7. We have one site's all directory with a huge pile of modules and basically one theme. There's elements like a shared primary navigation menu that all of the sites have. External users don't realize that there's separate sites even though they are. We implement that by having a primary menu on one Drupal site. When you move menu items around there's a custom hook that fires and dumps flat HTML into a shared directory and then all the other sites load that in the theme. It's a good editing experience. We also have what we call the emergency message system. A requirement for us is that if there's some horrible catastrophe going on in campus we need to be able to put a great big yellow box on top of every website and that's to be there right away no matter what caching systems are in place. That is done by dumping files into a special directory which the templates in the theme look for and use to replace parts of the content. We have a few external developers who push their own Git repository. Those go into a directory for a specific site, so modules that override the shared modules and sites all. This wasn't scalable for a lot of reasons. We're getting away from that but it has allowed a few people to build extra functionality special themes while still leveraging the integration of other campus systems that you get when you use our platform. Environments. Our local testing. By now we're all using Docker Compose pretty much. There is a shared test server that a few folks like Joyce are using but we're moving away from that and moving towards OpenShift which is the Red Hat flavor of Kubernetes. QA we have some shared servers because we can also use these to test other things about the servers before those go to production like a change to the configuration of MySQL for example. We occasionally have stakeholders or clients do QA on something for release but for the most part we just do it ourselves. And then we have three what we consider production environments. So there's the live site itself. There's also a separate set of sites which are rebuilt nightly which are just for trainers so they get like a blank site built every night that they can go and play around with in their labs and they can make whatever changes they want because it'll be wiped out tomorrow. And then we have staging which is content staging not staging of our software. So if somebody wants to re-organize the whole menus and write a lot of new content and then push all that at once they can use our staging environment. Code overview. We're at about 150 contrib modules and about 130 custom modules although since this is Drupal 7 most of those are just features holding configuration and code like definitions of a content type or a view for example. Drupal 8 of course all that will just be in YAML and we won't need as much of it. The contrib modules we try hard to just use things that are stable releases that there's security support. Of course it's not always possible to do that. We have currently the Jenkins tasks that we plan to replace with a GitLab runner that monitors for the security alerts when there are problems with core or contrib module so it automatically creates in our case a Jira ticket. Although a bunch of us developers are also subscribed to the mailing list so that we know something urgent is going to be released. The most complex parts of this code are a system we call channels which is extremely popular with our users and it's a main thing that keeps people within our platform. It's a news and event syndication system internal to our web publishing platform so for example the music faculty can publish that there's an upcoming event and they'll sign various tags and categories to it from a shared set of categories and then any other site in this pool of 900 sites can display a block showing upcoming events that match a certain tag or that come from a certain source. So for example the faculty of law or the business management folks they have many websites and that way they can have things displayed in all of them and then other people on campus can show just the events that are from the business from the faculty of law that are about medicine for example the medicine folks might want that etc. So this is very popular with our users as I said it keeps people in our platform and has encouraged people who have gone inside to come back in. We also have the university's course calendars the full description of every class and every degree program you can take at McGill. This is in a central ERP currently run by Banner. At a lot of universities there's a whole lot of cutting and pasting going on all the time whenever a course or program description gets updated. At McGill you don't need to do that. You put a little code and an input filter will show a link to that description on a central website. So the external developer and the firm Susan works for actually built that system for us so it brings in some information from Banner so that all of the course descriptions are updated nightly on all these thousand webpages which was a lot of work for those folks. Question? Yeah, just a question with the news and events which content lives within the same databases? So the authoritative source is the author. It's a site that created it. If it was the law faculty's event then it'll be on their site. They can update it or delete it at any time but it will be pushed to a central hub and then other sites can subscribe to things matching from the law faculty from that hub but if the original author updates it then that update will get pushed up to the hub and then brought back down to all the people who are subscribed to that. Can I answer your question? Is that also true of deletes? Yes, without deletes. That wouldn't make sense. But it's only in the XML site map on the source site because you don't want Google to have ten copies of a piece of content. Hosting. So we host internally at McGill. I know that's becoming less common. Everyone's moving to the cloud but we've got our own data center on campus and a group of sysadmins that we actually get to sit and talk to so we get to go and speak with them and if there's something that we need to change unlike some other places where it worked. So everything comes into a central load balancer from there. It goes to a series of eight web servers so I'm going to have a diagram in a moment. We have a MySQL master and slave. In Drupal, in your settings file, you can specify one or more slave servers and then encode, say, the specific requests. For example, in views as a checkbox, to say the request should go right to the slave if it's an expensive request. So we take advantage of that for expensive queries. Since we have multiple web nodes, of course, user uploaded files like images have to be available and all of those that's as a server area network, basically an NFS amount on each of the web nodes so that everyone sees the same directory. We're currently using Google custom search. We were using a Google search appliance. That product is Simpson shutdown. We're moving to Lucidworks Fusion. We thought it would be launched by now. Hopefully it will be up soon. So that's researching across all of our websites and various other media properties. We also use Apache Solar. That's for searching within the content of just one site. So this is a little confusing for users. There's two search forms. So we're planning to make one search form and use facets somehow so that people can specify if they want to search just on the law site or on everything. So we're thinking through that. Authentication is via campus-wide LDAP, basically, so we don't have to manage. It's the same password you used to go check your email, for example. So if someone got fired yesterday, we don't need to go cancel that account. That's happening centrally. Or was fired yesterday. Sorry, it should be more positive. Yeah, really quickly, this is what it looks like. So users go through a firewall, a web application firewall, which we're just starting to set up. It's a load balancer. The little part up there with the varnish is currently in development. That's not live yet. The load balancer sends it out to one of our currently eight web nodes. And then the web nodes themselves talk to the active directory LDAP server, to the Houston and Zookeeper for cross-lites searching, to the file server, our database servers. And then these little things down at the bottom are where the, for example, the course calendar information that I mentioned is pulled from a central Oracle website. Sorry, web database. And we copy the relevant parts of that into MySQL nightly so that we can update our own systems. So to wrap up provisioning, all of the servers are defined with Ansible Repos, they're virtual machines. So the parts of it that you need to be root to change, we basically make a merge request in GitLab and assist them and reduce it and then we deploy it if it makes sense to them. The stuff in user space, we can just, it's a separate Ansible repo and we change that ourselves. And then we have a huge pile of bash scripts that go around and push a code update, run update DB, for example. We push code as soon as we close the ticket, and it's not a Friday, then we'll push the update. So usually multiple times a week. And then if necessary, we'll run the database update hooks. And we have other tasks to go and create a new site, to rename a site or to leave a site, et cetera, with a web front end for that to make it as simple as possible for support folks. Yeah, I already mentioned integrations with the course calendar. Some user information, like there's each staff directory that's integrated with our system. There's some APIs, for example. The continuing studies folks have an online learning system. So descriptions of those courses get pulled in from that system's API. There's a data central API with like building information because McGill has a lot of buildings and a lot of places, including one in, I think, Bahamas, Bermuda, can't remember. Should actually try to book that meeting room someday. And then we push data to RSS, Twitter, Facebook, campaign trackers, et cetera. Yeah, I think I've covered this. Yeah, we do agile with two sprints. We don't have, the product donor is our boss. Basically, we don't do user acceptance testing for the vast majority of our work because our clients tell us they don't have time. But we do it for large, special projects. So we don't have to release branches. It's sort of, it's not real continuous deployment because we're just pushing things manually, but we're doing it on a regular basis. So since they're all small updates, we figure we can do it. We don't need to schedule downtime or anything for that. And, yeah, the next challenge is for us where we want to, for testing, move to some Kubernetes system where we can spin up test sites using a specific Git branch and a database from one of those sites for user testing to automate that. It's the easier it is to test the more often you're going to test. Like most people, we need more automated tests. We're working on moving external developers off of our servers and onto Kubernetes to make everyone's life easier, for example, so we don't have to do line-by-line code review before your code lives on the server we're responsible for. And like a lot of large institutions, things move a little slowly. Most of my career was at shops with like 10, 15 people. A university is different from that. So there's legacy systems, like that thing I mentioned, the old Postgres system that was built in 1999. It's still running one or two applications on a server in the corner that might melt down at any time, but you have to keep it alive because those people haven't moved their content yet. I'm guessing most large, not just universities, but large institutions have similar stories to tell. With that, if you have time, I'll turn it over to Joyce. Great. Thanks, Matt. So as Matt said, I provide the human side of this presentation. It is the side of the presentation that talks about how we support our community. So we have 900 websites at McGill. We have 1,700 people that create websites. In the past year alone, 600 people have been trained because there's a continuous kind of turnover of people coming into departments and learning to create some of these sites. So one of the things that I really like about working at McGill, as I mentioned, I worked at four other universities before coming here, usually the development staff is a little bit removed from the people that support, the people that create websites in the community. Because the development team and the documentation, training and support staff, we're all part of one team. There's a lot of really close interaction and we can provide a super tailored experience to the people that are building websites. This is also a little bit more of a technical side of how we build sites at McGill. I'm going to have a presentation immediately after this that looks at how we build websites more from an information architecture and UX perspective. So if content is more your thing, that might be more in your wheelhouse. But I'm going to go through some of the same things that Matt talked about from a support perspective. So basically what we're really trying to do with the people that create websites at McGill, this big group of 1700 people, is to make sure that all of these enhancements and tools that we put in place, that they understand how to use them. And we have this agile process where we're constantly releasing new features every two weeks. We continually have new features and new tools to share with our community and to make sure they know how to use. One of the other new things that we've recently started to do, well I guess it's not really new, but there's more of a focus now, is supporting our site managers with doing user experience research and user experience design. So that was a piece that was missing before. It's something that we realize in the departments, a lot of the people that are building websites are people that are also faculty secretaries or they're research students or they're just basically people that have other things on their desks. They're not dedicated web people and they don't know current practices for creating websites. So when they're working on a redesign project or something that requires a little bit more, a project that requires a little bit more of an expertise, they will work with us and we will provide that expertise and we'll work with them to train them to do those kinds of exercises. So just like Matt with his technical challenges, we have support challenges. I know there's a few people here that work at universities, so you are probably familiar with some of these. I'm not going to go through them, but I'm going to mention specifically the last one. So this was something that we also recently realized was a problem. We were doing a better job of communicating with our site managers and the technical people that create websites in the different departments, but a lot of the times those people don't have the authority to be able to make strategic communication changes on their site so they can't implement the features that we're updating because it encompasses some kind of communications or a strategic shift that they're just not capable of enacting. So what we are doing a better job of now is we're working at a director and dean level to create committees and networks within departments so that those people that are involved in strategic changes also understand our features and tools and so that they can empower our site managers to then make those changes because what was happening before is those updates were just kind of falling flat. They weren't getting implemented and we identified that was a big reason why. Some pictures from some of our community events and some stats that I've mentioned some of these already. I'm going to go through these events later on but these to me are the epitome of what makes it so great that we have our development team on campus. So we present to our community a few times a year. These are kind of exciting like release events where we talk about the new features that have been put out in the WMS. They're very well attended by our community. They usually sell out a big room which is kind of cool. And it's also an opportunity after we did the first few we realized it was an opportunity to present to our community but also to create connections within the community. And I've talked to a few site managers from different websites here and they have talked about how these events have connected them with other people on campus who are also building sites and how they've shared ideas and how they've inspired each other in their work. So that's something I think that's really gratifying for us to see that happening that it's not just us communicating I will say things are great now but perhaps at one time they were not. This is an example of the way things used to be. You can't probably see it very well but the way we used to communicate our changes to our community was we would take our iteration board and we would paste it into a blog and we would share that iteration board with our community or encourage them to go there to look at all the things that we were creating or working on for them. The problem was and I expect other people have experienced this as well they didn't understand our iteration board because it uses language that they're not familiar with they can't connect the requests that they've made with these items that are listed in this table. So to them it looked like we're not working on the request we're not doing what they're asking for and really what was happening was we weren't properly interpreting for them we weren't presenting this information the way they needed to see it. So the way that's improved now we now do a better job of putting our updates in a newsletter that gets sent out I've actually worked on a few newsletters in different organizations and the open rate on our digest is amazing. I haven't seen this it's almost 50% open rate which for a newsletter, an e-newsletter you don't often see and the click-through rate is really good too. So we put our features and little digestible little bytes that entice people to learn more about them and then we back that up with an article area of our website where we talk about best practices and we often use this area to also highlight not just our work but the work that's being done by site managers exemplary work. So I think whenever we do that we tell our site manager who we're highlighting that we're going to be featuring them in the blog and that kind of really makes people feel happy which is good. In addition to that we have a better site review service this is like a redesign service that we do from the perspective of the team that we work on it's based on the technical side so we don't really work from a content perspective I'm actually switching over to the communications department which is more content-focused they're the people that make those content changes but really what we were doing was just making sure that people were taking the tool and using it to the best of the needs of their websites So for example this is a before and after but it actually has the same content on the page so before we started working with this team they weren't aware of a lot of these new about a lot of these new layout tools that we had recently introduced so they created a kind of website that you used to see a lot is just a flat page with just a block of content so we showed them how they could lay up that content to make it more interesting for their site managers to navigate and so that it would be easier for them to identify what is on that page so it's just a very small update I also wanted to mention with these changes because it's a CMS that it's pretty easy we've created an admin, a backend really easy for site managers to use there are a lot of site managers that we work with who have very simple skills with developing and creating websites or laying out websites and they're able to work with these tools very easily but some other site managers who have more of an advanced skill set can do some more interesting things with the designs this is another kind of benefit of having the development team on campus so this is just a screenshot it's not very pretty it's our knowledge base if you're from Miguel, I see there's a few Miguel people here you're familiar with this this is about to be updated but one of the things that we do really well is we're very good at updating the documentation for our community so every time we have an iteration we update our documentation and in IT, we have a single IT knowledge base our department has more knowledge based articles than other department within IT so more than network more than the people that support the email it's the WMS articles that are the most active we have some writers that help us keep this documentation up to date as well, which is really good so in other places where I've worked it's been a little bit different the tool because it's been developed off site the documentation was also developed by a team that was not located on campus so producing documentation that really wasn't tailored to our team and surprisingly wasn't updated very often that doesn't happen with all people that are providing a service but it can at times and it's one of the nice things about this connection that we have so our training courses we offer three courses that are put on twice a month our site editing our site management and we have a drop-in lab for site managers and editors it's surprising actually how many times how many people we have that attend these courses as I said there's 600 people that have been trained in the past year out of an active pool of 1700 so that kind of gives you how much turnover there is in a university environment we have trainers that are not actually specifically on our team they're connected to our team but we work with them to make sure they understand the different features that we are implementing and we make sure that they know how to train other people how to use them one of the nice things though especially with the 302 drop-in lab we have the opportunity the development staff to go down and to participate in those workshops and what it gives us a chance to see is how people on an ongoing basis we can always do user experience testing what are the issues people are having and what do they need help with and what aren't we doing well in the way we're presenting our admin pages I've touched on this a little bit before if you're interested in seeing some of our presentations they're actually videotaped these are the presentations we do to our community these slides are available as I mentioned I showed you the link so you can go on and watch them so here's some examples of some of the ones that we've done in the past and I just wanted to reinforce that to me this is really the biggest benefit not only are we encouraging relationships within our community but it provides an opportunity for our community to see our developers which they don't always get to do I think the first time we introduced our developers at one of these events even though a lot of our development staff had been at the university for years and years people just hadn't seen them before so it was a really nice experience alright well I think we're going to wrap it up here as I mentioned I have another presentation that's kind of similar to this presentation but from a user experience perspective I'm going to turn it back over to Matt so we can wrap it up we'll just take questions now there's a link right there to these slides it's also on the conference website if you want and I'm giving a talk I'm giving a presentation tomorrow if you've never given one before show up but any questions about this do you have a strategy to move the 900 sites to Drupal 8? we are working on a strategy we will be moving to Drupal 8 we're very glad that moving from Drupal 8 to 9 is going to be a lot less painful as I mentioned I've been doing Drupal for a long time I've seen a lot of major version upgrades and they're always painful right now the next step will be I mentioned we have some external developers who are working on new projects who will be just hosting directly in an open-shift environment of their own creation some of them are in this room then the next step will be to create a basic environment like a copy of a basic environment on which external developers who need us to provide that platform for them because they don't have the resources so they can build on top of it so things like the ship some of the integration things that I've mentioned will be there but otherwise it'll look like a bare site to build on and then we'll go from there to making somehow moving everything to Drupal 8 we'll try to get rid of as much of the special things we built for just your site or just your site that probably shouldn't have been there and make all the sites as similar as possible but we think it's going to take a while that's the we're expecting this to take a long time we have some other ever-grading to do and some like we just upgraded the database servers for the first time in like better I won't even say this since when it was way too long there's a lot of things in place where we can work on that but it's definitely in the plans I was going to say if you were at the higher end summit yesterday Matt Cheney from a Pantheon was talking about migrating into Drupal 8 and he was talking about how you can just take a site and just migrate it straight into Drupal 8 but that would be a missed opportunity and perhaps not the correct way to do it that it's an opportunity to really introduce kind of a bit of a shift in not just the way you manage your site but also your content strategy so there's other pieces in addition to what we're doing with the actual technical migration there's a bigger picture of this web evolution project that we have in the works that we'll see kind of a change we're trying to plan a change in terms of how websites are managed in general across the university so I'm really excited about that but it will be a few years but that will be rolling out since we've got to rebuild everything it's not a good opportunity to do some housekeeping and clean some stuff up and rethink strategies we built the Drupal 7 version a while ago so a lot of best practices have evolved since then other questions there was a question you mentioned that we use the Google search for Google search and the polar search post do we have a page where Google search you want to see a page alright I'm doing a we're also considering Google search platform okay, yeah this was a big topic last year because the Google search of plans was being decommissioned and a lot of the universities that we were talking to and I don't know what the conferences he went to they were really interested in talking about search and we were expecting we tried a Google search before but I think we didn't pay it at the time so it had something to do with it oh there's a educational institutions get to use it for free so you can go open a support ticket with them that's why you see the little Google branding at the bottom but that's why this isn't full of ads even though we're not yeah you'll find this in their support documentation but this was supposed to be here for just a couple months because the powers that we wanted us to use our own search platforms that we could like you've got no control over this right we can control what's in a sitemap but we can't control how Google creates the snippets we can't control how Google is ranking things there's lots of keywords that we'd like to be up at the top just like anything that's a course description our clients want us to have that right at the top because that's going to drive user engagement and you've got no control here so this was the stopgap solution that's been up a little longer than we had been hoping for so the most common solution we found was Lucidworks Fusion and that's what we're hopefully launching soon so this is just so if you go to the search thing the main website these blocks on the right we're building ourselves otherwise it's just Google and if you go to it's hard to do this on your own of screen mirroring here for example you search for search for something here so now you'll see two tabs so one is slash law so here you're seeing these results are from solder so you see like facets with search API and here with us to control what the like how the indexing and ranking and snippets et cetera work and then there's a second little tab here which in our user testing which we thought was obvious but our user testing tells us users don't understand so if you click the second tab now you're searching across all the legal properties so now you're back to the Google search yeah so but yeah people don't see the two tabs so some sort of facet whereby default you see results just from the current site so there's a big obvious way to see results from everywhere is what our users expect and that's what we're in the process of building can I answer your question yeah but yeah and yeah definitely go open the ticket to get those Google ads off of your site build free for any I'm not sure if it's all non-profits but definitely all educational institutions other questions I have a question about so obviously with all your training you've got something you've got a pretty enthusiastic group of sites managers and editors so that's great how do you combat exhaustion some of that audience sort of thing like you're talking about moving to Drupal 7 and now we're starting out as Drupal 8 which is a great opportunity but I find that I'm from the University of Toronto as well and we find a lot of people who are administrative staff are like the look of the website often is a necessary evil sort of thing is it the result of the training that they're becoming excited about doing stuff with it or is there something else going on I think the whole communication strategy so just the training that we have we're trying to encourage this idea of community the fact that we try to communicate with them via newsletters on a regular basis so that they're in touch with what's happening and I think there's other things as well from just a burnout perspective Matt talked a little bit about these integrations a long time ago when I started I started at universities in 2002 and I was a faculty secretary and I know what it was like to try and keep a website up to date when you're also doing all these other admin it's very very difficult to do so these integrations that we have that allow people to pull content automatically into the site that's a huge bonus they don't really have to worry that much the content is going to be coming out of date because it's being pulled from repositories that are kept up to date like our e-calendar our online calendar or the banner system so that kind of takes a lot of work really pasting that Matt talked about off their desk another thing I think that really helps and it's something that we're trying to do better is to provide a support for these big web projects that they're working on because for a site manager that has never done a redesign before it's really daunting for them to think that they're going to have to restructure their whole site so we are looking at ways to provide additional support for that and thirdly we're also looking at finding ways to encourage departments from a high up level to invest more in their web staff because often it's not enough for people to be able to do a job off the side of their desk they really need dedicated web support staff in their departments yeah I'll just add that if you don't like the campus emails whatever your systems are providing you with I mean you're out of luck if you don't like your website and you've got a bit of money you get to go anywhere you want so that means that we have the onuses on us to make sure that our users are happy or else our departments are going to be made a lot smaller we're competing with WordPress.com and so a lot of that means that before I arrived as our boss has explained it to me I do I guess a lot of listening exercises you might say and make sure that we're responsive to what our users want and just like things like moving from that creating that newsletter that's actually readable description of what's coming what we've added recently making sure to prioritize features that our users like so they see movement and new things getting published new features being added that makes them stay in our tool we're going to have to wrap it up there but hopefully if you have any further questions you can approach Matt and I at the conference my next presentation is in 3,2 it's right after this see 3,2,7,0 so I think it's right around the corner if you're interested in checking that out and thanks for your showing up