 Okay. Hello everybody. My name's Scott. Thank you. That's what I was looking for. Hi, Scott. So yeah, I'm going to talk with you today about some of the customizations that we have implemented at NC State with our Moodle implementation. A little bit about me just as an introduction. I lead the instructional technology support group within a group called Delta at NC State. Delta is distance learning and learning technology applications. Sorry, distance education and learning technology applications. That would be the correct acronym. And at NC State, the distance ed group and the learning technologies group are merged into this one unit. My role there in relation to Moodle is I do a variety of things. One is that I oversee our LearnTech help desk, which is our help desk for faculty. It's the primary service point for faculty who need assistance with Moodle and with any of our supported technologies at NC State. And I also participate in several of our Wolfware governance committees. Best practices and support, the implementation team and the strategy team. So I have a variety of roles that I play in relation to Moodle. And my reason for telling you all of these different aspects of my role is that I want to also tell you the aspects of my role, the aspects of Moodle that I don't do primarily. And that's do the developing and coding and that sort of thing. So some of the examples I'm going to show you, I'll be happy to take questions on and comment on. But if it gets too deep or technical, I'll probably want to talk to you after the session and hook you up with the people who can answer the questions more effectively than I can. A quick snapshot of Moodle at NC State. We're on Moodle 286. We just moved to 28 in May of this year fully. We kind of do a sort of a phased migration in the spring. So it went into full production in May of this year from 26 to 28. And our usage stats there, that's just kind of a year, an academic year snapshot of the number of course sections. We're creeping up on 4,000 a semester. Enrollments are up maxed out at 120,000 and that's about 30,000 unique students. So that's kind of the scope of our installation. So with that many users, we have to think about how we customize Moodle. I mean, one of the great things about Moodle as we all know is that it's flexible and customizable. But when you have a bunch of users who are expecting it to do certain things in certain ways, you have to be careful about what you change. Again, I'm coming from a support perspective, so that's my take on it. If we were to ask some of the technical folks in our shop, I'm sure they would say there are other reasons to be careful about customizing Moodle, moving away from the core code and that sort of thing. But my perspective again is support. So the main sources of why we customize what we do is based on one user feedback. And I was glad to see Martin mention feedback as a component of development in the talk earlier this morning. We have various channels for user feedback that we try to herd comments and suggestions into. I and some of my colleagues will be giving some other talks on Thursday about getting feedback in particular, so I won't go into details here about that. In addition to user feedback, we also have a program at NC State called Delta Grants, which is a grant program in which faculty can apply. It's a competitive program each year and faculty can be awarded either money or they can be awarded development time from one of our staff, instructional designers, media developers, to help them create Moodle courses and Moodle course content. So some of the customizations that we've done have grown out of projects where we were enhancing or improving or evolving certain classes and we found ways to do it that was scalable that we could apply to many classes. And so some of the customizations grew out of that. So I'm going to go through a few examples. A couple of them I'll just hit pretty quickly and then go into more detail about some of the others. First of all, we make lots of little usability tweaks all the time and I just put it here not because it's a big thing but it's just something that goes on all the time in our installation of Moodle. We get suggestions and comments from users. I myself generate comments for the developers. Just things like, well, why are these buttons arranged like this? Why don't we arrange them like that because it fits the interface better or theme related issues or the order of settings on a settings page. We're finding things all the time that we think, well, this would be, we could improve this and so there are lots of little usability tweaks happening all the time. We also have SIS integration and we also have a grade submit tool that works a little differently I think than the one that Nancy talked about. We have our Wolfware system is sort of our umbrella over all of our learning technologies and Moodle is the biggest one under there but Wolfware is where we have kind of extracted some of the Moodle features out to another layer. So for faculty to request a course or add a TA to a course or change the course theme for example, they would do that in the Wolfware system as opposed to the Moodle system and grade submit is another one like that. So at the end of the semester, the professor would log into Wolfware and the course total column from their Moodle gradebook would be automatically populated to our SIS system through a tool we have in Wolfware. We use PeopleSoft if I'm not mistaken rather than Banner but that's another sort of SIS tweak that we've done. So I'm going to go into more detail about the other ones that are here and give you a little bit of background and examples of what we've done here. I'm going to talk about some course theme packages, a resource called the NCSU book, the NCSU grader report and then I'm going to touch on the gamification module as well. So course themes or course theme packages really. This is an example of one that grew out of the grant program that I was talking about. For well going back to kind of pre-LMS sort of days, faculty used to in creating their course website. They would create a website, you know, they'd learn how to use Dreamweaver sort of and they would create a website sort of and one of the things that they like to do was have their custom banner across the top that they made in fireworks or whatever. So as the LMS kind of became more and more broadly applied, a lot of them still wanted to do that kind of thing. They wanted to have that sort of customizability and but we wanted still to have courses that were rational and not really horrible looking at the same time. So the instructional designers in our group found that they were doing the same kind of work across a lot of different courses where people wanted certain designs and they wanted a banner and that sort of thing. Eventually we looked at all of these different themes that we created for these different courses and created a set of them and then applied them again to our Wolfware system where when the faculty is faculty members going in to request their course and choose their theme, they've got a list of several, a couple dozen different themes that they can choose from. It's all primarily look and feel so you can see the, you know, just some examples that I pulled from different colleges. Some of them are branded with colleges, some are branded with the university and then in addition to that, there is also a set of them that doesn't have any branding in the top bar but it's just sort of color, there's a color scheme to the theme in general and if a faculty member is using one of the personalized themes then they're able to upload their own custom banner that they've created or that someone's created for them in their course. So right now we're sort of looking at these themes and trying to figure out how to move forward with them. Over time they've been kind of hard to maintain. I should also mention that associated with the themes are document templates so that if you download or if you use a certain theme rather you can download a set of documents, you can download a PDF template and a PowerPoint template and things like that so that if you're presenting content in your course it matches the look and feel of the course itself. Right now we're looking at trying to figure out how to manage a smaller number of these and we're also looking at ways to handle change better over time with these themes. Colleges change names, we've had that happen a couple of times. Right now there's a pretty big branding effort at the university level so it might be that the university might want more NC State branded stuff as opposed to college branded stuff, things like that. The NCSU book is a resource that replaces in our instance the default book resource and there's just the screenshot of the activity chooser there with the NCSU book in it. Basically this is another one that came about from individual instructional designers working on individual courses for faculty and the tool that they were using much of the time to organize content in courses was the book tool in Moodle and they started to see the limitations with the book tool and they wanted something a little bit more robust and so after creating a bunch of books and a bunch of courses we said why don't we create a book tool that we could use to provide sort of a template for this kind of content creation. It's basically it works the same way as a book, there's a table of contents and there's a content panel pane. In addition there are multiple page types and there are call out boxes that you can highlight different materials, different content and then there are sort of different section indicators as well. So the NCSU book it has the table of contents over on the left and it has the content over on the right. In addition you can see that there is a learning objectives box over there on the right that is sort of a call out box that you can define. If I go to a different page there are some sort of screenshots of the different pages there's an introduction page, there's a page designed specifically for learning objectives, there's the basic page which is just sort of a basic page of content, a different page that can be used for assignments and for the summary and so the idea is that with a content module you use these different pages to sort of visually reflect what the flow of the lesson is. The other cool thing about the NCSU book is that when you are using one of the course themes the book restyles itself to match the course theme. So here the red sort of heading behind create your book is a reflection of the red in the banner and all the different themes and books work that way. So the next thing I will talk about is the NCSU grader report. This is an alternate grader report grade book view that we developed. I think that work started on this back when we were still on Moodle 2.3 but we launched it around a year ago when we were on Moodle 2.6 and the main features of this grader report are locked column and row headers on the grader report and scrolling that goes both up and down and left and right. I don't have a live example of this but here's a screenshot and basically we were getting suggestions from faculty who had large classes that their grader report was unmanageable, that they couldn't scroll up and down and they would forget what column they're in and that sort of thing. We would suggest well break it up into pages and only put a certain number on a page and then they would come back with well now I can't search for a particular student because I can't do the control F the way I used to. So anyway the NCSU grader report keeps the entire report on one screen allows you to scroll in both directions and locks the header column and header row. I think that we just to be fair I think some of the developments in Moodle since we put this out have kind of relieved some of the pressure that we were feeling on the help desk from from the previous versions of the grade book that we had. And so next I would like to talk about the gamification module. This is one that I think is very cool. It is a plug in that allows for gamified type activities within a Moodle course. It creates some of the features of it are that it creates gamification blocks. There's sort of a main block that you manage the gamification elements in as well as other blocks that can be displayed on the screen like a leaderboard block things like that. The module enables leaderboards enables points that can be awarded in a course as well as point sets. So the points can be you can have different groups of points and students can earn different points in different areas. You can set up game objectives and rewards. The student must do this sort of thing in order to get the reward and all of it is pretty customizable and configurable. And it uses existing features in the grade book like activity completion conditional activities you can say if you know if a student must complete this in order to get this game reward or a student must achieve this in the game in order to release some other content in the course. It can report a grade to the grade book and it can be tied to events in the course log as well as as far as triggers for game events. This is something that you can find out more about on Thursday one of my colleagues who is the primary developer of this is going to be presenting on this specifically. So it's a it's a pretty cool thing. It's been used in a couple of individual courses as part of grant projects and right now we are looking at how to how to release this how to make this scalable to other courses. And the problem is not the module itself. The problem is how do you tell somebody how to do the thinking work that would be required to set up a gamified system within a course. It's easy enough to go in and create points and create badges and things like that. But how do you do that well in a course and how do you do that in a way that makes sense is one of the more difficult questions. I think in my support and training role it's often a case of somebody coming in to take a workshop or something. I teach them something and they leave knowing how to do it. And I think it's going to be harder with the gamification module to do that. I don't think that it's going to be as quick and easy as people think. And in the work that's been done on the in the courses where it's been implemented. I know that hours and hours and hours went into planning the structure of the game elements and what students have to do to earn what rewards it's really it can be a really complex process. But I encourage you to check that presentation out if you would like to on Thursday. Here's a list of the other talks that NC State folks are doing here at the moot. The gamification one is listed there and then myself and a colleague are going to be presenting on how we gather feedback, our feature request system, how we address best practices and support. And then Marty Delberg will be talking about our overall governance structure at NC State and how we manage our deployment of Moodle in general. So that is what I have to tell you be happy to answer any questions that you have. I'd also be happy to connect with anybody on Twitter. I'm trying to build my learning network. So if anybody wants to connect with me up there, please feel free and I'll follow you back. Some of the smaller tweaks you're making that aren't modules. Are you making those to the core and how do you manage the source code when you upgrade? Yeah, we're not making them to the core. I mean, we have a like I said, we're on a yearly upgrade cycle. So part of that planning process is to look, you know, select the version that we're going to upgrade to whether it's the most recent version or the one before it or whatever the decision is made and then look and see look at our changes that we've made previously and make sure that all those get moved over to the new version. But it's not, you know, we don't have sort of an alternate version of core that we use or anything. It's a matter of going through and making those adjustments with the upgrade. When you do your yearly upgrade, do you do an in place upgrade or do you spin up a new instance? We spin up a new instance. So you have that for each academic year? Yeah, it's we have we made the decision a couple years ago, like three years ago or so that we have a different Moodle server for each year, each academic year. So the courses remain on that server for that year. But but our Wolfware system is the system that students and faculty use to get to the courses. So it links to the correct server regardless of what year it is. So the faculty can go in and say, Oh, give me my course from two years ago. And that's the course that that's the Moodle server that's linked to in the Wolfware system. So it's a it's a bit of a learning curve, I guess, to try to train people to go, don't go to Moodle for your courses, go to this other thing where it will be correctly linked. Sometimes there are cases where it's a new semester and somebody's trying to go to the old server and they say, I can't find my course. Well, that's because we've you know, started a new a new server. So yeah, right now it's once a year and we're basically upgrading once a year to with a with a new instance of Moodle. We're doing the same thing. And been doing it for about as long. We go we keep data back about five years, but we started we stopped doing in place upgrades and went to this annual academic year kind of model on the even numbered instances of Moodle about three years ago. And we built something we call a kiosk so that they can go into any of the Moodle instances linked to any courses that they have access to in any of the instances. But we've had some issues with the fact that the older years are running on older versions of Moodle. And they're not kept. We're not getting security updates and whatnot. So we're having to do some back patching and and the really old ones putting them behind a firewall. So might be curious to talk to you about that. Yeah, or I could point you to my one of my colleagues who could probably answer the question better than than I can related to the technical aspects of it. Great. Yeah, there are some other things like we haven't. We don't migrate profiles over Moodle profiles. So because it's a new server that sort of resets the blank every every time we upgrade the. Yeah, I'm not sure what our security policy is for older servers. I mean, obviously we'd keep them as patched as they can be kept. But I don't think we put any extra restrictions on them. We make them read only after a certain time so they can't be changed. They can still be accessed, though. And then our retention policy is four years, which is in line with the university's policy. Right, helpful for keeping the data. Thank you.