 Hi everybody. Welcome to Scaling Drupal for higher ed institutions. Before we start, we have ten seconds. Who all here works in higher ed? All right. Good job. Thank you for your service. So my name is Linnea Williams. I am the technical project manager with Stanford Web Services and I'm going to be moderating this session today. We have four awesome panelists. We have Christina DeLude from Dartmouth College. We have John Bicar from Stanford University. We have Brie Pendleton from Harvard University and Nancy Flowers-Mangs from Yale University. And I just want to kind of couch this with, we realize that we all work at Ivy's. That doesn't mean that you guys can't do this stuff. So, yeah, and I really want to say each of our groups is really working to our strengths. And that's what we want to emphasize here. That we're all taking different paths. There's not one right answer. So this is kind of, you guys know this context, but this is the context we work in. Remember the good old days when success was accomplished? One single website at a time? Well, now it's about scaling up successfully to provide a platform, distribution, training and support for an entire university. Take a deep breath. So some of the topics we're going to be covering today include business models, custom websites versus templates or products, training and support, campus Drupal communities, collaboration with vendors and features with a capital F. This is going to be less of a technical talk. It's more about how to think about collaborating with people across your institution, serve people the way you need, scale up your training, things like that. And we're not going to be hitting on these individually. There's going to be overlap. We're going to have a whole bunch of questions that will include some of these topics. So our basic structure is, and in the spirit of Austin, the quick draw, which will be introductions from each of our panelists about what they're doing at their institutions and kind of how that's playing out a little bit. Then we'll get into the nitty gritty, which will be our panel discussion. We'll have a series of questions that folks will be answering. And then following that, we'll have show your cards, which is your opportunity to ask us questions. So please do save your questions for the end. We're going to save time for that. And let's get started. So we'll start with the quick draw, our panelist introductions and Christina. Good morning, everyone. Good morning, everyone. My name is Christina DeLude, and I'm the web architect and technical lead for our central web services team at Dartmouth. I came to Dartmouth about three and a half years ago. Before that, I was at Duke University, and I drew both there. Is anyone from Duke here? Look at you all. So at Dartmouth, Dartmouth web services is a nine person shop. We're housed in IT, but we actually focus on user experience and design. And we list, we have sort of an appendix at the end of this presentation where we talk about our roles, but I'll go over them briefly. We have a director, we have the web architect, who's me. We have a user experience designer, who's Ben Wargan. Hey, Ben, are you here? No. We have a content strategist, Sarah Maxwell Crosby, who is here. We have an accessibility specialist. We have a web producer. We have two migration team members who are helping us with our big migration project, which I'll talk about in a bit. And we have a user support specialist. So our clients are administrative units and academic departments. We also manage sort of larger institutional resources, such as the Dartmouth.edu home site. And we also manage things like the faculty directory, which is a Drupal site, and what else, the front face of our institutional defense calendar. And we're sort of bringing in more of these larger scale projects also. So we don't support individual people's websites, so no faculty portfolio sites, no student sites, no lab websites, no course websites. We have a different tool for that. That's sort of more of a self-service tool that we encourage people to use. We're also in the process of migrating 200 websites from a legacy CMS over to Drupal. We launched these first Drupal sites pretty much right around a year ago. And we now have 30 sites that are either launched or in process, so only 170 more to go. So yeah, that's sort of Dartmouth web services in a nutshell. Do you want to go through some of your images a little bit? Oh, can I do that during? Yeah, that's what we're doing. Oh, sorry. Yeah, so that's our team. There we are. And so this is the example of our home site, which is the front facing Dartmouth at edu site. And so there's actually more to that page, but only that much fit on the screenshot. So if you go to Dartmouth at edu, you can see it in all its glory. This is a department website and academic department website. And we have like a basic template for that where they, the academic department sites all follow, they have like the same sort of overarching theme. But they have sort of different look and feel. There's another one, you can see it's sort of the same general layout, but it has a different color scheme and a different banner image. And then we have, yeah, so this is an example of our faculty of like a profile on our faculty directory. And there's sort of more to that page too. If you want to see, you can go to Dartmouth at edu slash faculty hyphen directory. Yeah, so those are just sort of examples of the types of sites that we do. Great done. So let's, let's move on to Brie. Hi, I'm Brie Pendleton. I work at Harvard University. I manage training support and documentation at my group, which is Harvard Web Publishing. At Harvard Web Publishing, we use OpenScholar to build our sites. So OpenScholar is an open source platform built as a Drupal distribution. It makes provisioning, am I loud enough? Yeah, okay. It makes provisioning sites very easy for us. We offer two levels of service for a website implementation. We offer basic service. So that's like project managed. We take you through a schedule and you get the whole PM thing, content strategy. And then we also have a self service website implementation. This is DIY. You do it yourself. It's free. We also offer training and support, both free and upgraded, but all of the three are both of these groups get classroom trainings, extensive documentation online. There's a community forum where you can log questions, report bugs, kind of speculate about what might be great in the future. And then we also have a campus community called what we call ABCD OpenScholar. So this is a little bit about our timeline just to give you a sense about what has happened in the web space at Harvard University. So you can see that Drupal or OpenScholar, which was Drupal 6 at the time, was created around the fall of 2009. And it was being used almost solely at the department in which it was built. And then in 2011, it was determined that OpenScholar would be the supported software platform for web publishing at Harvard. My group, Harvard Web Publishing and at that time was called Harvard Web Publishing Initiative was created in January 2012. We migrated our software to Drupal 7 in April 2012. We overhauled all of training and the support model in June 2013. We started our community based monthly campus learning group January of this year. And we rolled out our funding model since then. And so in the last probably like two weeks, we've trained up our lower level help desk to help us maintain some of the support that we need here at our campus. So about Harvard Web Publishing, who are we and why did we become a group. So we are part Harvard University IT, part Institute for Quantitative Social Sciences, which develops the software and brings our development process. And then HPAC, which is Harvard Public Relations and Communications. So they bring the best brand standards and digital communication guidelines to us. So we are about 23 people give or take depending. Director, we have one director, 7 p.m. or client relations people, three ux designer, content people, seven developers to support people and three interns. Our group started in January 2012. We have a combination of core funding and cost recovery. Currently, we have over 4000 sites on our platform. And we are migrating about 1000 from our legacy CMS to open scholar in the next two years. Both using our basic and or free kind of self service depending on the funding that the group has. So this is just an example of a basic implementation up here. It's the Faculty of Arts and Sciences Human Resources Department. Just kind of quick. And this is sort of a snapshot of our Harvard community. So we've got a page on our site that kind of links you to all the things you need to know about to get involved with having a open scholar Drupal site, or just learning about it. And then this is some of us at a Christmas party. But it's not all of us. It's not at all. And some people in terms of gone and other have come. But this is my most recent one. Thanks. All right, let's move on to John. Thanks, Brie. Thanks, Linnae. Hi, everybody. A couple of logistical things. If you're standing in the back, there are some chairs over here. Also, we have posted the slides. I posted a link to them in the comment section of the node here. So my name is John Bekar. I'm a Drupal web developer in Stanford Web Services. I've been at Stanford and doing Drupal for over seven years. The history of Drupal at Stanford is a bit longer than at some of these other universities. We've been doing it for a long time. It started as a real grassroots effort. As such, we have a pretty robust Drupal community on campus. We have over 300 users on our mailing list. We have an annual Drupal camp. Great. It's not as big or as bad as bad camp. It's not quite as bad as that pun, either. But Stanford Web Services was formed in 2011 as the first group on campus that offered centralized Drupal training, development, support and hosting. Drupal at Stanford followed the path of a lot of technologies at Stanford in which innovation happens at the edge. Stanford is a very experimental culture. We do a lot of things, move fast, fail fast. What happens with these innovations that happen at the edge when the technology grows more robust and grows more mature, it centralizes and Stanford offers more centralized support. And that's what Stanford Web Services is. So our mission is to provide the Stanford community a full range of Drupal website planning, design, development and maintenance support at well below market rates. This is our team. Our team consists of seven incredibly talented and hardworking individuals and myself. We also have a cardboard cut out of an alien named Howard. He's a stand in for our standard user persona. Howard drives a lot of our decision making in terms of user interaction and user experience. We provide, we build custom websites, for example, this for the Department of English at Stanford. We also maintain a free self service software as a service Drupal hosting platform called Stanford sites. This is an example of one of the sites how it looks out of the box. It's using the open source open framework theme, which we maintain at Stanford, develop and maintain at Stanford. We also do several Stanford branded sub themes based on open framework that are available to anyone at the university tested for mobile responsiveness, accessibility, etc. These are services that we provide to the university. Finally, this is a site that was built with the self service software as a service Stanford sites platform. This was not one developed by us. So this is an example of the community using the tools that we provide for free to the university. With that brief over you, I will hand it over to Nancy flowers mangs. Hi, everybody. I'm Nancy flowers mangs, and I am the senior web community manager for Yale University. And basically what that means is that I'm responsible for training communication documentation in support of our Yale sites but and in our growing web environment. Yale sites is our web publishing tool that is built with Drupal. We do have other options out there. We also have a WordPress service who is not and that group is not part of our group. But we are big supporters of Drupal as far as it being the main web publishing tools for our business and operations groups, faculty and courses type websites are usually in the WordPress offering. Our Yale sites instance we started working with that in 2000 between 2009 and 2010 2010 we launched our first Yale sites where we focus mostly on technology and did a rock solid provisioning system which was which is what pantheon was built on. So it's a kind of a pantheon type system. But we learned quickly that we should have paid a little bit more attention to the user. And so it while it was better than just doing HTML which is what we had before it still missed the mark a little bit. So when D7 came, we decided to put our resources toward making it better for the user. We actually had about, you know, two or three years worth of research and watching people struggle with our D6 instance. And so we created a Yale sites in the D7 instance, which has been quite a big success. All of our services are free, we don't charge back. I should say also in the process of that we were with ITS when we did our D6 instance, then they moved us to the Office of Public Affairs in a non technical environment. And now we're recently been moved back to ITS. Because when we and we built the Yale sites D7 in the Office of Public Affairs, but because we weren't in ITS we didn't have as many technical resources to kind of expand on our initial offering. So we've kind of been moved around. But still we have no cost for our services. We provide training support. We have an extensive how to guide. And we encourage users to ask questions and interact with our Yale sites forum to get the answers and find the answers that they need. One of my biggest jobs is developing a community within Yale, which has been the hardest thing for me, mostly because people don't want to do anything. They certainly don't want to come after work. I'm sure anyone in an academic department environment can understand that. And getting them for to a lunch meeting without food has kind of been a challenge. So so we're working on the food part. But anyway, the the underlying that kind of the light version of our technology is that we it's built with features. So in other words, we have a news feature, a video feature, photo gallery feature. So people don't have to think about what they're doing other than what kind of content they want. And they just add it. We provide both template and custom theme options. But you'll see in the next few pictures that I show you, we encourage people to use our template because it follows Yale standards, not just in the design, but also just good web standards. So we encourage them to use our template as their foundation, even for their custom theme. The templates are responsive. They can be built either in house, the custom teams can either be built in house or with a vendor. And we do have a list of Drupal partners that we recommend because they're familiar with our our Yale sites platform. Now that the thing about our our instance, which may be a little bit different from other people is that we have kept our instance to be very Drupal-y. In other words, when they go in, they'll still know that they're Drupal, but they don't come in with the blue and white, they come in looking like if we go to the next slide, they'll they'll come in this won't look exactly sorry, like it, but it will look something like that. So they're not they're going to look like it's a Yale sites. Now this is our Yale sites homepage. And that's where everybody can find everything that they need to know about Yale sites. The next slide should be an example of our our template. And this is what most people use. And it's interesting because we thought that people wouldn't want to use a template, they wouldn't want to be restricted. But when they come to training, which we encourage them to come to, I always kind of explain to them that this is kind of an open and airy template. And with the right content, which of course brings a blank stare, with the right content, you can actually build a really nice website with just these standards. And the next slide is an example of a custom template, which you can custom theme actually, which you can see follows a lot of our standards, but has a very unique feel. And so we've we've had a lot of success working that way. Great. So let's get into the nitty gritty. Now that we kind of know a little bit about where you guys are coming from. I want to start with the way we're thinking about our university and what we're offering. So so starting with Christina, in what ways are you tailoring your services to match the culture of your university or college? So Dartmouth is smaller than the other institutions on this panel, we have a little over 6000 students, about 4500 undergrads and 1500 graduate students. And so probably partially because of that, our IT infrastructure is a lot more centralized than that of many schools. We're also very, we take it a very top down approach. For example, our campus Drupal user community consists of the people on our team. That's it. It's sort of like websites are sort of like a service that web services like delivers unto you. So our campus IT is also very high touch. So how many of you work in the central web services department at your university? Okay, and of you who use people for that. How many of you when you deliver, someone asks for a site and you build a site for them to just give them an empty site, and it's up to them to sort of build out their content types and their views and all that. Who does that set up? A few of you. Well, so I thought there'd be more of you who do that. So in any case, we do pretty much the exact opposite of that. We we build the views and the content types and we build all the templates for everyone. And remember, I mentioned earlier when I mentioned earlier how we have launched or are currently working on 30 sites within the past year. I'm sure many of you are thinking really 30. That's it. But this isn't a straightforward migration we're doing from the legacy CMS over to Drupal. Instead for each site, we do a full content inventory. We work we rework the information architecture for the larger sites. We do user personas and card sort exercises. Who knows what user persona is? Good. Card sort exercise. Who knows what that is? Good. So we also work with our clients to select beautiful banner images and come up with a color scheme that reflects the colors used in the banner. And then we have two people on our team who help copy and paste all the content into the site. And so at this point, the clients haven't seen the back end of Drupal at all yet or the admin interface. Like we kind of lock them out. We work with them to develop their content and their imagery. But we don't actually get them in their editing until after after we launch the site. So I'm sure many of you are thinking the obvious question of why not just use my great module and call it a day. And we actually did automate this process initially. I wrote a script that crawled the directory structure of each of those output from the legacy CMS. And we sort of made this big XML file that we fit it into the site with feeds module because we use feeds module for everything. But then that's when we realized that the content itself needed to be reworked. And that's around the time that Sarah joined our team as content strategist. And so we took that opportunity to examine all of the content and sort of shine a flashlight in all the dark corners on the cobwebs, because most of our sites had launched about seven years earlier. And people sort of just growing stuff up there and not really, we're taking stuff down. And they also aren't web writers, particularly. So we needed to kind of overhaul the content itself. There's some scary dark corners, aren't they? Yeah, we've done a lot of them. So yeah, so after we launched the site, then our clients have mandatory Drupal training with our support specialist. And he sits down with people one on one and shows them how to use Drupal. And at that point, the site is then theirs. And they're responsible for content. We do sort of keep an eye on the sites, though, sort of informally, if someone seems to be having trouble choosing nice banner images for like, or nice, nice feature images for their homepage, we'll send them a little email like, Hey, you seem to be having some trouble choosing nice images, would you like some help? And they do actually seem to appreciate that which is nice. So it's totally locked down. All they can really do in there is edit content and create new content. They don't, they can't create content types, they can't move their blocks around, they can't create views. And so our top priority for our Drupal sites was to make it very, very easy for the content editors to manage many of them. It's not their full time job to manage the website. Often their administrative assistants are occasionally their faculty members. And managing the website is sort of an other duty as assigned, and not one that they particularly enjoy. And so many of them log into the website as infrequently as possible. So we wanted to make it easy for them. We also wanted to keep content fresh. And so we are working on pulling in content and information from other institutional data repositories on campus. For example, our faculty directory, which we showed a screenshot of earlier. That's a system where each faculty member can log in and edit a profile, but then the information from that profile gets fed out to their profile page on their academic departments that they're in. And so in that sense, it's always current. If they update their publications listing, it's automatically updated on their department site as well. We're also pulling in events from our institutional events calendar. And so if events are tagged as belonging to a particular department, those events will automatically get fed into the events listings on those department sites. We're currently working on building out a news site in Drupal. Right now it's in WordPress, but we're going to be moving it over to Drupal. And once that's done, the same thing will happen where news articles that are tagged as belonging to specific departments will be listed on those department pages. So we're hoping that sort of accommodation of making Drupal very easy to use and minimal work on keeping content fresh will sort of encourage our content editors or make their job. How many people have centralized data stores for faculty information and for events information like that? How many of those are in Drupal? Yeah, that's a pretty common. It's a pretty common scenario. And I think Christina's touched on it and we're dealing with the same thing, getting faculty to enter their information and getting events in a centralized place and sharing events, passing events from one site to another. It's a it's a common challenge and I think it's something that all of us are facing. So you're not alone in that. Yeah. So Bre, do you want to talk a little bit about kind of how you're tailoring to match your university and also the way you think about buy-in, how you frame Drupal at Harvard? Sure. Well, because we use Open Scholar, we don't actually talk about Drupal. We know that it's Drupal. Our end users aren't exposed to any Drupal talk. They've never heard of a node or a block. And we do that on purpose because we feel like it's a lot of it's a big undertaking to not only teach them how to use, you know, the front end or the CMS part of Drupal and just to manage their content and update things and keep things relevant and fresh, but to bog them down with talking about Drupal and Drupal speak kind of gets overwhelming. So that's something that I think we do rather successfully. You know, we call things posts. You know, we do talk about the layout. We they have administrative area functionality available to them, but we kind of keep it nice and light so they don't feel overwhelmed. So our big sell for Drupal, I'd say at Harvard University is that we it is supported. So if you move to Open Scholar Drupal, then you can get help from our group. And like I said in the opening slides, we've been training up our first tier one help desk folks to be able to triage some of the lower hanging fruit for our group. And so I feel like they the user group at Harvard feels like they always can get help. So that's how we're doing that successfully. So Nancy, do you want to talk a little bit about how you structure and address requests for new features to your service? One of the ways that we do that is through our user forum. We encourage people. We have people come through training. Our setup is a little bit different from what Bree just talked about in that we don't it's not 100% Drupal, but we do have blocks and and use the regular menu system. And so it looks a little bit like Drupal with the with the Yale Flare. But but when something comes up and someone has a problem after they've attended training, then we ask them to post their question to the forum and we're able to monitor the the most frequently requested features like what types of things people want. A lot of times what will happen is someone will create a website a custom theme and they'll say like for instance the one that we showed you on the world and people saw that rotating feature and they wanted it and so we're in the process of building a feature with a capital F. So people just have to enable it and add pictures and news stories that are connected with it. So we're able to have people go directly to the forum and then we we just it's just a regular Drupal forum with comments and we dialogue through that. It does help to keep down the direct emails. I always tell them if you email me directly you're almost guaranteed it's going to get lost in my inbox. But if they do it through the forum there is a chance that more people will be able to address it. And if it's something that I can't address I can forward it to our more technical team and then they can take care of it. So are people allowed to add custom modules, custom themes to their site at all? So we we do have a predefined set of modules that are part of our setup but if there is a good reason for someone to add a module we do allow that. It's not locked down in that way and and any other theme that they want would want base theme when we work with our Drupal partners so a lot of times they want a different base theme. We do talk to them about that because we want to make sure the reason that we prefer our Yale sites templates is because they we know that they're following the standards that they're following the design standards that they're going to be responsive that people are going to be able to work with them once that vendor relationship has ended. And I think that Nancy touched on a pretty good point especially talking about how she's moved from ITS to university communications back to ITS. One of the common challenges that all of us faces that we're not really a lot of us aren't really trying to solve a technical problem we're really trying to solve communications problems. We want to get the best and the brightest at Stanford. I mean the heck with these guys right? And that's really ultimately we're fulfilling a communications problem. And so having consistent branding having consistent accessibility having consistent use of the logo and mobile responsive really helps us fulfill that. We like the technical things but it is a communications function as much as it is a technical one. Okay. Bre do you want to talk about how you're structuring. Sure. So we do something that I think is rather interesting. We not only with our basic implementation you know our PMs are working hand in hand with different groups on campus to define what they need. And if it's not something that we have pre-built in open scholar every single request if it's from the Department of Chemistry or a student who just needs a site for his student group. They post all of their requests on our community forums. So it's built off of get satisfaction and so we're able to or anything that anyone wants always has to go first into what we call the community. And so it's completely transparent. People can but you can go in there and you can vote for a feature. You can the developers can ask questions of the person who submitted the you know initial posting. And so you're really starting to see things flush out. And what happens after that is it gets put in the back log. And so we have a six week development cycle. And so all of the things in the backlog get discussed in week one which is planning. And then they get prioritized from there. And we kind of scope it out to see if whatever these requests are will make it into this release or maybe it gets pushed off because we've decided as a team it's not a feature that many people at the university would use because that's the goal. It's not to build this one special snowflake module for this one person who desperately needs it. We're trying to build things that many people can use in many different ways so we can actually scale up successfully. Yeah. John do you want to talk a little bit about because Bree when you were talking about that the impression I got was that you have a separate dev team for your product versus custom websites or implementations. Yes. Yes. We will do we have done custom. We are hoping to do more custom in the future. But pretty much we take the open scholar core and we will build off of that. We won't just build a custom Drupal. Yeah. Yeah. John you want to talk a little bit about the structure of our team and how we've been sort of skirting that as a team. Sure. So like I said Stanford Web Services has been around for about two and a half years and we started out building bespoke custom websites for clients and we found out rather quickly that that doesn't scale and at all. And so we've moved we're starting to morph more into a product product development shop. Christina talked about and and Bree talked about the admin who doesn't care who managing a Drupal site is not part of their daily job and they don't really care and taking the Drupal out of it. And I joked about Howard our cardboard cut out. But we really we focus on Howard and we build these products. Howard is our admin in an academic department and Howard doesn't want to build contexts. Howard doesn't want to do contextual filters and views. Howard doesn't want to know what a bean is. And so we really let Howard drive a lot of our UX and our UI. And similarly in working with departments and units on campus and building these bespoke websites there are a lot of things that are constant. We talked about faculty profiles publications news events courses. These are pretty common. Then there's also the use case of a little bit smaller like a lab that just has they they just got grant funding. They need to launch a website tomorrow to fulfill part of their grant proposal. They just need five pages talking about the the project in a couple of pictures maybe of their P.I. So we have rolled out two products one called Stanford sites jumpstart to fulfill the use case for that small lab. It's very clean very simple. It's we we positioned it as a Google sites killer all static content comes with completely responsive templates. A custom layout on the front page but then like five top level menu items. Simple whizzy wig easy out of the box forever maintained on our central service. And then a product that's called Stanford sites jumpstart academic which is more robust it has the dynamic faculty profiles publications news events and we've rolled that out now for two different departments on campus the public policy program and the department of sociology which you can see at public policy that Stanford edu and sociology that Stanford edu and for the jumps an example of the jumpstart one you can look at provost that Stanford edu. Yeah and I'll say you know our team doesn't have a big training force behind it. We have strong developers and so I think that's the the direction we've tried to go is make something that that doesn't even need training if you can do it because we just didn't have the bench to be doing lots of training. And so speaking of training like that transition. You want to talk about training at at Yale and how you guys are structuring that. Yeah and and so that it is interesting because when we were preparing for this talk and we're all kind of sharing our different stories we realized that a lot of the ways that our platforms had been developed was kind of based on who we had for staffing. So people who had a lot of developers were able to develop a lot of more custom things and have it out of the box. And we when we first when we when we did our desix implementation we were in ITS we had some stronger IT people. Then we went to OPEC there were four or five of us. And so that was a pretty small team in each one of us had our own strength. We had one developer one person who was a CSS one person who was just kind of a site builder. And then my specialty was training and communications. And when we did our desix and since we didn't think anyone would need training. And that quickly we found out that that was probably something that we would need. And so we've always had a really strong training program. It's not required. But we try and evolve it and kind of build the community so people want to come. Training is free and all the training is hands on so people are actually working on their sites while they're in training. And so it's a lot easier to justify a full day of training when someone leaves and at least three quarters of their site is built if not more. It all depends on how big their site is so and again we're talking about the basics template basic templating sites we're not talking about custom themes. But the training has been really really successful. And it is allowed us the fact that I'm able to do it as my primary job. It's allowed us to have a more open platform. And I actually do teach content types and views and I'm pretty amazed at how people pick that up. People say oh you teach content types and views. But it really because we have a dedicated person and I you know I'm not teaching them contextual filters out of the box. I'm teaching them how to create basic lists I'm teaching them the basic concepts of you know the underlying database and how you know how you create structured content. But it's it's really been successful and helped us to help people to empower people to do what they need to do to build their websites. Go ahead. You want to show So what we did when we HWP Harvard Web Publishing moved open scholar from a department to our group. We overhauled all of training. So it was a one hour training where they kind of talk about everything. And it's now two and a half hours. So we offer department based or group based training. So it's two and a half hours. We go through 15 activities and we talk about different concepts kind of Drupal concepts but also best practices. So it's really great. I do the I do the trainings myself and people really learn a lot. And we also offer a training for people looking to build a scholarly website for an individual because obviously some of the activities would be different and the goals and methods and how you build the site would be different as well. We have documentation also but we do encourage people to attend training. It's not mandatory. But if you were to submit support requests to me I might say hey I haven't seen you at training. I might look you up you know and say you haven't been to training maybe if you came to training it would cut down on some of this. Unlike what Nancy does we build sandbox sites. So they're like just totally test sites that they build right there day of they have access to them up to two weeks so they can play around. But we don't have people working on live sites because there are too many questions about very specific individual like but I want to do this and it might derail the class. Do you want to talk about your support model so how people get help. That's leading into your training. Yeah. So that's a big deal too. We have multiple ways. So like I said we can we've trained the help desk. So that's kind of our tier one me and another co worker and some co ops. We do tier two support and then we have tier three support which is our development team. So we use the ticketing system like most universities do. So if anyone has a question they email to it help at Harvard edu and it gets routed to our group by passing the help desk if needed. And then additionally what we do is we have our ABCD open scholar. So it's our monthly topic based what we what I consider to be advanced training. So one month we did everything on taxonomy. We taught how to use taxonomy. We had like low level to very very high level examples. And then also with that 15 minutes of every one of those meetings we open it up for people to bring their laptops and bring their real time questions. We have the community forum. We have our documentation sites. Yeah I think that's what we do. Feels like a lot. So I'm going to jump ahead. John since at Stanford we had this existing community. We're not really working on building up a campus community. How do we how do we think about integrating with an existing community without causing confusion. It's it can be a challenge. One of the things that has happened as Stanford Web Services has started and grown is that we now kind of have a target on our backs. Everything any help ticket that comes in that has anything to do with web comes to us which we may or may not be scaled to to deal with the the ways that we integrate with the community is that we're very we follow the very open source mantra. So we we open source almost all of our code. We make sure that we participate a lot in things like the Drupal's camp the Drupal camp and the Drupalers list and help people out on all of the various platforms of Drupal that they can be using. We have kind of a dual responsibility based on our dual funding model. So we're a combination of core funding coming from the Provost office and cost recovery. So we do charge back to clients at below market rates. So we have a responsibility to the general Stanford community web community not just Drupal community. But we also have responsibility to our paying clients and balancing that can be a challenge. And we honestly we we go back and forth almost on a weekly basis. And in terms of defining our priorities who should we be serving whether or not it's the larger powerful more better funded entities on campus or the little guys who don't have any funding. And we really try to do our best without getting spread too thin. But I will admit that it's an ongoing challenge. Yeah. So Nancy from the other perspective what sort of what sort of things are you doing to build a campus community. Yeah. So that as I said in my initial presentation that building the community it's been the hardest. Most of the people who are building sites are admins who did not expect to be building websites. Some of them are more excited about it than others. But some are just like this is not my job. And so I have really worked to try and get people enthusiastic to encourage them to let them know that they can do it in training. Training has been a big community event even though it doesn't might not seem like it because when people come to training I really really try and let them know that you know they can't break this which is a big relief because you can before this basically people were building sites in HTML and they could just delete the folder and you know kill the site. So that their fear is is probably is reasonable with the past history. But I let people know that they can't break it. I let them do whatever they need to do to try and make the mistakes within class. So it's a very open and encouraging environment. And then we also have we do have Yale sites Drupal Group which is kind of slow to get going. But the biggest success is that is having our Yale sites Drupal Camp which is a full day and we actually get people I don't do any presenting. And we get people who are actually building sites to do their to do presentations on what they've done. And that's been really really successful. You can it's kind of like like when you leave Drupal Khan you leave with that glow. And you see everybody leaving with the glow and it really it's really a nice a nice feeling. So so a little bit different topic. Let's talk a bit about vendors. So Christina do you want to talk a little bit about how you have sort of integrated vendors into your process and where you hire them. What sorts of things you use that for. So we're hosting all of our Drupal sites in the cloud with Acquia. And so they handle the hosting but we still manage our own code. So they're not going to troubleshoot or they're not going to do any development for us or write us any modules. But they can help us troubleshoot if there are problems. We also have a fairly hefty support package with Acquia. So remember earlier I mentioned that on the technical lead for our team. I'm actually also the only technical role. So that is where Acquia support comes in. It gives me the opportunity to come to events like this and not have to be glued to my email the whole time in case things just go horribly horribly wrong with the sites. And so this works fairly well for us or very well for us. Because with Acquia handling the hosting we can focus on what we're good at which is building beautiful usable websites. And when we decided to switch to Drupal we actually did spec out a scenario where we hosted on campus. But in that sense we did that we'd have to beef up our resources and web services we'd have to hire a few more of me. And also our systems team would also have to hire more people and increase their skills. So in that sense even just with staffing resources alone it was actually less expensive to host in the cloud with Acquia than to host internally on campus. John you want to talk a little bit about hosting our hosting environment at Stanford? Sure. With regards to vendors or just our hosting environment? Our hosting environment we can come back to hiring vendors. So for Stanford sites we host internally we have an infrastructure team that maintains the hosting environment and we the Drupal team the web services team takes care of the Drupal level of the stack basically without getting too technical the infrastructure team runs everything up to the lamp section of the stack and then the application layer is us. And that's all that's all hosted internal. We also have so that's Stanford sites and end users the only interaction that they have with that is through the web UI through the Drupal UI so can't add custom themes can't add custom modules. We do review what gets added to the central stack and we do continually add things. That's Stanford sites. There's also a a open web hosting environment the the web servers the W W W servers that anyone that have a CGI bin space and anyone any group any individual can run PHP, Perl, MySQL anything that'll run on a lamp stack and that was actually that open environment was really what led to a lot of the innovation at Stanford. And that still is ongoing and is still a viable option for people to host Drupal what we realize pretty quickly with that hosting environment is that keeping up with with patches and maintenance and updates for Drupal was a real challenge on that and that was what led us to build this more software as a service platform. Yeah. So on a related and or unrelated note do you want to talk about how how we've hired vendors to supplement our team occasionally? Sure. So Stanford has a pretty long history of hiring Drupal vendors at least as far back as 2007 when I first started getting involved and there was a lot because Stanford so decentralized there were a lot of vendor contracts happening and vendor builds happening on campus that there wasn't a lot of transparency or any communication to the rest of campus what was happening. And so a number of people have started to see this and see the inefficiency of that model and over the years various initiatives have tried to really write the ship. And that's one of the things that led to the creation of Stanford Web Services. There was a provost efficiency initiative and one of the proposals was, hey, you know, we're spending all this money on vendors and not getting a lot out of it. Maybe we should be doing some of this in-house. That's not to cast dispersions on any particular vendors. Although if you come up to me after the session, I'll be happy to cast dispersions on a particular vendor. So we still do work a lot with external vendors. There's no way that Stanford Web Services, like I said, there's no way we could do everything web at the university. What we really focus on and what is my colleague Zach Chandler's main role is working with vendors to work at Stanford and say, hey, you guys do good work. We're excited to work with you. You're a top Drupal shop. We want you to bang out this Dean of Research site. We want you to knock it out of the park. We want you also to roll back the code that you're doing. Open source this code. Make it a value to the rest of the university. And we've done that with client, with vendor work. So Dean of Research is one that we've rolled back some of the policy stuff that are working on. There's another vendor that's working on our central faculty database, a Drupal module to interact with that API. Open sourcing that as well making that open to the rest of the community. So it's not about just reducing costs. It's about increasing value. So we're willing to spend the money, but man, we really want to get the best bang for our buck. Additionally, in Stanford Web Services, we do the same thing. When we want to build extra functionality and we just don't have the bandwidth to do it, we'll contract on an external vendor, say, hey, we want you to build this sub-site functionality or whatever and hey, we want to open source it. And the awesome thing about the Drupal community, the Drupal vendor community, is that you know the good shops because they're the ones who have their devs contributing back to core, maintaining contrib modules and then open sourcing the work that they do for you as a client. I don't know how many people saw Dries's blog post from yesterday about giving, OK, Sean and I are the only people in the room who saw it. Dries posted yesterday a proposal to provide credit to shops and customers who contribute back to open source. And it was a pretty lightweight way of beginning to gather that data. And then the proposal is let's do something with that data once we start to gather that. So I would suggest everybody go take a look at Dries's blog. I don't remember the name of the blog post, but it's a great way to contribute back to open source. Awesome. So we've put together some resources for you guys, just product descriptions or user guides, things like that. So these are all on the session in that comment. So you can go ahead and click on these if you're interested. We have our GitHub accounts there so you can look at our features if you want. But it's time for questions. What questions do you guys have for us? And please use the microphone if you will. Hi there. So I kind of want to continue off of what you were saying, John, and maybe hear from some of your other folks. Obviously, open scholar is open source, but can you talk about how you in your university have made the decision or if you had to persuade upper whoever to say that this is OK to contribute to open source, specifically GPL 2 and maybe 3 or something. We've had the experience that that's been kind of a non-starter in a lot of ways. And there's been a lot of kind of uncertainty about using that. So how have you made the decision to contribute back? Have you made the decision to contribute back? And how have you convinced or what are the reasonings that you find that benefits the university for you to do that? I can speak lightly to that because I'm not a technical person. We don't have something like open scholar that we can contribute back, but in our work in working with Drupal, you know, we make patches to things and we have built modules and everything, every module that is, I shouldn't say every because there are some that are custom and unique just to Yale, but any module that is created to add functionality to the site has to be go through the community and available to the community as a Drupal module. You can't just build one locally on your site and just expect to use it for just that. And that's the most I think that we've been able to do. Did you have to convince somebody about that or do you just do that anyway and you never really ask permission? No, yeah, we didn't have to convince anybody because it was part of our work and it was just the way we did it from the beginning. Yeah. And I don't think at Stanford we've had a lot of pushback against that. I mean, we're in the heart of Silicon Valley and open source, free and open source software as part of the DNA, but there certainly are stakeholders that do need to be convinced and we, you know, some of the selling points are look at all the value that you're getting from this open source community, you're getting free support, free software. And that kind of makes a business case in terms of committing back and we've had a lot of success with even with our clients going back to them and saying, hey, we built this feature for you. Do you mind if we repurpose this for other people on campus? And they're like, oh, that's great. That would be awesome. So that's something else that works well. Yeah, please. So I run a Drupal agency in Boston who serves higher ed primarily, including Harvard and MIT. And it's so great to hear about the move towards software as a service to be able to scale this. But we run across clients for whom that's not going to serve their needs. They need something more custom. So I'm curious to hear more from all of you about the best way that vendors and Drupal shops can better sort of complement and support the services that you're providing. Bre, do you wanna talk about that or Christina? That's a big one because we struggle with having to want the sites being built by a vendor who supports it. The after it's done, it seems to be like the client, the department, whoever it is feels like, oh, well, great. Now, I have built this little thing that's so important and special, but then who is going to support it? And so that has been a struggle for us because we don't have the bandwidth to support custom built sites. So that's why we have such a big push to build off of OpenScholar. And so we're only maintaining a module here, a module there, a feature here, a feature there, a special search something, something here. So that's why we don't tend to want to go down that path because I think the expectation is just that we're gonna pay hundreds of thousands of dollars for a custom site, but then, hey, Harvard University IT, support me and help me maintain this over years to come. So it's difficult. Go ahead. I can speak to that, that we have certain standards that our Drupal partners have to follow. All the sites aren't necessarily built by our Drupal partners, but they quickly learn. We usually try and get in front of them before they start building because we do have a specific way in which sites can be built. They can't create their own custom modules. Of course, they're not supposed to hack core. The biggest problem that we have with that is that people will hire people who say they know Drupal and don't. And so that's part of the reason why we have the Drupal partners list because we know that anyone on that list is a Drupal enthusiast and also understands the Yale sites platform. But we do have certain standards that they have to follow and they're usually onboarded before they start the project. So what I might say to that, at Stanford, what we found is that what she was saying, if you can make a collaboration with the web services team at the university that you're working at, that can help you because they often know how to leverage on-campus technologies. So we have our hosting platform and vendors can build on our platform. But it's trickier because they can't get into the code but we've had some very successful collaborations where vendors have come in, they've built a custom site and it's on our platform so we know that they're getting updates and everything is being managed well and into the future. So I think that's the balance that needs to be struck with this is that we wanna make sure that if a vendor's coming in that there's a decent support plan for that site. And be frank with them about the total cost of ownership of their website. It's not just the bottom line dollar amount of building it, it's like you need to figure out where you're gonna host this thing and how much it's gonna cost you for support over the long term. Yeah, cause it sounds like for any of you guys if someone needed a really custom thing that was very outside of the box, they would pretty much be responsible for finding their own hosting and support. It wouldn't, that's not true. We haven't built it in our Yale Sites environment but we have, the custom site has to be built so that if the vendor walks away because that's not intentionally. But it's a strong possibility that something's gonna happen and that relationship's gonna get built and that relationship's gonna get broken whether it's because the vendor no longer exists or because somebody doesn't have the budget. So when they build a site, they have to set it up so that when somebody gets new staff and they come to training, they're just going to add content or content edit. And those are the kind of standards that we have to make sure that even if it's a custom site, the backend still remains the same. Right, yeah. Thanks. Great job on all you're presenting. Real quick question on kind of privacy and what you guys are running up against. It might maybe lean towards maybe some of the self-serve things that you guys do. But I'm curious if you guys could maybe speak to how you deal with content coming in from maybe student population that could have copyright stuff or like if you guys are doing anything special there and we want to talk to that, that would be super. That's interesting. Okay, so we have a somewhat vague copyright policy that is linked off of the bottom of many of our public facing websites and it, yeah, it basically is sort of like, don't take other people's stuff. It is very vague, though, I will say. But we don't have anything like technically enforcing that at all. Yeah, that's it. I don't know about the rest of you guys. We have various data classifications. We don't, and I'm sure that every institution has this, but we have confidential restricted prohibited data. And so the only types of information that we deal with on our platforms, it's a content management system. So this is one of the things that we try to consult with people with clients at the very beginning. Like this is a content management system. This should not be, this is used for building public facing websites. This is used for putting out information that you want to be public. So if you want to build an internet with Drupal, you can do that, but it's probably not the best tool. And so we have a strict policy, it's not even pretty strict, but strict policy of no restricted or prohibited data on our sites because they're just not rated for it. We have a small bit of pin authentication built into our site, depending on what kind of permission or site visibility you set it at. So we could, you can set your site to Harvard only. But again, it's not for high risk confidential information. It's for more Harvard only classified information. Nothing FERPA related obviously. So, yep, no FERPA, no HIPAA. Yeah, actually just to definitely, Lisa, we have actually for that kind of private information, we have those sorts of guidelines also, like don't put any information that you wouldn't want the world to see on your website. We do have some things that are locked down behind authentication, but even then it shouldn't be things like social security numbers or medical anything or that. We also integrate that as part of user training. We had some content editors who would copy entire articles from like New York Times that their faculty members happened to be mentioned and just sort of like posted on the website without attribution. And so we've been trying to integrate those sorts of best practices, or in that case, like worst practice, and you know, like don't do this. So that's a user education issue. Please. Several of you mentioned documentation is a big part of your service. And I'm wondering a couple of things. One is where exactly are you storing that? Is it on a Drupal site or another tool or service? And then kind of how much of it's public, how much of it's private? And for those of you that have a more fractured environment, how you're actually, how you're coordinating and standardizing documentation and sharing it. Ours is fully public facing. It's on the resources you guys should leverage it if you can. It's on an open scholar Drupal site. Um, what else? Yeah. Our public facing documentation is on Drupal sites. Right. Yeah, and ours is all open. Anybody can access it. Right. I will say that Stanford Web Services is looking into potentially doing something that's a bit more robust, maybe with like a Zendesk option or something like that, but it's still experimental. We haven't rolled it out in any way. Yeah, and we're just using the book module. Nothing fancy. We use basic pages, nesting basic pages. Hi. So it sounds like you provide centralized web services that are available to anybody within your university. So my question is two part. One, do you have web services teams that work for individual schools and colleges and other entities? And two, if so, what is your working relationship with them and how do they fit into the workflow process? John, you want to talk about that? Sure. We're not even the biggest Drupal team at Stanford or the most technically savvy. Yeah, we partner with, it ranges everything from a single Drupal developer in a small unit to a full Drupal team like at the Graduate School of Business and we work with them in various ways. We'll share code, we'll share tactics, we'll share all sorts of stuff. And so it just kind of depends on what their needs are at the time, what we can provide and then what they can provide for us. It's open source, it's the community. So we're one minute over. I'm gonna encourage you just to come up and ask your question, is that okay? Yeah, that's totally cool. All right, thanks everybody for your attention. Thank you for your attention. Thanks. Thanks. Thanks.