Choosing Wagtail for Columbia.edu

Speaker 1: So hi everybody, good morning. My name is Zarina Mustafa and I am here this morning to share with you the experience and the process that my team and I um went through in order to choose Wagtail as one of the tools in our tool belt in uh my department and what we do. For that I will have to go through a little bit of the background where I'm I work at Columbia University in the city of New York, which is about two hours away from here. And my department is called the Center for teaching and learning. And what is a center for teaching and learning? If I'm not mistaken, UPen also has a center for teaching and learning. It's there are many, many universities

Speaker 1: with the CTL. Our general mission is basically to support and promote the practice and the culture of teaching and learning. The emphasis is the practice and the culture of teaching and learning, excellence in teaching, um, improvement of learning for uh for the students. Deep in our mission that sets us apart from other CTLs in other universities is that we have uh a mission where we support the purposeful use of technology in conservative Whether it's online or physical classrooms, whether it is just using hardware, but for the most part, we focus on software and web development.

Speaker 1: And the tools we create, the applications we create based on what the faculty that comes in the door in our department asking for help in that matter. So We are a team of 40 people in the Center for Teaching and Learning and my group, which is the Software and Web Development, is only five people. So um the other 35 they are basically um experts in teaching, experts in learning process. And we support them in the decision making of trying to decide what kind of technology we're going to use in any of the projects that come into the department. So normally a faculty or a group of faculty

Speaker 1: or graduate faculty will come in with a set of pedagogical objectives. This is what I want to do in my class. I have an idea. I want to use some technology, but I'm not sure what to do with it and how it relates to our um you know objectives in trying to teach our students. So from there my group along with the other 35 people who are involved in the in the uh conversation would look at the technologies that they're using. We either support the technology or we create new tools in order to achieve that idea that they have. And if they don't have the idea or they don't know where to go from that um initial idea that they have

Speaker 1: we go ahead and do some more research for new solutions so we are all academia so research is a big thing for us to do um which is not a pretty bad gig But we are also the academic we're also free open source software. We're big on that. We like free. So my role as a front-end developer is that I am primarily involved in information architecture of the thing that we're doing creating user experience, user interface, accessibility because we are governed by section 508 and everything else that comes you know in between that So it's almost like a unicorn. Another thing that's very important is

Speaker 1: the technology that we're using, whether it's a website, it's a software, it's an application, it's It has to be seamless with the process of learning. It cannot, must not, and should not impede learning. We are in the business of promoting practice and culture. Teaching and learning, that's our mission and that's what we're gonna work on. So my level in programming is I'm primarily using a lot of JavaScript framework, but now I am moving a little bit more in the programming level. So my Python knowledge is, I would say, advanced beginner more on the beginning than the advanced, but you know, a little edging towards intermediate. But I rely on my colleagues

Speaker 1: to give me uh pointers and ideas and where to go to proceed with what what I know. So like I said, we are primarily Python Django shop, but we explore other technologies and other frameworks, not limited to what's listed here, but these are the few recent ones that we're looking at, and we have used other frameworks. other content management system. You got Hugo and Jekyll, which is actually a static website generator. WordPress, which is run by CampusPress, which is specifically geared to educational institutions. and of course Drupal. And then we also develop a lot of LTIs for Canvas, for our

Speaker 1: learning management systems at Columbia and also now we're looking at MOOCs with edX, Coursera, and other organizations that deal with massive online learnings. So we have over about we have developed about 300 projects thus far in about 15 years and these are the some of the more recent ones. Most of the ones that you see here, I think I'm about about maybe six of them are on Django, uh one on WAC , one on um Hugo and the other one is on AdX. So I said before faculty comes in, they have a learner-centered mission that they want to accomplish. I have an idea, I have a technology, this is what I want.

Speaker 1: So we would use that as user story. That is our user story and from there we would recommend what kind of solutions to support that idea. So we would build tools, for example. We have built mapping tools for a faculty who is interested in mapping the history of education in New York City. We have developed Media Threat, which is a media annotation tool. That's being used by Columbia and other universities. That those two are Django-based. Then the next one is generally people will come in and say, I would like to build a learning, a linear learning uh modules it's very static it's page by page moving forward a couple of images couple of media

Speaker 1: it's just like a book but it's on the web And then there is another one which is a little bit more complicated. We have a learning module. It's still going on from chapter to chapter, but within the chapter chapters, we would intersperse with interactives or some other connection with other applications that we have built in another project project. So it's a combination of control by the client, which client faculty, over the content of what they want to teach, and then we provide the tool that we've we've create it and see if they go together. And these two things lend itself to the need for content management system.

Speaker 1: Most of the client who participated in creating the learning modules or something of that sort, they need to manage the content. They need to be able to put in uh images and videos and anything that they find elsewhere. And they need to be independent. They cannot, they don't want to come to us every time they have something that they need to do. So but then again, you know, we can't really give the expectation that you are fluent in Markdown, that you can go in and do things with HTML We cannot make that assumption because everybody they come from a numerous spectrum of uh technical experience

Speaker 1: Most people are familiar with Microsoft Word, so WYSIWYG is very important. Most people like drag and drop. Most people like this. you know the simple things that they do every day that's natural to their process of creation and we need that in the CMS It's you need to be intuitive based on the experience that's largely out there. So we develop a couple of criterion to look at the CMSs. What do we have now and what do they have out there? So we look at the criteria that we I will explain the criteria in a bit. So we looked at a couple of um CMSs that we know is Django, we know some

Speaker 1: WordPress, we know Drupal a lot, and then at the time we were just investigating Hugo, and then we have um Django CMS and Wagtail because We do a lot of work in Django. So here's a question. Does anyone know what a pizza team is? Just one? What is a pizza team? Exactly. So Jabezos ki you know said that the a a very large corporation does not need to improve community The teams in meetings should just be enough to be fed by just two pizzas. And that's basically what we do. We have hackathons every month, once a month. And that's devoted entirely to research and development of any technology there is out there

Speaker 1: in order to find more knowledge to support our faculty. So we we set aside three six six hour three six wait three days six hours each day two pizzas each And we look through, we look into how the um Hugo, Django CMS, and Wagtail, compare, contrast, see how they fit, see how they fit our mission, because our mission, again, practice and culture of teaching and learning. So going back to the rubric that we created, we looked at control. We want to have control over the model. If we build a page, what is this page going to be? It's going to be videos, images, etc. etc. We need to be able to control

Speaker 1: and have a larger picture of how these models are connected. We need to have control over the code, the template. and we need to be able to test it. Of course, everything that is Python based, we can do that. Um Hugo to some extent the modeling is on the config file it's a little hokey it gets really complicated when it's many to many relationship it has no database that's what we're talking about and say. Camper Brass has no model, it's just pages. And Drupal is um yeah it's it's okay but we can't see the larger picture. We can't see if somebody else is creating the model and and now it's breaking and then we can't look at it quite night the way we want to look at it. Virgining is very important.

Speaker 1: I have made many mistakes as advanced video And so I can fall back to where it was before. Campus Press and Drupal 's versioning is mostly content, not code. The UI for CMS The Django UI in all of our projects in Django, faculty client has expressed dissatisfaction over the user interface for them to add content, modify content. create new content. Hugo has no CMS. It relies heavily, we rely heavily on GitHub and We cannot expect people to come in and have knowledge of Markdown. Um Django CMS and Wagtail has excellent UI for CMS. Content management is impeccable, we love it.

Speaker 1: And then we could say the same thing with WordPress and Drupal. We cannot lie that it's not great. It is great. It has WheezyWake, clients love it, so we need to be you we need to be attacked. attentive to that particular need. Authentication and security, how these tools integrate with Colombia, security, Colombia authentication. Most of them do well. Hugo doesn't really need authentication at the moment. We use it mostly for static websites. And then we have our own, our departments. CTL have our own workflow, how we deal with continuous integration, et cetera, et cetera. And for the most part, like

Speaker 1: You know, actually all of the Python-based framework works well. We don't need it for Hugo, and we certainly don't need it for Kemp. WordPress and Drupal. So we have a nice choice here. Do we choose Django C Or do we choose Wagtail? So for the so here's the other additional rubric that we create, we come up with with like um how is it going to how are clients going to respond to some of the things that they need further and how are we as developers going to respond respond to the things we need to do with um with Django. So Django CMS and Wagdale

Speaker 1: wins of course. This is a Wagdale conference, right? It would be really fun. So Wagtail is a separate application and we really like that. We have our own Django application. in the project, we want to integrate our mapping tool in a learning module. And the learning module is being controlled by the client. Great, but we can control our own thing in within that same prompt It's very flexible. Out of the box is very clean. And out of the box, I just set it up as a beginner. I could do it. It's extendable. We've developed some very interesting um um experiments with the website that I will show uh later on.

Speaker 1: It's very simple. Showed it to one of my clients Um and she said, oh my god, this is lighter than Drupal. And lighter, what she meant by lighter is that it's terribly simple and that simplicity is because we work together to decide what the CMS is going to be not what the CMS is and we fit to that CMS. And is responsive and this is really important. One of the things that we um that we keep telling everybody in my department it has to be responsive, it has to be accessible, it has to be printable. And of course search integration, we are still experimenting on that, but the Elasticsearch as an official uh Wagtail supporting Elasticsearch is um

Speaker 1: is good news. We are trying to figure out if we can do it with solar support documentation. I think people have said it many times that it's it's robust. It's great. I understand it and environment an advanced beginner I can understand that that's pretty cool. It has an editor support, so I can just give that to the content providers. They don't have to come to me and I don't have to write another manual for that And the learning curve, we kind of stopped doing more research on Django CMS. We continued with Wagtail. Learning curve is manageable, it's not terrible. So it's a good thing. Let's see so but some considerations there's some bumps in um in with Wackfield

Speaker 1: what we do which is basically like our faculty is our client so there's expedient I want a course blog, my class starts in spring. I want to spin it up right now. Um, add blogs WordPress, Drupal, serves that need really well. You can do this, here it is. But then there's this technical debt. Are you using this just to start your course blog or do you want something richer do you want something cleaner do you want something that you can manage that can survive more than one semester you can extend it to another class next semester or another course by another faculty And it does require a developer. You can't just spin it up like that out of the box. Maybe you can if you have some knowledge

Speaker 1: how to do that. For the most part, they need us in the short term, in the long term, to go through the user story so that it becomes a critical mass how and when we're going to recommend Wagtail for their project. And of course when something you know happen and everything is great and then have a feature request. So we need to spend a little bit more time to look at our models, I mean see how they fit, how what will be compromised. etc etc so in neat time and um there's also migration from old applications we have a lot of legacy projects From Drupal from Movable Type. Anybody remember movable type? Old old technology. We still have that and faculty are still using it.

Speaker 1: So we need to migrate that out. So we're experimenting on how to do that, starting with a couple of projects with the music department, which is pretty exciting. So the experimentation. So we know what it is, so let's try it out. This is something that still in the works, it's not widely distributed, it's not even live. We are building in our department a portfolio of all the things that we have made, that we have produced. It's very simple. You know, it has thumbnails, it has a list of things, and you click one thing, it goes to another thing thing tells you what it is, but the thing itself has many things in it. And the project is by a developer, there's a project manager, there's a developer, there's a designer, and there's a communications manager.

Speaker 1: and the communities manager is our client so to speak in this case where she wants you know this is a tool For others to know us. I want to see this, this, this, and this in this manner. And the designer would say, okay, I want this, this is how it looks like, and this is how it's going to print, this is how it's going to look on mobile. All the functional specifications all the technical specification all the communication specification is built into the model and you can see how it maps out and we work together with the developer with the developer and the the communications manager and the designer um and when we give this to the communications manager he just enters everything don't need to worry about where it's gonna go and if we decided that it doesn't look right then we can just play around with the template later on

Speaker 1: still same model great No complications. And we are extending this even further because we're now trying to figure out how this is going to be going to hook into our main website, how this is going to be published into communications, uh leaflets, etc. etc. So it's it's gonna be uh complicated very quickly around July. So Let's see. So there are a couple of um criteria that Wagtail met with us across the different exp uh the different groups of criteria. that we have which is developers, designers, faculty partners, and content providers. The flexibility and extendability of WagTil

Speaker 1: is a welcome relief, I would say, for us. Because now we have a thing, something else to provide them to say that, you know, you do have a CMS and you can customize it and we can do whatever we want given, you know know the restraint that is not the CMS. And the UI for the CMS can be customized intuitively with collaboration among the designers, the developers, and the faculty. partner which is great because then it creates room for faculty and for creativity. You can be creative in your modeling, you can be creative in your the UI, you can be creative in your in actually sending out the message or the

Speaker 1: the learning uh you know the activities that we we build etc etc with Django and Wackdail And this is still beginning. We are barely scratching the surface with Wagtail because um uh you know among other things that we have to do. Um But we're excited to look at it further. Our next project, as I said, is a uh collect um the migration of um the music glossary from the music uh music human The class is being used by everyone, every undergraduate in the humanities class. So it 's pretty exciting to see how Wagtail can serve that purpose.

Speaker 1: So that concludes my talk about the process. We are still ongoing, so we will let you know how we're going to go from there. On our blog is compiled. ctl. columbia. edu. We have a blog, a developers group, and um we post from time to time about our experience. in in the things that we make and each post we accompany it with cat pictures that encapsulates what the post is about. So print is the device, you can see a cat with a printer, and you know no dogs allowed, it's authentication. So

Speaker 1: when I go back to my desk, uh the end of the week, I'll be writing about this conference and my experience with Wagtail. And I will be using this photograph. So I think the birds survive, but you know, we'll find out. And uh yeah, thank you.

Speaker 2: I have a question actually, one thing that came to mind as an educator is that was is there a module for grading? For what? For grading.

Speaker 1: Grading. We use Canvas.

Speaker 2: Okay.

Speaker 1: Um, so because it is supported by the university it's integrated with the registrar and therefore the courses and the groups. Some of the things that we created for that uh for for our group is a tool to support the learning. So all the exams and the clo uh um For example, Media Threat is the media annotation tool. That is actually, we develop an LTI for Canvas. And we hook up the two and when they did assignments in Media Thread, it goes straight to Canvas.

Speaker 1: But it it we did a lot of work on that. So it would be interesting to see if we could do the same in but I'm pretty sure we can because it is Django. So we've done it before. It's just a different route Does that answer your question?

Speaker 2: Uh yes. Um it sounds like Canvas probably has a lot more possibilities than Blackboard.

Speaker 1: Uh and yes. We have used Blackboard many, many, many, many years ago.

Speaker 2: Sure.

Speaker 1: And then we moved to um Sakai and then now we moved to Canvas. Any other yes?

Speaker 3: The example you gave where you have, I think it was the educators fill out a big stream field block and then that gets populated in multiple forms on the website. Cognitively, is that something that the folks you're working with appreciate? Is that confusing for either the designers or the educators that you're partnering with?

Speaker 1: Um when we begin with our process is basically like We don't go straight to screens. Tell me what you want to do. Tell me how you would imagine you want to annotate this video. Tell me how you would do how to map this thing And so from there, the designers are involved from the very beginning. The same thing with the developers. We come in and we sit there because the designers can tell you, okay, this is great, we want this, we want this. but they don't know the power or the limitations of a technology that we're going to use. We never recommend technology first because sometimes things, it sounds complicated, but you could achieve it with you know WordPress but sometimes it sounds simple

Speaker 1: but it sounds simple because the methods to get there is complicated so simplicity is not easy we try to achieve that by doing iterations of user stories, etc. etc. Like um the video annotation tool that we made for Media Threat, Django, it's like multiple, multiple iteration. the mapping tool, the history of New York, we use Google Maps, but it's it's the the process of how the student learned what these historical sites connect with each other. We go to that meeting. We go to their classroom to see how they work.

Speaker 3: Great, thank you.

Speaker 1: Sure. Yes.

Speaker 4: You mentioned at one point that um in terms of using this for say like a a a professor that wants to start a new blog, it requires a developer to get involved in in Yeah. So I I assume you're talking about maybe customizing some models.

Speaker 1: Yes.

Speaker 4: Would it not be possible to have sort of a a a one or two or three different sort of models already set up and then you could just go into the admin and say okay I'm gonna create a snoop blog and

Speaker 1: that's what we were thinking. So we start sort of like a boilerplate. This is a simple thing, complicated things, very, very complicated things. So we're we're trying to figure out like um what are the patterns because every time when we create something with a cookie cutter and they say but what if I want X and then now that cookie cutter is a little with an X like a quiz tool you know like okay I want um you know ABCs but what if I wanna choose your own adventure and then now this and then you know so it's it's um

Speaker 4: I don't know if you're aware of the site settings capabilities in Wagtail.

Speaker 1: Uh yeah, we looked at that too, but we were we're we're trying to figure out again like what are the patterns and then how do we cookie cut this These patterns. Any other questions? Great. Thank you.