 We're good Yes, I'm Jeremy Schweitzer. I'm the director of customer solutions for ethink education, and I'm Courtney Bentley I'm the VP of services here at ethink education and Obviously, I can't operate the technology Maybe nope Oh, there it goes So our title said Moodle magic and really it's more sleight of hand that we're talking about You know, most of you are probably You're running Moodle installations We know that many of you run multiple Moodle installations because you may have multiple audiences That you are trying to reach More and more we are hearing needs around the need to target information to particular users particular groups of users Really trying to personalize the experience. We know that you know This is one of the things that Martin talked about in the keynote is reaching users all over the world And so that need for personalization Is a really big key to what we're hearing many of our clients need So I'm gonna actually walk you through a Few of our examples. I thought Jeremy was gonna talk about my fake tendency, so I'll jump in before he moves forward I always refer to this as fake tendency. So what we're gonna talk about today briefly is The way that we have been working with some of our clients The ways that we've been working with some of our clients in order to organize their sites In order to really leverage both core tools and some plugins In order to do that sleight of hand So Jeremy's gonna talk you through a couple of examples and I'm a walk-and-talker, so I'm gonna walk a little bit So one of the examples is really that idea of targeting different locations So the example we have on the screen is showing you to it's an area education Association those go by a lot of different names and a lot of different locations But the idea is that they have a lot of different locations that they're all trying to target in slightly different ways Different courses that they're showing Different resources that they're highlighting and so what we've really done is set it up so that when anyone logs in They're seeing only the information for their particular location So it's a little bit hard to see maybe on the screen but when these users log in we did an example from the chief Lesh I If I've buggered that in anyone knows that I apologize and the baits locations for this particular one There we go. It is the clicker now. I know how it works this particular example is a kind of Student support program that's really designed around cohorts that are based year by year So they have a year one cohort a year two cohort a year three cohort And really what they have done is they are dynamically creating those cohorts Enrolling people into a cohort and then have a front page that is customized to pull in HTML blocks and other types of information That are specific to certain cohorts So from an administrator perspective the page maybe is a little difficult to look at but from the end users They're seeing only the information resources blocks that are really important for them and Then this is an example of a client of ours that is doing end user training around products So each one of their clients they want to be able to log into a single Moodle instance So they can share their courses across all those clients, but have a different tailored experience So what they're really doing is using those cohort blocks to do every single one of their clients has their own block that kind of says welcome to a particular company whoever you're working for and This kind of shows that you can create this kind of multi-tenant or fake tenant Dashboard experience and so just to reiterate what he just said I think that many of you may be thinking gosh We do that already on the front page and that is true Many of our clients are also doing this on the front page in similar ways. They're using pretty much just access restrictions With maybe profile fields and things like that So what this is doing is leveraging both core functionality as I mentioned along with plug-ins So when we're talking core functionality that we're leveraging custom roles So that first example that you saw where each of the Each of the different centers receives kind of their own list in the course category Each of those centers is set up as its own custom role a Little unwieldy to manage if you get up in numbers However, the role itself is really simple basically an authenticated user and then we can push and pull other things as needed cohorts, so This is actually I'll tell I'll tell a story on us I guess we've been working for working with each other for quite some time And I kept saying yeah cohorts is the solution cohorts is the solution We should be using cohorts and everybody looks at me like I'm crazy because everybody goes why cohorts only do enrollment? They're very focused And so finally we put this together and sort of broke broke through that door That cohorts really can be used for more than just enrollment. I can be convinced and trained. It just takes a while And then as we've mentioned access restrictions, so being able to use those cohorts For limiting access to particular blocks particular content and then obviously visibility so turning off the visibility on things Playing sometimes with CSS in certain situations in order to not make things appear hidden when they really probably are So Courtney was talking about the core functionality we do to really create this more of a seamless experience We are using generally some plugins to make this possible. So the kind of primary ones are the local profile cohort which allows you to Dynamically assign people into a cohort based on profile fields and then the block cohort specific Which actually allows you to do something that people really wanted a way of doing with blocks Which is making them hidden or shown to specific groups of users It really allows you to do that anywhere that you are using a block You can tie its visibility to membership or lack of membership, which is kind of cool. You can do it both ways Specifically in any cohort within the site Both of those plugins actually come from the university or Olm University. They just kind of flopped their name And they've done a really great job of developing those plugins releasing them to community Giving some basic use cases and then also being really open to feedback on the code Any issues performance-wise or anything that we've seen they've really taken that feedback and been great partners to work with And then the last one which is local cohort role And this is one that actually that team also recommends and one that we've actually used in the past that it really allows us to Say, okay, if this person's a member of this cohort automatically assigned them this system level role Which is where we're able to do things to kind of create this systemic level experience Which we're gonna dig into in just a minute So I always want to know that's great. You've told me some of the tools But let's dig in and take a look at how we've woven this together So the first thing is creating and if you know me you know that I will prefer to automate everything if possible So create and preferably automate those cohorts. So what you're seeing here is that profile field based cohort membership If you've not looked at this one before you'll notice that what it's doing is allowing you to Set up rule sets. So if the user matches this criteria, then add them to that cohort So pretty simple to set up And then you'll see that in the system available cohorts You'll notice the source is now profile field based cohort membership Anytime a new user comes in matches any of that criteria It will automatically push them into that cohort One of the really neat neat things about the plug-in is it'll actually allow you to start building out business rules So you can say must match these two things to get into this cohort or match only this one match all of these You actually have some flexibility for building out business logic within Moodle through this plug-in So then cohort role sync to custom roles. So again Being able to set up that custom role and then define the synchronization so that The cohort that's been established then pushes into that custom role that I mentioned really in this case It's kind of a glorified authenticated user There's not a whole lot extra that it's doing there because then it's pushing them in as a learner to those courses where they need access The nice thing is we're not excluding using cohorts for one of their primary use cases in the first place Which is enrollment, but you can also ignore the enrollment functionality of cohorts and use other enrollment methods if you're using something like the external DB Enrollment method or anything like that. Nothing that we're doing here excludes using any other method So when you get to the point where you're ready to kind of map those cohorts to the visibility of specific Categories, so that's what we were doing with the first example. We showed which gave you kind of a rundown of these Users log in there from this location. They can see these categories, but not these categories All you're really doing is going into the category level permission So this example is the baits example that you saw earlier and we've gone in and said the view hidden Courses no view see hidden categories. I'm sorry. There's both of those permissions you Just add that Basically that baits roll to that so that they can see that particular category and only members of that cohort can see that category And so the result is potentially a custom view So we went ahead and pulled those three examples forward just so that you remember What those looked like previously so the example that you just saw kind of built out is the one at the top where? Baits users are only seeing those baits categories When they take a look the one in the middle again is using Dashboard view. It's using the HTML cohort blocks in order to distribute information To that learn to that user based on their cohort membership And then the last one is aligned with their different Companies within their organization their different department areas so again notice it is on the dashboard Where it is displaying that? Specific menu set to them. I also know that people might have different setups There are options for things like automatically creating cohorts through different methods than the one we use as an example today So one of those would be if you're using LDAP for your authentication method There's the possibility of mapping those into cohorts So if you have a security group you can map that automatically into a cohort in the system So if you've already done that there's no need necessarily to back up and do it through kind of that cohort mapping or the Profile field mapping to cohorts that we kind of demoed today if you're using that When you're using kind of a standard restrict access you can use profile fields To do that restrict access But if you're using another method to create those cohorts you may not want to then map that to an extra profile field We would always try and avoid adding extra work and try and automate as many things as possible So if you have that set up there's options for doing things like standard access restrictions based on cohorts Actually the example in the middle when this picture isn't showing that but they also have that setup so that they can Do different things depending on whether it's a front page a dashboard or course page allowing them to do even things like semi-multi-tenant courses where some of the content is shared across the cohorts But some of it is shown specifically to individual members of cohorts And so they restrict access down to that cohort level for activities and resources as well So there's a lot of flexibility for how you build these things out a lot of it really that we do is Kind of stop and do some mapping What's already in place? What's already automated? Okay? What are you trying to accomplish? How do we put that together so that you are creating that curated end user experience that you're attempting to build? All right, so I hope that gives you a nice Kind of overview of some ideas that you might take home and implement I think we have maybe a couple minutes for questions if you have them And then obviously we're gonna be around for the next couple of days You're always welcome to track us down and we'd be happy to geek out about this Could you wait? So We can set cohorts right so within a cohort. Can you set selective roles for? different users, you know an example would be You know, I'm looking at not looking at non-academic settings So probably say and supervisor with people who report to a supervisor. So can you set different roles for people within a cohort? That's my question. Yes, so Find me. Oh, sorry find me and we can talk We have done some things where we set a user relative to a cohort so that the supervisor then has access To view reports and information about their cohort Yeah, it's a similar setup to what we're kind of talking about but a slightly flipped use case And there's a couple other things that you can do to kind of streamline that But yes, generally what you're doing then is assigning that role in the context of the cohort rather than Kind of the version we were talking about where you're assigning the cohort in relation to the user So it's gets into moodle contexts those of you who have been around moodle for a long time You know that there are a lot of context and they interact in sometimes unexpected ways Any more questions? I think there's one here. We've only got time for one more question. So just this gentleman here Thank you Thank you. What would be a good rule of thumb for choosing whether to use a cohort or a role? Is there a preferred way or one way where one would be better for the other? Well, I would say most of the time we're using both So the core cohort is really allowing you to identify the users you're attempting to target in a way that is readily Automated so if you already are doing this manually and you're saying it's a small group And we're just doing this manually you could assign the roles Manually and just skip the cohort but if you're starting to talk about scale and wanting to do this across hundreds or thousands of users the cohorts allow you a Slightly easier way of assigning this in an automated way so that as soon as someone enters the system You don't have to worry about them making sure that you manually go and add them to the right cohorts or add them to The right roles the system pulls that information and automates it all the way through And we have clients that are doing fully manual or self Registration that are using some of this but we also have some clients that have this entire stack automated It really depends on what you're trying to accomplish But if you're talking small groups of users you could skip some of the cohort pieces and just do it with a role Okay, thank you very much to Jeremy and to you call me