 Great, thanks for coming. My name is David Turnbull. I'm the manager for UNSW Web and Innovation and have been for the last three years at UNSW. And it's been a pretty interesting time in transition. Today, I brought with me Jeremy Epstein, also known as Jazza in the DrupalCon community. He is one of our developers, external. And so, first and foremost, this is going to be a business case. I mean, this is a bit of a history. It's where we were at, how we got to where we are now, including all the actual financials, which almost no one ever gives in these kinds of presentations. And then at the end, Jeremy will actually take you through some of the sites and some of the technical challenges and some of the technical aspects of that. So you'll see how we implemented that. So we're going to quickly burn through a few topics today. Just to let you know, to give you a bit of context about UNSW, we're ranked 65th in the world in quality insurance of educations. We've got about 53,000 students, which is a very large student body. I mean, it's right if there were some of the largest American institutions. Nine faculties, quite a bit of complexity. And overall in the domain, we're talking about 350 websites. The central web unit, until April of 2010, it basically consisted of me. And well, actually, before me, it consisted of a part-time producer and a graphic designer. And then I joined as the manager. There really wasn't much of anything happening at the time. It was a policy-only body. But we did have the benefit of a really robustly and strongly thought-out strategy. So we had a roadmap. But there was very little budget. But there was massive opportunity. And when I first joined them, I didn't think this is what I'm going to do. It was after four or five months of actually looking at what the circumstances were on the ground, that I realized there was a tremendous opportunity to move the web unit into the production space and doing so on cost recovery. So the way things were, like I said, at the time we had multiple decentralized channels for web development. Anyone at UNSW could go to IT and get a website done. There was a joint venture with Fuji Xerox operating in the web space on campus. And any unit, any division, any school, any faculty, any whatever could go to any agency anywhere on the planet and get whatever they wanted done. And that's just the way things were. Now, the opportunity there was is that there was room for competition. And there was an expectation that websites cost money. But I know we still get the request going, yeah, I need Facebook by Thursday for $2,000. And you just go, OK, well, they cost more money than that. There was no integrated approach to communications. Websites were being spun out left, right, and center by anyone in any agency. And they weren't connected together. There was no way to traverse from one website to another. There was no logical grouping of like for like services or service centers across the domain. But there was an inherent advantage to being the internal provider. People trusted us. And because we had that internal awareness, we could start to solve individual units and groupings together. I wasn't seen as the outside salesman. And it gave me a tremendous amount of access just to go in and solve their problems, solve the business problem, focus on the users. And ultimately, I had the advantage of reduced overhead. I'm not paying rent, and I'm not paying to keep the lights on, and I'm not paying everybody's salaries. I did have myself as on staff at UNSW, my designer's on staff at UNSW, it was only the developers that we had to cost to cover on. There were multiple content management systems in play. At the time, I identified 37. There were more that we just couldn't decipher the DNA. We had no idea what these sites were built in. But we could build the case that a better, cheaper, more flexible CMS option could save the university lots of money. And that's where Drupal comes in. At the time, we had 897 sub-domains, over 350 plus websites. So there was just this rapid, long-term period of anyone who wanted a website clearly got one. But the opportunity, of course, was every single website was going to have to be rebuilt. So that's a sales pipeline, if we could tap into it. And it was one that, like I said, being internal, we had an advantage to. There was no active domain management. And because of the multiple methods to get a website, there was many procedural policy and ownership vacuums. There were services that just nobody owned. There were sites that had no owners. There were technical and logistical variances between what was basically across the web. And that gave me an opportunity to simply take ownership and responsibility for different aspects of the web. Now, there were cases where I came across where there was a service that nobody owned. And I asked to own it. And people said, no. Not because they wanted to own it. They just didn't want me to own it. Or maybe there was some benefit to someone of services not being owned. But by even going around and finding out about all these services, it increased my and my unit's stakeholder contact. And we were able to just go and meet people and find out who they were and where they fit in. And even having these conversations generated a lot of goodwill towards the central web unit at the time. And the biggest opportunity of all, there was a negative attitude about web across UNSW. Because of the disparate technologies, web was hard. It was difficult. The back end content management systems were confusing. They were overbearing. And it was expensive. And it was big and scary. And no one wanted to really touch it. And that opportunity was to change that mindset. Which I think that the web unit has been very successful in doing that. And again, given the great usability of Drupal, when you give somebody a CMS that was just so simple to use and was orchestrated toward not just the end users of the content of their site, but equally designed to meet the user needs of the people administrating and maintaining that content, a lot of people just came to us and said, this is so much easier than what we had before. So 2010, we just figured out that we could actually turn into a development shop. And the first thing I was going to need is revenue. Because I needed to know that because you just can't hire someone at a university, there is a process. And it's very methodical. So the first thing I did was I approached units to put in an SLA. I wanted funding. I just needed the money. I needed to prove that I could pay somebody that I brought on. So basically, I took all of my initial funding. And I hired Brian, who's my senior developer. And basically, we brought him on a one-year contract because I mitigated risk. I negotiated SLAs with two of the larger divisions. And basically what they did is it covered 60% of his salary, but freed up 50% of his time to do other projects that we could then charge and cost recover for. And at that time, we were building sites in both Drupal and Django. We were keeping it open, sorry. So we were keeping our costs down. Ultimately, Drupal won the day. We still build in Django where there's a specific use case for it, data-driven sites, et cetera. We look at the technology and what the use cases are before we decide on the technology. But now we've built so much in Drupal, it's really meeting loads and loads of the user needs. Another thing we did was we automated the domain or sub-domain request process at UNSW. So now you can go to the central web unit site. And you can go here to the domain name application and you can apply, which gave me a sales pipeline. Oh, you're building a website. Yeah, what do you need? Let's talk about this. And this was, again, something that nobody else wanted, but the policy framework put under my control. And so by simply taking reins of that and automating that process, it automated my sales pipeline. And that was critical to the early success of the unit in terms of driving both projects and revenue. Avalanche is better than none, for those of you older Rocky and Bullwinkle fans like me. After four months of operating, so really we hired Brian first of September in 2010. By the end of the year, we were way over capacity. The demand was just outstripping our ability to deliver. We added a technical producer or go-to guy, which we rated out of marketing. And we convinced marketing to pay 50% of its salary. And I still don't know how I pulled that one off. But what that did is it also gave me a very expanded skill set that I could then go and sell. There was already demand for services for what he could provide. I knew there was a market there. And again, I was able to put the business case. So he would then spend half his time working on marketing. But again, 50% of his time could then go to projects where we could drive revenue and recover some costs. And what we did is we used external sole traders to keep all our costs down, where we had the demand. And basically, we continued to consolidate our service level agreements across the divisions. And so we just had this one stream of revenue coming in through SLAs, and then we had a project stream of revenue coming in. Now, this is what turns people's heads. In six weeks, I'm going to get a bit of definition in terms of what cost recovery is. We see cost recovery as being one of three things. One, it's money not leaving the university. That's the opportunity cost. So because we were able to deliver services that say 25% or 30% of what that flow on was, we were immediately able to save money. Two, it's the money actually coming into the web unit to support the cost recovery positions. And three, it's the cost savings to the individual units, because if it would have cost them $10,000 before, it's only costing them $2,000 now, they have a cost recovery of $8,000 on that project. So what you see here is the numbers. Now, what's happened in these early days? These were actually quotes from agencies. These were out there. I had these physically in them. Once we had the capability to deliver on them, we were able to cut those costs either through internal charging or through using subcontractors to the university. So in six weeks, we were able to recoup about $76,000 in cost. All the bigwigs in our university are upstairs for me, and I would see smiles on that stairs coming down after that. Over four months, that blew up to a cost savings of the university of $240,000 in those first four months of operation. Some of this, where you see zeros here, the way that this slide works is that this is simply where there was no external cost. There was no longer going to be an external cost for those projects. So there might have been some internal charging on that, which is represented. I grouped them according to the top where there was internal charging. But after that, it was just run through. So it was a good end to the year. 2011 achievements. Basically, we started to work with faculty IT to roll out Drupal as the common platform. This all started back in, basically, prior to my joining UNICEF, when Jeremy will talk about this after. We had a massive project called the Research Gateway. And the Research Gateway was so intensely scoped and built in Drupal that it served a nice platform for us just to roll out. And anyone who saw it in faculty land wanted it. So we had a good demand there. And for the first time, we had a history where faculties basically have their own faculty IT teams. And a lot of them were in different non-convergent platforms. They were all coming onto Drupal, because it was Sharon and Cheryl-like. Also, they would co-fund developments. So faculties would get together and say, David, we need this. How much do you think? And also, it's going to be $5,000. And they'll each pay $2.5. We'll develop it. We'll roll it out to them. And then we'll give it to everyone else who wants it free. So individual units were basically supplying the costs and the development funds to roll out stuff centrally, basically building our code library. And basically, web was starting to become a very positive experience. It started with the IT guys, with the faculty IT guys, who were just really excited about it. And then it started to get to the end users. And that's where there was a very significant cultural shift. Web was no longer big, scary, and expensive. It was becoming cheaper, easier, and a little bit more fun. Now, on the technology side, right now, there are slightly over 100 Drupal sites who have launched or planned in Drupal. And I mean, I know that there's probably 95 I can confirm that have been launched. Many of the themed elements in the custom modules are reused across multiple sites, which we used to keep costs down. And we do integrate with university systems where there is a demand, including our authentication system, or LDAP, if you're familiar. The site content editors are just overjoyed with the UI on the back end. It's so easy. When they just look at the back end page, and rather than seeing directory tree file structures, or web parts, or whatever it is, just to see that front end with an edit button, they just love that. They know exactly where the content is going. And just the ease of that has created a significant word of mouth about the unit. Most of the calls I take now from new business, and I treat everyone like clients, as we've heard from so-and-so and this and that, we do offer training and manuals with every site we turn over. And our record shortest training session is 13 minutes for a non-technical user. Simple sites, but still. We take all the overwhelm out. 2011, we built the unsw.edu.au site in Drupal, launched and deployed externally. We basically, then, were told on December 16 of that year that we had a new color, yellow, which we all love to work with and design with online, don't we? Now, what that did, though, is, again, it created just this instant rush to the web unit going, we need help. Can you assist us with our redesign, with our redeployments, et cetera, et cetera? And we just as helped everyone we could. Because of the way university budgets are set, they're usually set in the September of the year before to get hit with what was going to be an additional spend in December was unpalpable to a lot of people. But we helped out where we could. We're still helping them out. We managed to hire additional staff. So I handled basically someone to keep me organized to get, well, actually, technically, I hired her to get me out of the way. And also to be trained up as a non-technical project producer. Also, my two previous hires on cost recovery were made permanent simply because I could make the business case. And so for those of you who are in organizations where you're desperately needing resources and people, if you could put an ROI to that, the people upstairs or down the hall or wherever they live in your organization, that's what they will listen to. We also delivered a development model that basically meant that we could deliver websites customized to the individual use case level much cheaper than organizations could deliver a cookie cutter site. There was no longer the fear of this is going to cost you a fortune unless you use this exactly this way. So we blew that out of the water. And that's typically around the world in any service level organization. That is the model that most enterprise IT units will use. But that's also because an enterprise IT organization is going to have a lot more costs and inherent process restrictions than we do sitting in communications. 2012, we doubled the number of sites from 2011. So where we delivered 2025, we delivered well over 50 last year. We had an efficiency improvement of 40% year on year. And that was largely driven, like I said, by the strategic hire and getting me out of the way. We expanded the service offering. We now take over all the wikis and blogs for UNSW, et cetera, et cetera. We added that producer. And I say that it took six months to recover her ROI. Looking back on the numbers, I think it actually took closer to three. And we put in a deployment framework that now we can deploy simple sites in as little as 60 minutes for nothing. As long as we provision the subdomain, as quickly as we can provision the subdomain, we can basically have the site up and running at little or no cost to the client. To show you what the numbers mean, now, whoops. What you're going to see here is for 2012, basically every time we take on a project, we do two quotes. We do the agency quote. And I have seven years in digital agency. And so we run the numbers that way. And then we do the CW quotes. So where the cost recovery impacts on the big pace curve in terms of opportunity cost to the university, you will see what we delivered for roughly $420,000. It would have taken agency spend $1.2 million to achieve the same result. And that's, again, simply because I'm not charging for everything. Because I am on staff, we don't charge for my time. We do not charge for the scoping or the project definition. We do not charge for the graphic designer because she's on staff. We do not charge for the web, or if she's our web designer. We do not charge for project specifications. We do this all for free. The only thing we charge for is development. And then we have a set percentage we put on top to cover the unfunded positions. So we could just do things really, really cheap, really, really quickly. Because every conversation with me is not charging. I'm not charging you $180 an hour, or $250 an hour, like an agency would do for sets of services. We do fixed cost quoting. We don't have time sheets. So I mean, I know there are projects where we just said we've blown them out by days. But it's because we've said people aren't overwhelmed. There's been a rapid need to deploy this site. We might take over that content, ingestion, or things that we can provide services for free over and above the actual set process. So even if you add on in 20 costs the actual cost of my unit. So this is the total cost of running my unit. Even above that cost, the opportunity cost savings to UNSW for 2012 are about $675,000. So basically, we're trying to get to a position where, for every dollar you spend on the central web unit, you will save $2 in external spend. This is the business goal. Revenue over the three years of operation. We basically, first year, I think we took in about 28,000. And that was really only in the last four months. Yeah. Second year of operation, we did 198. And last year, we did 420,000. So we're seeing pretty much a steady increase. This year already, we're probably going to hit about $600,000 in gross revenue. It's just inevitable. My unit's booked out till October already. We came into the year, booked out till the end of June. It only took two weeks to fill up another few months. So as of February, so as of the start of this month, we had already confirmed 420,000 revenue. So everything we did last year, we've already achieved. So this is good for the growth of the unit, potentially. As I just said, we'll probably hit $600,000, probably more. We're already starting to get the ad hoc projects in or the longer term 2013 development requests. Ultimately, we think that if we hit our lower level target, we will save the university $1.9 million if we hit our stretch target for the year. In terms of development deployment, we'll save the university $2.5 million overall, which again translates to over the actual cost of running my unit, we'll save the university anywhere between $1.2 to $1.8 million. You know, a million here, a million there. All heads up. And that's already accounting. I've added another junior developer this year. So that's already including the increase in staff costs and the raises and everything else. And what really makes people happy is that at the end of every year, the central web unit basically kicks back its entire operational budget, non-staff, back to the unit. We're the only ones I think who do that. People think we're crazy for doing it. You know, basically we actually fund services and staff in other areas across our division. So that generates some pretty good management will. So again, just like you saw before, up to the light yellow, if we hit our lower target, the $1.9 million versus the cost of running our unit, we'll save anywhere between $1.9 and $2.5. And I covered this up before, but just to repeat, the cost recovery as we define it is not having money leave the university. And to tie this back to this conference. I mean, this was single-handedly driven by Drupal. The modular approach to Drupal, I mean, as I explain, because I deal with a lot of non-technical users, is we're developing these functional blocks, like Lego blocks. And all we need to do is sit down and figure out which Lego blocks we're going to build your house with and then paint it the color you want it. We're only able to do that because of the flexibility of Drupal, the modularity of Drupal, the fact that we're supported by thousands of Drupal developers around the world who are constantly improving the product. This year, it's my hope that we're going to give back a whole bunch as soon as we go through and have the time to catalog and figure out which ones we can give back to Drupal.org. The ease of the technology itself just took all the difficulty out because my job in running the unit is to meet with you. I like to say I'm there for the first conversation. I'm there for the last conversation. I'm behind the scenes. But the first thing I need to do in any conversation is take away all the fear. Because most of the people that we deal with are non-technical people. They've been told they have to get a website built. And that is really scary to a lot of people. But the user experience that Drupal's generated, they can go, we can show it to them in the meeting. They just go, that's so easy. They start to calm down. We can focus on the use cases that we need to hit. And of course, it's the actual revenue that I get from those conversations. And again, what happens is, as I said in the process, we used to try to run to agile as much as possible, but it didn't work. Any university, again, because we deal with non-technical people, the first thing we do is calm them down, get them a cup of tea. We talk about what their website needs to be. And in that first hour conversation, we come out of there with a functional list. So what it needs to do, we come out of there with a really rough wireframe of what needs to go where on a couple of key pages. And then we break convention, and we go straight into design. And the reason we do this is because this person has to go back and convince people more senior than themselves usually that this is what they need to do, and this is something they can show people. This is something real. They can actually see it. And it actually gives them, even at that initial stage, it gives them something to look at, and it gives them something to criticize. And we love that. Because if they're criticizing it, now they're just basically going in that direction anyway. They're just moving around the boxes. Criticism is still positive feedback in my book. And then ultimately, we scope it, and then we give them that. And I'm happy to, and also, by the way, I'm not tied to doing the work. We will pull together the designs. We will pull together the wireframes. We will do all the project management. We will pull together the technical spec. And if they want, or they don't feel comfortable with us doing it, I will assist them in managing that external quoting process. Because I speak agency, and no one can run their crap behind me, because I will call them out on it. In fact, it used to be fun, because my first year at UNSW, because I came from agency, while we were building the business, I used to get called in to help a lot of people whose projects with agencies were just going off the rails. As some projects do, let's face it. And then I got to go in the room, and they go, oh crap, dad's here. Behave. Don't do that so much anymore. So the approach. If you're going to do this, if you're in a management position, you've got to think like a business. If you're in a non-profit, it doesn't matter. Think like a business. Put the customer first. User-centered approach. Do not have big, scary technical conversations. Do not present overwhelming, weighty documents. Problem solve. You're there to help them. You're there to solve whatever problem they're having. And be aware that the problem that they're telling you is probably not the problem they have. So it's listening to that why behind the what. And focus on the administrators as much as the users. Because if you just focus on the front end, you're just going to mess with their heads on the back end. Figure out your value proposition, then build a sales pipeline around that. Pick your revenue center service. For us, Drupal Development. This is my cash cow, one of them, Jeremy. But basically, like I said, we provide everything around that single service as value add. By the time we actually get to the development part of the project, the users just feel so secure that what they're going to get is going to be something that's going to work, and it's going to be something great. Because the experience up till that has been rewarding for them, we hope. Charge only what you need to charge for. Don't go crazy. And with every conversation that I have, be open and honest. I say, look, we do work on cost recovery. And what cost recovery means for us is I do have positions that are not on staff. So we do all of this, steps A, B, C, D, E, F, G for free. We then quote on development. And then I put a little bit on top just to make sure that we are going to cover that person. And people are fine with it. You're just being, in the case of UNSW, there's a complete understanding that those undefined positions justifies that particular charge. So who you need to be? Chief coffee drinker. I need to run around, and I drink a lot of coffee. I have a lot of conversations with people. I mean, in some ways I'm the face of the unit. I'm certainly the name of the unit. And word of mouth, especially at a closed organization like a university, means everything. It's like the phrase that takes years and years and years to build a reputation, but only a minute to destroy it sort of thing. But yeah, you've got to put the people first. And that comes down into everything. The use case is everything we do. We're putting somebody before us. If you're going to try this, you've got to have a strategy. You've got to figure it out and take time. And like I said, at the beginning of joining UNSW, it took me about four months to actually realize what the actual operational circumstances were in order to do this. Yeah, in a lot of ways, I'm also the executive producer. Every project will come through me at various stages every time. The clients will never see that. I mean, I'm there to do the project definition. I'm checking that design. We will discuss certain aspects depending on the complexity of the project. And some projects, and listen, I'm not saying I interfere at these stages. I mean, I personally describe my management style as even not so much delegation as abdication. I've just hired really smart people. And I just go, look, you just figure it out. I don't even care what your solution is. Just do it. And then just put complete trust in the people that you hire. I'm not there to be prescriptive. I'm not telling a designer that the best solution is to have a dropdown box for this. You guys, complete faith in you guys. You need to be the business planner, opportunity, spotter, goalsetter, problem solver, mentor, fund maker, culture warrior, business model champion, department of finance, HR sales, and other duties as required. Yeah, for the first year, I did everything. I didn't have any people. But again, make it fun as well. Put the FU in fun. And a politician, especially at a university. You're there to fight the battles. You're there to plan the strategy. And you're there to execute. Now, in a minute, I'm going to have Jeremy final thought. We as web professionals, we are probably the most uniquely positioned individuals to drive culture change in organizations simply because everybody deals with the web, whether they're answering emails, whether they're surfing it, whether they're project planning or have to deliver it. And we as web professionals can either make that in our own capacities a hellish experience or a joyous experience for the people who've come to us for our expertise. And I've seen a significant culture shift around this at UNSW because of the fact that the face of the web is changing and the ease of the technology and just those users who have come to us. Now, before I hand over to Jeremy, who's going to take you through some sites, I thought I'd give you cream through that one. Did you guys want to have any questions about the business side of things? And then we'll move into the technical bit. No, I don't consider it an issue. I mean, my team, like I said, we're actually only, including Jeremy, who's essentially full time external, we're seven people. I go to conferences in the states, and I'm dealing with guys who are complaining at their universities who are half the size of ours that they're 30 people aren't meeting the bill. So every job we look at, we value it in, do we have the expertise to do this first and foremost? And if we don't, I have no problem going outside. I mean, I have a list of partners for mobile. I have a list of partners for certain aspects, data, especially. So if it comes down to that particular expertise, and we don't have it, I have no problem. In fact, half of my job, I mean, I'm a resource for all of you NSW if they want. I'm there to find the expertise and to give opinion. And this morning, actually, one of our units was having an issue around mobile, and he sent me the issue I forwarded on and said, you two deal direct, and I just back out. I mean, I'm not there to get in the way. As far as brand, yeah, that's an interesting one, because especially, how do I say this without singling anyone out? You do have, especially in the private sector, you have sub-brands and brands and brands and brands. And so for most people, rather than want to be resented as the overall brand, they want to be their specific brand. We've accommodated that by allowing sub-brands at UNSW, so as long as we get the overarching presence, which is the white banner and the yellow line, and then you can do whatever you want between the header and the footer. That first pixel under that yellow line to that first pixel on top of the footer is yours. Because especially, one of the challenges I had with the brand rollout initially was, it was rollout so late in the year, there was no budget. We have 350 websites that all have a different look and feel. So the first thing we instituted was a plain white banner, just because that was the only thing that was going to go with everything underneath. So that just instantly brought a lot of consistency. And then all we did was put that 10 pixel yellow line on top, and we went, yeah, we're done. But we allowed everyone to do what they wanted on the page. And brand in this case is being grandfathered in, so it only applies to sites that are being redeveloped or newly developed, because there are sites, there are conference sites in UNSW that are obscure, acronym at UNSW.edu.au, that are never going to be redeveloped, they're just going to sit there infinitely, and we'll never touch them and we'll never be money for it. So we're good with that. Did that answer your question? We can talk after if you want. Yeah. Well, yeah, yeah, oh, yeah. Yeah, well, like I said, prior to joining UNSW, I was part of an agency that UNSW was my only client. We worked on a massive project called the Research Gateway, which was basically combining four business units under one visual umbrella. We went through a year-long scoping process. And ultimately, when it came to the end, we thought it was actually, I can't remember what the other one was, but I know that up until almost the very end, we thought it was going to be Django. And then at the very end, there was a select set of business rules that changed. And because of that alteration and what we had to meet the business rules, Drupal just came up on top. Now, every project that we talk about, the first thing we do is try to define those core use cases or the core business rules that we're trying to meet. And again, now that we're three years in, I mean, we built a Django site two months ago just because that was going to be the proper thing. And because I sit under meeting communications, whereas anyone sitting in an IT enterprise is going to have a lot of process restrictions, and they're going to have a lot of cost that are just inherent with being part of the enterprise, it's not better or worse, it's just different. But then again, they have a lot more risk management than, say, my unit would have in terms of some aspects of that development. We just look at what's the best technology for the use cases and for the business case that you're trying to achieve, but now three years in, Drupal is pretty much 99% of the time. We don't have incredibly complex business requirements that we're dealing with anymore. Yep. Yeah, of course, websites are never done. Yeah, I mean, one of the things we do, I mean, we do host almost every project that we build. So we have a series of VMs and we do, well, I mean, again, sort of true to the agile methodology, we just want them to roll it out quickly and as inexpensively as possible because we know these are coming. We don't want to chew through what their operational web budget's going to be, and we want them to come back to us in four months' time, not just with the bumps and the tweaks, but saying, actually, our business process changed, or this process here isn't working. And let's, you know, let's say every six months review what's working, what's not working, or has your business change, has your online needs grown, and then let's use that bit of budget that we didn't spend before to make that enhancement. But no, actually, it's not. I think we're going to hit probably a critical mass by the end of the year. But I mean, no, if you consider that we're looking after about 90 sites at the moment, it really isn't, interestingly enough. I'm not sure why. I mean, we just went through a whole series of Drupal Core updates. But because the framework is so similar, those were achieved in about two days. And so when you've just done quadruple updates across 50 or so sites in two days, again, it's the scalability and the deployment framework of Drupal that we just, it's just easy. Anything else? Yep. I don't conduct training, but you could certainly email. But no, essentially it is. Because the deployment framework on the back end is so similar, I mean, basically every manual I write is almost the same as well. So there's efficiencies to it being there. But it was just one of those things where the site wasn't too complex. I think the site owner wasn't just oblivious to technology, had a bit of technological understanding and a bit of savvy. And literally, we booked the thing for an hour, and my guy was back in 15 minutes. And he just said, 13 minutes, new record. So just lights go on. And some take longer, because I mean, our job is to make sure that they understand it as much as possible. But getting back to your previous question, I think the most resource-intensive time for us is when we do hand over a site. Because of course, we come in, we test it, and we try to use their actual content, even though we don't really want to take responsibility for content. The training session involves going to users and having them put in their content. But then you get the thing where you get the email going, everything's gone. OK, what do you mean? Oh, everything is gone. Let's just revert that. But no, and you do get the little bit. And then the three days after the fact, they're going, oh yeah, we would like a Twitter feed. And you go, OK, let's just wait. Do you have one now? No. OK, well, you're probably not really going to populate that straight away. Let's just get you betting this down first, and then we'll introduce complexity at your second iteration. Anything else? Yep, Peter. That's a question for Brian. Jess, do you have anything on that? Anything else on the business before I hand it over to Jeremy? OK, great. Thanks. Remember to de-mic first. We pulled out with a little new development as much reuse as possible, really. So for example, this is the new unsw.edu.au main site that we rolled out, I believe it was about a year and a half ago. And so there are a lot of elements that we pretty much just copy and paste between our basic sites. Like, for example, the search in the top right, search this website, search all unsw websites. We've got a module in our reusable module library for that. Further down the page, we've got, per the unis legal requirements, we need to show on the bottom of every page, page last updated. We've got a module to stick that in the footer. We've got a lot of that stuff implemented in features. A lot of the other modules, they're basically just no more than copy and paste is needed, not much config involved. A lot of the theme elements for the main nav menus, for the sub-nav, for different sections, gets reused. We make heavy use of carousels on most of our sites and most of them share a lot of design. I was going to talk about some of the more interesting sites we've done as well. For example, the research gateway, which was the first and really the biggest Drupal site still that we've got at the uni, which is more than just a standard school of this institute for blah, blah, blah site. It has a profile database with more than 2,000 researchers and academics at the university. We're pulling in data from some of the other UNSW custom databases, like the HR database and the Publications database, using combination of the Migrate module and various scripts to do that. This site was also recently upgraded from Drupal 6 to Drupal 7, which was a pretty big job. It's got a lot of content, regular node content, and a lot of custom data in there as well. Makes pretty heavy use of admin moderation features on the back end. Content scheduling, content expiry, a two or three step moderation approval process for content changes. So that was definitely one of the more involved sites we developed. As an example of some more of the day-to-day sites we did, sorry I don't have the screenshots here, but the School of Psychology website shares a lot in common with our main site. We recently redid the UNSW Facilities Management website, working on a new School of Chemistry website, which will be rolled out soon. One of the more interesting sites that we launched last year was the UNSW Open Day website. And we made that a little bit more fun and interesting, has a lot of Facebook integration. Users are able to log into the site via Facebook. Their Facebook profile photo then appears within a block on the page saying, who do you want to be when you grow up? And lets them construct a little picture on the site of the profession they want to be with their photo in it. And that picture that's then gets screen grabbed and they're able to post that directly to their wall on Facebook and share it. So that was one of the more fun, interactive things we did. So yeah, this is not a technical talk as such. Just wanted to give some quick examples of some of the recent Drupal work we've done. So yeah, I hope I didn't speed through it all too fast. And yeah, basically that's all I wanted to share with you. So if you have any questions about these examples or about the technical side of how we do Drupal at the uni, now's the time. Yeah, up the back. For most of the sites, yes. Some of them, specifically, faculty of medicine has a lot of sites. And they've set up a special shared code base and sharing a lot of tables within a single database as well. In general, it's not feasible for us to do that, mainly for procedural reasons, different schools and faculties wanting at least some level of separation between environments from other units. Yeah, look, we do automated fair bit of Drupal upgrades across sites. And yeah, we end up reusing quite a lot of code across sites. And we have several shared staging production environments as well. Like I said, the faculty of medicine is our main multi-site. We're also working on a new multi-site rollout for a going to be our research center's sites hub. And what we're hoping to do is get something like an aga set up if you're familiar with that kind of turnkey hosted Drupal stuff. We're hoping to get a large number of research lab and research institute sites running on one shared Drupal code base and allow new sites to be created with like one click create and install using multiple code bases or multi-site. Well, I mean, main benefit is Drupal upgrades, particularly security upgrades, can be rolled out quicker. In my experience, it's a bit of a 50-50 situation in terms of the ease versus increased complexities of sharing database tables and sharing themes and modules across sites. Yep, heard that covers it. Yes. We have a different theme for each site we build. Yeah, well, our designer does give us a new design for each site. A lot of design elements are very similar and are basically reused across sites. But yeah, I mean, we change icons. We change layout. We change colors to match specific school, laboratory, brand guidelines across sites. Yeah, at the end of the day, in our use cases, we decided it's not worth the effort trying to keep bending a single theme to work with multiple sites.