 And welcome back to another session of Domains21 for the OER by Domains21 conference. In this session, we'll be talking with Jolie Tingin and Matthew Raskoff about Duke University's kits, which I am intrigued by for several reasons, but I will invite them both onto the stream right now. To say hi, welcome to the session of Domains21. So I was, no, thank you for coming. I was just saying that I'm super intrigued by the project that you call kits. So I think it might be useful to maybe explain, A, what it is, how it got started, and where are we now, if that makes sense. So a little bit about kits and talking about it, and then we can maybe dive into some bigger questions that surround it, but I'm super intrigued. So take it away. Absolutely. Kits is kind of Duke's version of a next generation digital learning environment. It allows faculty to set up tools that are best for their teaching. And it started out as a tool that we've had around for probably a decade or more. I think WordPress was actually one of the reasons that we brought kits, something like kits into our infrastructure. We needed a way to easily set up those sites for faculty who wanted to use WordPress, but it has been extended to many different tools in our ecosystem. So it gives faculty a lot of pedagogical flexibility based on their discipline or their teaching needs. And so it started out as a tool that we've had around for a decade. And in the past three years, we've done a pretty major revision of it to make it more usable, more human-centered. The presentation of it has changed dramatically as a way to be an entry point for both students and faculty to access tools that are being used for their courses. Matthew, did you want to add anything to that? I would say the operating system in mobile has been one of the keys to innovation at the level of apps. And nothing like an operating system exists in ed tech. So each app is kind of its own stack. And we saw this real gap in the interoperability infrastructure. You could say the middleware that would connect apps to one another and would connect the ed tech stack into the student information system. And part of what KITS does is it's pride infrastructure behind the scenes that provisions data from the SIS into the ed tech ecosystem that is appropriate for your school, to Jolie's point, to your faculty, to your discipline, to the pedagogical choices that you're making and lowers the barrier to entry to bringing in the relevant applications that you want to use for your teaching and learning environment. And in the process creates this more competitive, more robust, more user-centric set of opportunities to use the right tools for the job. So it's kind of an alternative approach. The LMS attempts to bring all these things together into one system. And what we're saying is there are 4,000 ed tech products out there. We want to take advantage of all the innovation that's happening in the space, both open source and commercial. But we need better infrastructure in order to make that experience a good one, to make it consistent, to reduce the cacophony of a student who might have four different tools and four different courses and think about the experience that we've now presented them with. And the faculty are the same. So we're trying to create a kind of good common user experience around a proliferating and pluralistic set of ed tech opportunities that we want to take advantage of. We want to give our students and faculty access to, but do it in a way that is within the constraints of an institution, within the FERPA expectations and regulations that we have to uphold within the security environment that we live in. So that's kind of how I think about the opportunity and the advantages of this kids approach, which is it is the vision is this next generation digital learning environment. And this is our effort to kind of take a concrete set of steps in that direction. So one of the things that I'm compelled by when talking about the next generation digital learning environment, which is in fact, a term used by EDUCAUSE back in 2015 to talk about the ways in which, you know, the future of how we build and create a digital learning environment is changing. They use the kind of metaphor of Legos and you all have written about and even probably presented through EDUCAUSE about this. And I was struck because I think this is the first example, first concrete example of how this might work. And one of the things you alluded to, Matthew, is the way in which it starts to kind of create a layer of how we would say cohesion amongst all of these different applications within the environment. And can you speak a little bit about like how that's working? Like, how do we start to de-center not only the LMS, but connect a whole series of disparate third party tools, often commercial, in a way that is both, you know, seamless, but also maybe mindful of, you know, data, the collection of data, who owns that data, et cetera. So is that something that maybe is worth extrapolating on a bit? Jolie, why don't you take that one and then maybe I can dip in as well? Yeah, sure. I mean, I feel like, you know, in the past, the solution has been to just add a tool to the LMS. That's the cohesion, right? That's the entry point for everyone. That's the common interface, the common location. For kids, we've thought about kids as being one level up from the LMS. So the LMS is an app in kids. You can go to kids and set up your LMS course site. But there's this sort of consistent user interface across all the courses, whether you're a student or an instructor, when you come in, it looks the same, the presentation of the courses. You have kind of more of a blank slate. You can choose the tools that are right for you as a student. You can actually add some learning resources. And there's a lot of consistency that kids provides in that experience. And in terms of data, I mean, we're integrating all of the tools. So we have our own standards around that and our own ways that we implement these tools to make sure that we're meeting those privacy concerns or any data concerns. Yeah, I would add that I think there are two limitations of the LTI integration into the LMS that we were trying to overcome. One of them I think is just the fact that LTI is the learning tools interoperability standard. And it misses out on a lot of the non-learning tools that are used in the learning context in educational institutions. And I'm thinking about Jupyter notebooks and data science. I'm thinking about Slack. These are tools that have real powerful use cases in education but are probably never going to invest in LTI because education is not a big enough market for whoever, you know, the providers, the vendors in that case. So I think what we need is a non-LTI dependent mechanism to integrating and using like modern API infrastructure that all these vendors have provided makes a lot of sense. The other limitation I think of, you know, the LMS is that it's excessively linear for many learning experiences. Like it's designed around a week by week organization in most cases and that fits a traditional course, but it doesn't fit all learning experiences. And in some cases that you want something that's more modular, something that's more fluid, we have kits that are set up for co-curricular experiences that are not academic courses in the traditional sense. And what they need is a common set of tools and an organization system that, you know, provisions them to all the students who are in that co-curricular group or in a project or whatever. So we have this concept of user-created kits as well as SAS-created kits. So there's kind of the top-down from the course metaphor. And but then there's the bottom-up that individuals can make kits on their own and put together a group and put together the tools that are meant to be assigned to that group. So we're questioning, I think, some of the assumptions that are built into LTI and built into like the linearity of the LMS and in the process trying to liberate our educators. And actually, I think of this in terms of academic freedom, that we want to grant academic freedom to educators. Just as we do in the classroom with respect to content, we want to give a similar set of, you know, freedoms to our faculty with respect to interactions and tools that are associated with that. So those are the stakes and that's pretty, you know, big aspiration of ours. But but that's kind of the framework that we think about for this. That's great. And I was wondering, so like as opposed to the LTI, is the kits infrastructure then and cohesion all driven through the various APIs of the various tools that you have surrounding the LMS? Like, can is this because I know, Jolie, we met first, I believe, at the University API Conference in, I think it was Provo, right? Utah. And that is where some of these early ideas were brewing. And obviously, APIs still be a couple of sessions, both today and tomorrow talking about API. So can you talk a little bit about how APIs are working and how you do what Matthew, you referred to, which I think is brilliant is the notion of it's not just top down. It's also bottoms up and a kit is not just created for a course, but it can be created for a group or by a student and a faculty. So there's a lot of complex permissions back and forth, I imagine. And is it worth it? I understand we can only go so far in such a short period of time, but could you speak a little bit about how that's working? If other schools are going to start considering it or imagine it? Right. So one of the real consistencies with kits is actually around the groups. Kits is built on Internet2's grouper. It's not a requirement. You could use another type of group tool. But that's actually one of the efficiencies around kit, is that you start with a group and then you set up your tools around that group. So it manages those memberships across all of the tools. So if you go to your kit and you add your TA to the kit, your TA is then added to all the tools that are in your kit. So that's one of the greatest efficiencies and benefits of using kits. But talking about the tools, we've used APIs to integrate tools. We've also used LTI to integrate tools into kits. If there's an LTI integration possibility, that saves us a lot of time. And we'll probably build an admin tool that allows us to plug in LTI tools, like an application administrator could do instead of a developer. Just like you have with most LMSs on the market. You're able to do that. But something else that you just mentioned, Jim, and that Matthew was talking about that I think is really powerful about kits that's a little bit different than the LMS is students don't have a lot of agency with the LMS. In a traditional core site, they can just respond to a forum's post or submit an assignment. There's no kind of personalization or customization that they can do for their own learning so that it becomes a resource for them. And that is possible with a kit. And it's also possible for students to go create a kit, to have a study group, or create any kind of resource that would be helpful to them to collaborate with other students, or even just corral their own resources for their learning. So I think that that's also one of the major benefits of kits. And I would just add that we're supporters of LTI. I just think it's sort of necessary but not sufficient to do all the integrations that we want to have. So we'll use it when possible and it's efficient. But I don't think it goes far enough in terms of all the different tools that we want to make available in a modern ed tech ecosystem. Where at Duke, we have I think 150 different tools in our last survey that are being used across all of our programs and departments. And it's only going up from there. I'm sure it's actually more than that. We just don't see all of them. We don't know about all of them. Part of the benefit of kits is that it actually brings that process in-house. It makes them more visible. It lets us see what people are using, what they're integrating. And it creates an infrastructure for tracking them and making sure we're getting the utility out of the licenses that we have. And we're actually using this software. And if there are things that are being used that are duplicative, we can make strategic choices. Some of the innovations are happening in the departments that may not be visible to us. And if we see a tool getting real traction, that's influential in the way we think about our central decision making as well. So I think just creating this modern infrastructure that allows us to innovate with these tools, it requires the LTI standard. But I think it needs to go beyond that. And I think LTI needs to accelerate its pace of innovation as well. And I think it's been held up and has not moved as fast as the market has needed it to, let's say. It's interesting, too, because the LMS is a poor, almost router for all those APIs, right? They can't go through there, so it becomes a black box that prevents you from doing all the change that. Especially proprietary LMSs. But even though open source LMSs, at Duke, we have Sakai. And so we can go into it. We could do kind of API. But I think what we want to do is kind of have the LMS as one of these tools and not try to cram everything into the LMS. But think about relaxing that constraint a little bit. Yeah, so I mean, I'm interested. Obviously I've followed the long death of the LMS since about 2005, 2006. And it's still hanging on, right? Like it's the thing that won't leave. And that's good, though, because I think one of the promises of the NGDLE was that it's not like the LMS isn't still important. It's just not the same thing. And Jolie, it's super useful to think about it as moving a level beyond or above the LMS to start thinking about that. So obviously one of the questions that comes to mind is what are some particular cases and what does that kind of need? Specifically, let's talk about Duke for now. At Duke, where KITS has proven to be a boom for possibilities that would not be possible otherwise. I can talk about that. I mean, in lots of ways, we had the usual suspects of people who are not heavy users of the LMS in the first place that made tool kits, KITS predecessor a valuable tool for them, which is another reason why we decided to invest in tool kits and a redesign. So we have faculty in this, particularly in the sciences who are using tools that are just not tools in the LMS. They're using tools that look nothing like tools in the LMS. And they need a way to set up those tools and share them with their students. I'm thinking about math, computer science, lots of folks in the sciences have all kinds of tools that they're using that we do not have connected to our LMS. And so KITS has always been a good fit for those faculty. And we're looking at how we might actually bring more of those tools into KITS, integrate those things like GitHub and GitLab, particularly repositories, but even other things like Gradescope and other tools that are being used heavily in the sciences. However, recently I met with a faculty who teaches English and she teaches writing and presentation skills to English a second language students. People at Duke who say, I want this kind of support, I'm gonna sign up for these courses. And she is not a tech savvy person. She's not someone that we would have put into, that we would have thought about that KITS would be a natural fit for. But she loves the simplicity of using KITS because everything is one place in one place. It's easy for her to set up the tools that she needs. She uses Box and she will likely use Google when we integrate that, the Google tools. And so those are really good fit for her in the courses that she teaches and she has an easy way now to set those up and share them with her students. So I think we're still discovering faculty and across all disciplines where KITS is a really good fit for them rather than the LMS. Jim, you mentioned you're in Italy. One pleasant surprise that came up in the data that Jolie shared with me recently is that the Italian department or the romance languages department but within that the Italian language group are power users of KITS. And it's actually not that surprising in the world of teaching and learning because language faculty have always been really innovative in their use of technology. It used to be the listening station with tapes and the language learning lab. And now it's apps and they've got tools for interacting with native speakers and they have tools for dictionaries and they have tools for translation. There's a lot in the language learning stack that needs to be integrated and supported and they're early adopters within the humanities. So that was very gratifying to see that it's not just the data science and computer science, the people who know they need tools and they know they need infrastructure to integrate those tools. But there's also this I think next wave of innovation that I think we can unleash by lowering the barrier to entry to using ed tech and to doing it in a way that is coherent that's not kick-off in this for students. I think we're gonna expose and support faculty in a much wider range of domains than we have typically heard from in the learning technology world. And that's exciting for me to think about this as a whole university, whole catalog support. That's infrastructure. That's the level at which we should be investing so that we can support all the disciplines in ways that allow them to pursue their pedagogies, their approaches that are relevant for them without kind of imposing from the center this one size fits all kind of LMS model, which I think is really constrained the innovation at the disciplinary level and at the individual faculty level. That's the stakes that I see. And it's really about every single field having an opportunity to use things that are relevant for this. And the chemists need something different than the biologists and the physics. That proliferation is good. We're pluralists. We want to support it, but we can't have duplicative tools. So we need to find some middle ground between the total top down enterprise IT model, which says we have this one thing and you're going to use it. And the total, the kind of chaotic cowboy model, which is to say, like, I'm just going to do this. I don't care what this ESO says. We're just going to do this. And there's got to be some middle ground where we have security and privacy and like the things that we need to control and some coherence for our students and faculty, but also freedom to experiment with tools that are appropriate for your needs. And we want to support that experimental mode. That's the middle ground we're striking here. And building for Italia. I always love to hear Italy get a little love, even though I can't speak a language very well. And I've been here five years. We have some Italian courses that maybe you could take. I have to. The other thing though is, you mentioned it, for example, Matthew, one of the things you brought up that I think was a good example of that is Jupiter Hub, for example, and Jupiter Lab. How, like, how do you all decide which apps get brought in? Is there a process where, say, someone from another school could write, you know, an integration for an app? Or how does that look right now with kids? And maybe what's the roadmap to enable more and more apps to provide a broader universe for folks to pick and choose? Because that's the beauty of kids is, you know, you decide which tools you're going to use based on which class. And I really am compelled by that. It's a truly intriguing model that takes the kind of vaporware idea of NGDLE that have existed for a few years and puts a concrete vision on top of it, which I think makes the work you're doing really, like, unique and forward-thinking. So how do you expand that in a way that's scalable? Thank you, Jolie. Why don't you start, and maybe you could say something about the open source, you know, vision that we have for kids and the community we're starting to build around it. Yeah, I mean, I'll address the requests around the integrations and the apps. We have a list of requests from faculty to integrate specific apps that we have not yet integrated and we are trying to get to that work. And we have a few on the horizon. I think I mentioned Google earlier in Gradescope. Those are two tools that are of high request and are higher on our list to integrate in the near future. And there are lists beyond that, but, and I prioritize those based on the number of requests that I get and the number of faculty that I think will benefit from using that tool. We may look to even scoping access around tools that are just licensed within a specific school, how we can add those to the app store to let faculty within a specific school be able to set those up, but just keep it scoped to their access. But we all are, as you mentioned something, how do we, about how do we take advantage of other schools writing integrations? We do have some schools that are interested in kits because the problems that kit solves for Duke are not unique to Duke. Lots of institutions have a really rich ecosystem of learning technologies that faculty are using and these barriers existed those institutions as well in terms of provisioning and finding the apps, faculty discovering what they can use, students being able to navigate all the apps that are being used for their courses. And so we are working toward open sourcing the code. We're starting with a small group of institutions that have early access to sort of do some early evaluation for us so that when we do get to open sourcing the code we'll be in a much better place and potentially have some adopters, people who are interested in moving forward with kits at their own institutions. So, I'm very encouraged by that and we are hoping that those schools will collaborate with us and write integrations for apps that are either in use at both schools or just even at their institution so they can contribute that back. So, I'm excited by these opportunities. We have a meeting this week and I'm excited about what that might bring. The vision for kits is like Julie said, it's not just for Duke. We want this to be shared open infrastructure that benefits the entire community. And we're figuring out what is the right open source strategy to do that. And we're very receptive to ideas from the community of open source contributors who have experience with it. So, we know we want to launch this thing. We know we want it to have a life beyond Duke and we've got to figure out the sustainability strategy to make sure that we have the mechanism to keep investing in it, that it's sustainable. I think doing integrations at one school and sharing those makes so much sense. There's no reason to do like a custom integration. Once you figured out how to bring Slack into kits, there are gonna be dozens of schools that are interested in that. But we are attentive to the fact that the resources at different institutions vary widely. So, while we have a fantastic engineering department that is able to do integrations for us based on what our faculty need, not everybody has that. So, we're also talking to hosting and service providers to do a kind of red hat style business model. So, the code can be open source, but for those who need extra consulting, integration support, hosting, cloud hosting, for example, there'll be like a SaaS model that can support institutions that need that and there'll be an open source model for those who want total control and run kits on their own infrastructure as well. So, we wanna have those options to serve a diverse set of institutions and we're attentive to the fact that Duke is not representative of all of American or global higher education. And we really believe this is infrastructure that should be shared that could be beneficial to the whole community. So, that's kind of our thinking right now. Yeah, it's interesting too because the way you talked about cloud infrastructure and obviously I'm interested in that, working in both shared hosting, but also managed hosting, but now cloud infrastructure. One of the things I found pretty striking and really kind of a boon for the work you all are doing is not only can you get fairly seamless integration, but also given the nature of, say, containers, you may be able to in some almost, how would I say it, in a way that's somewhat consistent from school to school using internet to and grouper allow for an infrastructure that's fairly similar from school to school and gives them access to all the different tools they might need for data visualization, data informatics, you name it, and even ones as popular as Google in box or as completely niche as like data set. And I think that's super interesting that, depending upon how it's built and the architecture you do with the open source, you would have a fair balance of the commercial big companies as well as the niche, often academic projects that are done at the school, right? So it would be interesting to see how that works. Very much so, and you've hit on an important point to Jim, which is that kits is a mechanism for discovery. It's not just a tool for kind of user experience and kind of integration. The app store that's built into kits is partly our theory of how people are gonna figure out what tools they want to use and we can use it to promote open source solutions. Like that to me is exciting. Figuring out what are the default apps that are included in the kits package that gets rolled out to other institutions, that's gonna be a very powerful influence over what they use. And if there's a good open source option that we can promote, and I think that would be wonderful as a way of thinking about this as a package that enables, think about you get a new phone from Apple, it has a bunch of apps from Apple that are already on it and then you can download other things. And we can put, I think, some good thought into like what are the open source projects that we wanna have included in the package that comes with kits at your institution and then you add in the infrastructure that is particular to your place that you need for your own stack, for your own ecosystem. And you can do some of that vetting as a broader community around sustainable, what will be there, what is one off and what is something you wanna maybe include in the custom package that everybody gets. And yeah, it's compelling in a lot of ways because I had a hard time personally. I've been following the NGDLE conversation for six years as long as it's been out because I was struck by the vision Malcolm Brown and them set up and set out. And I really do appreciate the work you all did with kits because I think you finally put a concrete vision that people can start building on top of and really imagining that future. So I wanna thank you both for taking the time to join us here at Domains21 and talking about your work because I again, I'm super intrigued by where it goes. So thanks again. Thank you and we encourage participants to get in touch and maybe Julie can share her information if they wanna learn more about rolling out kits at their institution or in this phase of expansion and we're exploring these partnership opportunities right now. Yeah, and I'll look forward to that information about open sourcing and various schools working together some sort of consortium or coalition. Exactly. That would be a lot of, I mean that would bring probably the leverage and the scale kits needs to stop, I mean move beyond the Duke vision not that it's great, I mean maybe the Duke people will be jealous it's leaving but at the same time to share it more broadly. It's not leaving, it's graduating. Well thank you both again. Thanks so much. Bye. Hum, hum, hum. Om nom nom.