 Well, welcome and greetings, everyone. Thanks for attending our session this afternoon. I know there are many other pretty awesome sessions that you can choose, so we really appreciate you taking your time to come to our session. So let's make sure that you are attending the right one this afternoon. If you're now getting into Drupal or doing a fact-finding mission, to see if Drupal is the one for you, then you're in the right place, you're not going to get too technical this afternoon. And now if you're here because one of my team members said that we were raffling around trip, take it to Jamaica, then you feel free to leave right now and I do apologize on the other half. So our chat today is about the ongoing journey taken by the four main campuses of the University of New West Indies to migrate our web platforms to Drupal. So to help me along this journey, I have on stage with me the webmasters from University Center, Drupal Dali, Mona Campus Jamaica, Ruhenshaw, the Open Campus, Richard Bhatt, and myself, Darren Dorey, representing the Center Casting Campus from Trinidad and Tobago. So this map should give you a good idea of where we are and how we are distributed across the Caribbean. As you can tell, you can see the main campus of 17 countries, Trinidad and Tobago, Barbados, and Jamaica. And we were also distributed across 17 countries in the Caribbean. So we're responsible for ensuring the online presence across this reach of campuses. So our geographic stretch does provide some challenges in trying to represent ourselves as one university instead of four campuses serving 17 countries. So while we're working towards seamless staff and student mobility, moving from one campus to the next, and also offering an extensive selection of online courses, the web teams also face a challenge of presenting ourselves as one face to the rest of the world. So in the past, each of the four main campuses has implemented a CMS that fits their skills and needs, their budgets, and you can see from the example being shown. So now our strategic plan, once we represent ourselves as one university, so we must shift gears a bit to come up with a solution that will take us from here to here. So to start you on this journey that we embarked on and to discuss the challenges that we faced along the way, I'm going to introduce Mr. Richard Bart from the Open Campus who will lead you on the discussion. Thank you, Darren. So like Darren said, it's a tough job but someone's got to do it clearly. So let us look at some of the challenges we faced as a university prior to us embarking on our Drupal journey, maintain a consistent brand identity. As you have seen from the previous slide, we are an organization that is somewhat splintered throughout the Caribbean but we have to ensure that our strategic objective of the university which is to present a unified front is maintained. This has been problematic over the years. Even though we have a single web template, each campus has a different adaptation of that design based on the web platforms that exist at each campus. Over time, various CSS styles, scripting languages are employed, resulting in consistent navigation and a poor user experience. If anyone is here from an IA head institution, probably you know about enterprise system called Banner which is a student management system. Now, I'll give an example of a problem that we have in sharing resources. So my colleague from the Mono campus would have developed an application to interact with the Banner software which would pull information then repopulate on the website. Now sadly due to the fact that we were different web platforms, we're unable to share this module and the resulting experience that would have been gone up. Keeping up with the Joneses, sorry. Yeah, I made this error this morning as well. So collectively, we have to address the needs of over 600 websites and this number is growing rapidly. Keeping up with the request proved to be very challenging, particularly with keeping in line with one of the university's strategic objectives of going green, essentially going, sorry, going online. Lastly, the explosion of social media across the university. We have had requests for integration into many websites with no easy one click integration or installation of any automated integration modules on existing web platforms. This proved to be very difficult and time consuming. Security, access and authentication. Working with our homegrown systems and trying to integrate with proprietary software that each campus runs, you'll find we will always be doing patches and trying to defend against attacks, right? We're also challenging with two factor authentication. When you have 300 VPN users and you're using a USB E20 token for two factor authentication, this proved to be very costly. And of course, in these economic times, that's a challenge. And of course, olds and flaws. Now, there's so much and no more, the limited staff of the webmasters can do to stop attacks due to olds and flaws. But when you have a wide community of users sharing and helping to identify these flaws, it's much easier. Money, money, money. So it costs a lot to manage these proprietary systems. We think about the cost to install them. We think about annual licensing fee, upgrade license and multiple support contracts. And with budget cuts being done each year, we have to find solutions to these problems. And so I'll introduce Ron to speak on how Drupal became a rising star. Thank you, Richard. So in about 2006, 2007, we started researching a CMS solution and we were getting a lot of pressure in terms of delivering designs, updating content. We had calls from registrar, the marketing department, the principal wanting to get things done just faster and we needed it to be more efficient. And while we try to explain some of the technicalities, I mean, they're not technical users. They just didn't care. Just wanted more, quicker, faster and better quality. So in Jamaica, we had a few red stripe bears, by the beach, a few sunsets. We discussed it. We looked at the different solutions. We came up with a short list. It encompassed Drupal, Joomla and WordPress. We looked at the costs, ease of use, frequency of updates, popularity, like, I mean, which sites used it, amount of modules and themes that were available. Best suited for what type of solution, whether it's a small or a large scale. Also, if it were only a web development tool or framework, could it do more than just building websites? Could it really do apps, stuff like that? I mean, current skillsetting house and how easy it is to train our current staff to get them comfortable with the technology and to use it efficiently so that we can deliver the products or the services that we need to deliver. So all this was taken into consideration. And the cost, of course, was a big factor. And I mean, we had to, we were using a system where we had to install desktop clients for them to do their coding in and then update and stuff. And then we had to train these persons. So it just really wasn't working out. It was a lot to manage. So we wanted something that was a lot more seamless, a lot easier, would reduce the costs. So we looked at these in-depth. So we looked at, we came out, well, Drupal came out on top, needless to say. I mean, it had all the benefits up or wanted, but could remove the yearly or monthly fee for the licensing for the product on the desktop side, as well as somewhat on the server side as we were looking at a solution where we'd install it on the server and the clients would kind of push and sync up the content or the changes from the different department users. So with Drupal, it was browser-based. So I mean, right there, we cut all of those client licenses immediately and we had over 600 websites across all the campuses. So it was a big cut. I mean, it was significant. This was really huge. And we just had to make that decision. It took a lot of retraining to get there, but we decided that this is what we had to do if we really wanted to go forward and wanted to be efficient. The pressures from senior management was just a little bit too much to bear. So we wanted something that was flexible and dynamic that could respond. In our environment, more or less all the departments would deliver the same kind of product, but probably in terms of like courses, but just a little bit different. So chemistry would offer chemistry courses, physics would offer physics courses, biotech, but the process to do it is pretty much the same. The process to get information on the website is the same. It does have a different look and feel, a different name, more or less, for the most part. So what we did was, okay, we said that this could work easily. I mean, we can use the content type and better get a custom content type and reuse it across the different sites. So that would help us significantly. We have the similar code base to deliver a different look and feel. So we'd theme it differently. Everybody wants their thing to look different. They don't really care about what's on the line. The functionality's gonna be the same, but it needs to look different. Physics need to look like, physics need to say whether it's electrons jumping from this to that side, the electromagnetic field and stuff like that. Chemistry wanted to have that feel of the molecules and stuff like that. So a different look could be the same chassis under the bottom. It doesn't matter, but a different look. That's what was key in their mind. So this worked for us perfectly. Build it once, reuse it, reuse it, reuse it. This was perfect. I mean, we didn't have a challenge with that. So it worked. We didn't have to reinvent the wheel with us. Replicate and say, okay, we'll have it here once. Probably a few tweaks here and there will spin up a new site for a different department. But for the most part, it was very, very flexible. The custom teams, modules, installation profiles allowed us to spin up a site very, very quickly. We could pretty much have our fingers spin up something for a new department. We've got a new request. One of the things that we did, we sent out a client worksheet for the department to fill out when they requested a new website. So it could kind of get an idea of what it is that they want. And this client worksheet would ask them about some, some intricacies of what they want, when they want it, what kind of look and figure they're looking for. So just some sites that they might like. We'll take a look at those sites and say, okay, we can probably pull these elements from the site, put it together when we are rebuilding it. The graphic artist or the designer would take it into consideration and give them a design that they like. The theme would come in and implement it on top of Drupal after we spin up the site and that would work for us. So extensive module library. That was awesome. Web forms, polls, shopping, the backup and migrate. The backup and migrate helped significantly. And we did some training with Lollabot in Rhode Island that was probably like, well, probably five years ago. And I saw Jeff Robbins yesterday. And I was surprised. He remembered me from the training. I hope I wasn't giving him too much trouble. But it was really good. And it helped us a lot. We met the guy from the Drosh and he showed us what we could use to back it up and so we could move from development to production and back from production. Because sometimes the sites get out of things. So you have to take the production and carry it back into development. Do whatever you're doing with it, rework it and then carry it back over to production. And this helped us significantly. Saved us out of time because before that, the process was tedious. That was something that was really tedious. So that helped us a lot. That visit to Roda and look at some training was a weaker training from Lollabot. It was really cool. And this is what the IT worker typically looks like. Overwork, underpaid, short staff, repetitive tasks. And one of the tasks that you just can't get away from is answering the phone. My boss is always on me to answer the phone. I tell him to come by my desk. That's a lot easier. If I take the calls, I can't get any work done. We all know this. So it goes without saying. So it was answering the phone. Most of the time when you get the work done is at it. After hours, pretty much after the work, they are if you're coming very, very early. But of course, they get calls about all kinds of things and they want you to go to meetings to talk about stones and whatever else stuff they want to talk about. So flexible workflow. Now, this is what we have. You create a content, review the content, get the content published. Straight out of the box, Drupal worked seamlessly. It was a perfect fit. In all set up, we have what we call department publishers. They create the content for the most part. The head of department will review the content. And at our university, the head of department is responsible for whatever content goes out for that department. So he or she takes responsibility just for that content. If something is wrong, she's responsible. He or she can also have a designate for publishing. So they'll review and publish. If not, then the head of department is responsible for doing that. And it was pretty easy. As I said, it's a perfect fit. It worked. We didn't have to do much on the workflow side to get this working. Content type and views. No, I spoke about content type earlier. So we'll go back to the same scenario. Yeah, of course. Of course, there's a name, a certain amount of credits, a lecture, the location, which faculty belongs or which program belongs to. So we use this. This helped us significantly. We could reuse it. And then what we're able to do, we're able to put views on top of that. So when we were creating our program database, you could put views on top of that and pull the courses by departments or by faculty or by lecturer. So that was pretty easy. We didn't have to rewrite any queries or any stuff like that. It was pretty easy. Didn't have to do any coding really to get that done. Put in the content, use your views on top. And that worked. So that was a significant help. It helped us to be more efficient. It would deliver a lot faster. For scalability, we're talking about moving over all our sites to Drupal. As I said earlier, we have 600 department sites. We decided to use the multi-site solution. Back then, I mean, that was pretty much more or less probably the only solution or one of the better solutions that were available at that point in time. No, you probably have another solution you could really look at. But that worked for us pretty well. We could, as I said, spin up the sites pretty easy. We can manage them differently on the same code base. So when you're doing installs and stuff like that, that is easy to manage. So we did some exploration, spent some time on this, figured out how to get it to work. It went well. A few tweaks here and there. And you could scale too much, whatever you need. Recently, we employed Varnish, which is our reverse proxy. It has somewhat of a caching ability so that gives us performance. And we needed that. Don't want the site to be loading too slow. So, and also some caching within Drupal itself. So that helped us to really scale and have the thing grow easily without much challenges. End users, they were a problem. When we were, before we went to Drupal, we had to train them. Not many of them like writing HTML code. That was not in their job description. They couldn't figure why they should come to the training. If you try to teach somebody HTML that is not interested in any kind of coding and only come to sit in the training because the boss say it must go, it doesn't work. And that was just like a dead end. With this, it's browser-based. So they have to learn anything much extra. It was pretty much cut and paste and click here, click this checkbox, click this button. Bam, you get a page with all your course information. Easy, no coding. So, this worked for us for the end user. Yeah, I mean, almost no specialized training, pretty much just know how to use a browser and not to send an email and that would be good for you. And so it was just made for the end user. Now, this allowed us to do some real IT work. I mean, we could sit by the beach, have a few beers. This cost real matters that really impacted the university. And have some fun, get real IT work done. I'll now hand over to Mr. Darval Dalle who will take you through the rest of the presentation. All right, thanks much, Rohan. Now, we're still on how Drupal assisted us in achieving the one UI concept. So branding and design. Our marketing and legal teams, they are big on branding and maintaining a consistent brand identity. Now, Drupal's theming and templating system allowed us to maintain a systematic and consistent brand across all our sites, over 600 sites, while at the same time not compromising on uniqueness and usability, thus achieving what the legal and marketing team wanted, maintaining a unique brand identity. Now, another aspect of brand identity is our domain namespace, which is UA.edu. Now, currently, UA.edu is prefixed by the respective campuses. So the campus in Jamaica is identified by Mona.UA.edu. The campus in Trinidad is identified by SDA.UA.edu. So a challenge that was faced was maintaining a consistent web address with the UA brand while pulling content from multiple servers. So as you can see in the diagram, we are pulling content from, for example, two servers, MySpot and Web Apps 3. Now, that is what the user would normally see in their address bar. And as you can agree, that doesn't do much for branding. So how did we go around that? We used Varnish alongside Drupal to present a uniformed naming convention to the user. So regardless of whatever server they is serving up the content to the end user, all the user would see is Mona.UA.edu. In the case of SDA.edu.edu slash content, or in St. Augustine's case, SDA.UA.edu slash content. Now, security and authentication. The standard method of authentication on the campuses is authentication via LDAP. And we realized that Drupal was able to integrate seamlessly with this. Rather than creating new users, new accounts, we just allowed the users to authenticate via LDAP. And the beauty about that is that if a member of staff no longer works with the university, immediately their account becomes disabled. So we don't have to worry about revoking privileges and permissions. And if an added layer of security was needed for a particular application, we could use two-factor authentication. And so far we're using Google Authenticate and that again integrates seamlessly with our current setup. Now, at the university, we are very concerned about security. And one of the things that we were looking at when we were evaluating CMSs, we wanted a system that would provide timely updates and security patches. And again, Drupal stood out. And early out, we found that patching and all security issues were handled by Drupal's dedicated security team. And so far, they have just been awesome. And I recommend that if any site administrator is here who hasn't yet signed up for the security newsletter that you should do so. Enterprise integration. Now, as a university, we had certain enterprise systems already in-house and we never wanted to duplicate the content. So we wanted a system that was pluggable, that we could use to integrate with these enterprise systems. So for example, we needed information for our students on program and course information. So we created a module that would integrate with Bono to show the program and course information to our end users, which were our students. And our online staff directory pulls information directly from PeopleSoft. Our help desk, we also created custom emails using web forms and embedded code to automatically create help desk tickets. This interface with Manage Engine help desk software. Extensive support. Now, as Dries said in the keynote earlier this morning, the strength of Drupal lies within the community, the users, us. And our experience so far has just been wonderful. Support is readily available if needed, both paid support and free community support. And as a university, we've utilized both forms and it has just been awesome. And again, I recommend to us users here that many times we feel as if we cannot answer something on the andrupal.org but it goes a far way and each person, we add something to the community. So I'll now turn back over to Darren who will wrap up. Thanks, Drupal. So where are we now? Well, our roadmap looks like this. At the time of initiating into this project, we decided to go with Drupal 7. And that's really because of compatibility issues and the experience that we had on campus. So obviously, upgrades will be expected as you move towards Drupal 8 and it'll happen in a similar fashion. Now our monocampus was chosen to be the lead campus as they were the most advanced in the group with Drupal. So they developed what we call a starter pack and that was handed down to the other campuses and provided training as to how to go about installing the starter pack. So now all the other campuses, we were at various stages of customize and install phase as you can see there. And we were all hoping to launch pretty soon. But that didn't stop us from being here today. So we'll be presenting at DrupalCon. Now it's all planned at the end of this process to develop a distribution pack specifically for universities. That way we can give back to the community. And some of the other modules that we've developed as well, we wanna have those available. Some modules that can speak directly to Banner or to be able to store and so on. So that's it folks. As we say in Trinidad, party done. Thanks. You've been a wonderful audience. We have the website address of all campuses there and please do take your time to evaluate our session. Let us know what we could do better if ever we come back to present to you again. So I guess if the floor is open, if anyone has any questions at all, I'll simply answer what we had to say. If you do so, you can come up to the mic so that the questions could be recorded. Thanks again. No questions? So in case you were wondering, that picture depicts our carnival in Trinidad and Tobago. And it's once a year. It's in February next year, so feel free to come down. Are there any folks from two or three institutions in the audience? No? Education sector? Okay. Well, excellent. I wish I had a prize, sorry. In terms of publishing the content? Yes. Yeah, sure. Ron, you wanna take that question? Yes. For the most part, it is the same. We have each department to identify a department publisher. That person just wants to put in a content, making minor updates. One of the things that we don't allow them to do is the theming. Although we probably have one department that will kind of allow them some flexibility in theming. And that's simply because marketing have certain guidelines for branding and how they wanna think to look. Certain elements must be certain location. So we don't allow them to do the theming themselves. But in terms of the workflow, yeah, to create the content, the head of department reviews it, and then says it's approved for publishing or they themselves publish it. But for the most part, yes. And then again, how many themes? The themes don't vary that much. What we do, we break it up into, we have administrative theme, academic, and then we have a different theme for the top-level pages, which would be the first page I hit when I get there, and probably two or three clicks down. So the faculty would have a specific theme that the academic department, administrative department. Some schools, the school or business, they're gonna get their own theme. So I would say probably we're gonna end up with probably six or seven right now, but we're gonna group them and categorize them. So different categories have different themes and different things apply. Anyone else, any more questions? I wanted to also add that each department is able to customize their theme and their themes. For example, each department has a different color. So there will be different color codes and menu placements. So we allow some flexibility with that. Well, if there are no more questions, thank you for coming. As Darren said, kind of an entry that is in February. We're also kind of in Jamaica. That's in just after Easter, whenever Easter falls, it's the week after. So thanks again, thank you very much. Have a good day.