Up next on the roadmap - Wagtail Review

Speaker 1: Yes, the roadmap.

Speaker 2: Oh.

Speaker 1: And what's next on the roadmap?

Speaker 2: But what?

Speaker 1: The map of the road. The map of the road

Speaker 2: But what? To what?

Speaker 1: To our path, to the stars and the future.

Speaker 2: Oh. The feature of

Speaker 1: Wagtail.

Speaker 2: Oh. Surprise.

Speaker 1: Baptist, do you know why Wagtail is called Wagtail? It's because it's the only bird that uses roads, which is why it needs a roadmap. Oh no. Is it? Do you know Sage why it's called Wagtail?

Speaker 2: I think it was originally going to be named Verdin or something because of the color scheme. it's it's green, right? It it used to be green dominantly, but it sounded like verdant Sorry, Verdant sounds like Vermint and Rodent. So um we settled on Wagdale. Well I wasn't there at the time, but Apparently it's the type of birds that would appear outside of Torchbox's office. Torchbox being the creators of Whitetail. So yeah.

Speaker 1: Voila.

Speaker 2: And that was more than 10 years ago now, apparently.

Speaker 1: Beautiful. How long have you been doing Wagtail Baptiste?

Speaker 3: I've been doing Rugtail for a while. I think at least six months.

Speaker 1: Wow I've only started

Speaker 3: uh working with Wagtail when I joined Torchbox uh in February this year. So it's been fairly short for me. I think I'm amongst experts here that know a lot more about Wagtail than I do.

Speaker 1: Take it as a compliment.

Speaker 3: I have been using Django for quite a for way much longer than six months for sure.

Speaker 1: Do you know how we manage our roadmap for Acthill?

Speaker 3: No.

Speaker 1: Okay Let me introduce you to our roadmap. Woo! You mentioned Django. Wachtel has um has a fixed release schedule like Django re-release once every three months so four times a year which is pretty tight uh but I guess you know it makes lots of sense to us to bring um improvements like very incrementally like that And yeah, I think you know uh part of the reason why Wagtail uh is picked by people, why Wagtail, why people find it compelling among other CMSs, is that uh even though it's open source there's a pretty good cadence of new improvements coming to it um as well as maintenance

Speaker 1: And uh the roadmap specifically, uh we at Torchbox tend to make lots of suggestions for it. We also look at uh community-driven projects like Google Summary of Code. It's a very frequent addition to the roadmap and then we put together a big RFC which is a request for comments with all those proposed I guess topics of focus uh highlight features for all of the upcoming releases. Um and the RFC, the idea is um it's a format that people understand that anyone and everyone can make comments on. I don't know Batis if you looked at Wikteat RFCs before or maybe the Django equivalence depths

Speaker 1: do you like to review those kinds of things?

Speaker 3: No sh

Speaker 1: it's tons of work.

Speaker 3: Yes, it's it's uh type of work that I don't feel I'm very good at so I tend to feel more comfortable in a pull request review or code rather than uh a DEP or an uh even an RFC

Speaker 2: But sometimes I think it's interesting to see the opinions of people who have left the comments. So you might not have anything new to say, but it's still interesting to see the discussion.

Speaker 1: Yeah, some of them are really, really um deep and thorough. So you do require to be in that kind of same mindset to make the most of them. But the good news is for the roadmap updates, it's much shorter. Those roadmap items here, they're only defined in about four or five lines. maybe a bit more for the new ones. So it's really more like on a high level understanding of what makes things compelling than the details of the implementation. So it's more about the direction I suppose. the vision than exactly how the road is paved. Uh yeah, and I guess why we're here today is because we've just updated the roadmap for the next two versions of what

Speaker 1: due to be released in February and May. Yeah there was five five things on the roadmap for February and four for now in May. There's still some room for that to change Some that we were trying to get sponsorships for and some that need other contributors, I think. We need to find more people to work on them. Should we go through the items of the next release in order?

Speaker 3: Let's do reverse order.

Speaker 1: Reverse order. AI checker concepts. Actually, I'll skip this one. It's too intense. Let's do block settings and then get back to the AI. Sage. We love block settings. Tell us about block settings. Why do we want this?

Speaker 3: Why would you want to block your settings?

Speaker 2: Yeah, I sometimes think about like how ambiguous that wording is, but I think in it's in the context. Once you see the context, it's pretty clear. So in White Tail, the editing interface can be uh built out of what we call blocks. It's powered by stream field which underneath is JSON field so it lets you add flexibility to how the page editing experience is built. And yeah, the way we build the blocks is it basically consists of fields, right? And in some cases, people may have blocks that are not meant to be the content that you see itself, like like the text or something, but instead you have blocks that control

Speaker 2: how that specific block is displayed um in the front end of the website. So like you might want to give the editors the ability to change um maybe like the font size but not necessarily letting them uh select any arbitrary font size but you have a predefined set uh that follows your design guidelines or maybe like the color scheme of that specific block again uh not giving the exact colors um not giving editors control over the exact colors, but it's all predefined by your developers according to your design. guidelines

Speaker 2: and it currently if you have such blocks it's uh so white has no distinction uh which means they're just going to be displayed along with the content blocks which It works, but could be better because in some cases the editors don't really need to configure those. Maybe the defaults are good enough and they just want to focus on the content and having those settings blocks um in the same form um without a way to hide them can be a bit dis So yeah, in in this um well we are looking at a PR here, but um Um

Speaker 2: yeah the feature itself is about letting you mark such blocks as settings so that Wagtail will collapse them by default and if you want to use them. um you can show and hide those blocks specifically. And I guess uh another um points of view to this thing is to allow you to group multiple blocks under a collapsible panel. without necessarily having to refactor your blocks into like nested blocks, which means you'll have to restructure your data and do migration. So if you already have existing blocks where the content lives alongside the settings

Speaker 2: and you just want to change how it's displayed in the admin , yeah, it might be useful. to do that. So we're trying to um well I don't want to use the phrase kill two birds with one stone because we're we're friendly to birds.

Speaker 1: We don't do this in Wagtail.

Speaker 2: Yeah we don't do that in Wagtail. Um yeah. We want to feed two birds with one

Speaker 1: feeder.

Speaker 2: One worm. One early worm. Well well, I feel bad for the worm. But I don't want to say bread because apparently you don't you're not supposed to be birds with bread as well. So with with one seed. I don't know how how you can share

Speaker 1: With one fruit.

Speaker 2: With one fruit, okay. I can get by that.

Speaker 1: Doesn't doesn't have yeah. Yeah, we have um The requests for those features have been there for years, if not decades at this point. A lot of people will be elated to see this when it comes out in 7. 3. We have uh eight hundred and sixty one worth of seeds or fruits or birds to feed depending on how you count it. So it's really useful when uh you connect the dots like that. uh over the years and um yeah

Speaker 3: can i ask the question

Speaker 1: yeah for for sure

Speaker 3: so what kill ships with the series of blocks that people can use out of the box, right? You don't have to always implement your blocks. Did you find that by making this new feature you were able to already use it in WhiteScode? Or is this only something that enables people who write? their own blocks to use.

Speaker 1: Only their own blocks. Because just like I think Django's built-in fields, Wagtail's default blocks are really low level, really meant to be the foundations that you build. build other things on the content model itself in Wactel is really up to the site implementers to decide side by side Maybe we'll find more opinionated blocks to add these to in the future. But yeah, those types of settings sometimes We try and uh encourage people not to have them at all, just have fewer decisions to make in the CMS. So you have to be careful introducing things like these. uh by default.

Speaker 2: But we do have one example uh block that where we have some opinion which is the new image block that we added recently so that images have to be accompanied with an alt text or you mark it as decoration.

Speaker 1: Yeah. Um this this is a really cool project. I was just showing the the public version of the roadmap on our website, but behind the scenes in GitHub we can also see the whole history and um image block improvements that's been one recent improvement where we really wanted to be more opinionated to get people to better um alt text and more accessibility accessible images. Images that might sound like a really simple feature, but there's lots of nuance in how you render them and how you structure the data that actually make it quite good, I think, for us to be more opinionated. Yeah, this is the this is the behind the scenes roadmap for people who haven't seen this before. If you want to see what's happened up

Speaker 1: over the past few weeks. Anyway, really cool. I'm sure lots of people will love this. I see there's some love for the feature in um in the chat. from um Dan Braggis who says looking forward to this settings layout oh my I think lots of people will feel the same and with that we'll move on to our AI checker concepts uh which Baptiste really wanted us to talk about next. This is much fuzzier as a feature. There's not been decades worth of requests for AI checker concepts Surprise, surprise. But we think it makes lots of sense to work on this. When I say work on this and it being on the roadmap, just want to be very clear that

Speaker 1: all those AI features they live outside of Wagtail Core. We have no interest in adding AI dependencies to the core package. They will be for us to implement in our WhiteTail AI package, which is completely opt-in. And uh there might be changes we have to make in WacTelcore to support those types of customizations, but they wouldn't be AI dependent. So here specifically it's uh iterations over some of our recent AI features. Um over on the on the right side of this UI we have content feedback and right now the AI package on only supports one feedback prompt for the whole site. We felt like it would guide people towards better higher quality content.

Speaker 1: if we made it possible to define multiple types of feedback in there and request uh which feedback you want at different points in time. When you're close to publication, you might really want to get an accessibility check or an SEO check. You might not really want to have the AI tell you again about your tone of voice, how good it is. or no. And um yeah underlying capability in Wagtail is uh being able to more easily retrieve the page content that that powers those features. And that could be really useful whether your custom check are AI-based or are not AI-based. So for example, if you wanted to integrate with an accessibility checker , you can go much further if you can retrieve the whole of the content in a good format

Speaker 1: and um readability checks like the one we introduced in the last release this readability good here there's room for much more advanced checks if you integrate with bespoke tools rather than a very simple um built-in formula Do either of you have questions about this?

Speaker 2: Not necessarily questions, but I think

Speaker 1: More of a comment.

Speaker 2: Yeah. This will also mean you you will be able to trigger the accessibility checks on demand, right? Instead of it being automatically run. I think it could also be useful for like um integration with the preview panel where you have multiple screen sizes. um yeah at the moment the accessibility checks is only rerun when you update some things on the page but um you might have different type of layouts and you want to checks uh check for the accessibility issue for different screen sizes so you don't have to update the page if you have that button to just rerun the checks.

Speaker 1: Yep And AI-wise , we definitely have some really strong opinions about exactly which types of AIUs we think is good for us to aim for. And it's really essential that the CMS user is in control of exactly when the AI is used, not just have it run in the background without them even knowing, without them having any awareness of how much AI they use. using um this human in the loop thing at the bottom, them deciding at what point they want the review for accessibility we had chosen in the past to do it whenever for much simpler checks where there's no AI involved, you know, grass grass-fed accessibility checks. But for the AI variants we need uh

Speaker 1: more control Matisse, what do you think?

Speaker 3: This seems interesting. I'm not sure maybe that's um an obvious question for someone who's More well versed in Wacttail, but this type of panel on the maybe it's not panel, this type of sidebar you have on the on the right side. So that's injected by the Wactail AI package.

Speaker 1: Um yeah, good question. So um this side area we call it a side panel. the side panel itself that comes from white tail core content metrics come from white tail core and we've just started to make them customizable at the like barest level and then content feedback below that will be from the AI package. So

Speaker 3: you did have to create some kind of system where third-party app could customize the Wackell's own side panels?

Speaker 1: Yeah exactly. So um We spend a lot of time with Wagtail trying to decide exactly how we want to support customizations , some customizations. it's really very low level as in like you have to override Django templates people know how to do that but it's really time intensive and some we create much higher level apis that go straight to a specific specific type of business logic. So now what I'm screen sharing is um SEO power tools concepts. Those concepts predate um AI and we really always envision that there'll be some room to customize live checks that go beyond just like data validation in the CMS but exactly how we make this information available

Speaker 1: how we make users able to trigger those checks that's still in flux as you can clearly see. So then the big question for us comes to the UI. It's actually quite tricky in our experience to get package developers to create bespoke UIs like this So we have to make some really hard choices on which UI components we do in core for the benefit of those fancier packages. I see a question in the chat. The AI checker, can it be integrated with local AI API like OLAMA? Yes, definitely. This is very important to us. that you can use any AI provider, any uh AI model with those providers

Speaker 1: and open source AI in particular and uh that's developers who want to try this out don't have to go for one of the big services. So OLAMA definitely built-in support. It's just as simple as configuring the un point. Personally I use LM Studio and these days I'm looking at the equivalent from Microsoft. I think it's called Forge Local, just because that has supports across um all operating systems unlike Olam and Adam Studio. Um okay, we'll move on in interest of time. Um do you want to go still reverse? Right to left, do we talk about autosave or lm. txt? Baptiste, what do you prefer?

Speaker 3: Let's do model search improvements

Speaker 1: Perfect. Model search improvements. I know less about this one, so I'll be much briefer. We have been wanting to improve White search for a while. Lots of people would like to see search improvements. But there is a big but those search features don't come for free, they're really hard to maintain and this has primarily been the refactoring so far. We've introduced this new package called Django Model Search. When I say we, I don't get to take much credit for this. It is almost entirely the work of two Wagtail contributors. Carl Hubbley who built this initially outside of the Wackell ecosystem

Speaker 1: and my Torchbox colleague Gasman, Matt Westcott. um who has been supporting those such features in Wagtail itself and um they spend time moving those features to a separate Django package that isn't Wagtail dependent that Wagtail then reuses internally And I guess the point there is those features are available and useful on lots of types of Django projects, not just Wagtail specific. There is very little in how the search works that has to be Wagtail specific And uh we wanna it it really helps to move to a separate package to maintain the code better. Um But I guess I guess the next step coming back to this roadmap item would be to have more of those uh

Speaker 1: advanced search features within that package for us to reuse in WacTL This is really vague right now as a robot item, just because uh we don't really know how much time those things will take and um don't really want to commit to any specific improvement at this time. just you know more work within that uh area is that a fair explanation sage

Speaker 2: I would say so yeah um Yeah, I think the bulk of the work was done in the last release for separating it out from White Tail itself. This is one of those packages that we split out so that the wider Django community can benefit from. I think It would be interesting if there is any interest in the Django community or for like ideas on how to improve the key service. mechanism mechanism

Speaker 1: yeah they tend to be really popular actually those packages that aren't like wagtail centric that we have have model cluster being one of the big foundations under how Wagtail works, Willow being a wrapper around our image processing. And um yeah, query-ish as well, kind of an opinionated way to um emulate the query set API for other data sources. And um I mean even WhiteLai now we have our Django AI core package, right? That is meant to be as a kind of um generic foundation for how you add AI features on Django projects. regardless of them being Wattel or something else.

Speaker 1: Battist, any comments about the the place for those packages in the Django ecosystem to know about search outside Wagtel, how this is done and how much improvements there is to be.

Speaker 3: I actually did some work on a on a client project a few months back where we had to go quite deep in the internals of the research to add got some support for a feature And I think having a separate package where we could potentially have this feature live is great. I in a previous life I used to maintained the website of the popular phyton web framework called Django and I think this type of uh library could be very useful because search is one of these tricky um It sounds simple, but when you want to do it at a reasonable scale and what something like Django has kind of a

Speaker 3: Long history, it's a very old website with lots of content in different types of formats, different type of models. Wagtail search, I feel it's it's a very right level of traction for doing this type of thing Just for reference, for example, here in this search, you see this Django website tab at the at the top of the search. This is a very, very new feature that was implemented by combination of Sarah Boyce and Tim Schilling and many contributors that lets you search the the content of the site which wasn't possible before because Our search was built as a documentation search originally. That's all you could search is the documentation, but there was a great need for wanting to search other things

Speaker 3: and I think White Tail searched. or Django model search rather could enable us to make more things searchable in kind of a nice generic way. So I'm excited for this

Speaker 1: Great. Um yeah, I wanna say one more thing on this, uh which is that um even though this roadmap i time is already there again it's really like open-ended so those roadmap i times we definitely encourage people to go in there and add comments in um in the GitHub issue and uh give us the feedback on exactly in which ways this could be helpful. So when I say give us the feedback, even like describing a use case for a package like this for work. like this like you just did that's really helpful feedback because then us when we have the discussions about the features we can refer to those use cases and It makes it heaps easier to reason about what to do and the value in it.

Speaker 1: Okay Two more and we'll speed up a bit. Autosave MVP. Autosave has long been on our list of desired features. Uh it's just the idea that you no longer have to manually decide when to save drafts. You no longer have to worry whether your content is gonna be saved or no. You no longer have to worry about your session expiring. Just as you type, naturally it saves your data so you don't have to worry about losing it. And um we are expecting you to make it much easier for people to work directly on their content in the CMS much safer if they have any uh worries about losing content

Speaker 1: We all I think have lost content to badly implemented web forms at some point in the future and even the web well-implemented forms. All it takes is your connection flinching for a bit and then you lose uh what you poured your heart and soul into. So yeah, just makes lots of sense. and uh with it being called MVP, uh, we've had a long, a long autosave journey on the road of the roadmap. on the map of the journey of the road of autosave. This is just one step and it takes a lot of time to get there. But yeah, the big goal for us will be concurrent editing, like multiplayer style in the CMS. Does that make sense?

Speaker 1: Okay.

Speaker 3: It's kind of like the the rest stop on the on the way to the destination.

Speaker 1: I like that scene.

Speaker 3: Getting some snacks, putting it some some electricity in your car.

Speaker 1: Recharge. Yeah. Yes.

Speaker 3: That's a break.

Speaker 1: Last but not least, lms. txt for docs. Have you both had the chance to play with lms. txt?

Speaker 2: Say again, sorry, T-B.

Speaker 1: Have you had the chance to play with lms. txt files?

Speaker 2: I haven't. I've been reading about it. like mentioned here and there a few times but I've never actually played around with it and see

Speaker 1: yeah

Speaker 2: any different if it makes any difference

Speaker 1: Well, it does. We're really blessed by the AI gods in the Django and Wacta World. We're really lucky that they've slept all of our grass -fed content, all the books that have been written about Django, all the Stack Overflow questions and answers that people have poured their heart and soul into. Because AI is really good out of the box as Django because of all of this as well as you know the AI models learning how the Django project does engineering. The result is Django people get good results without any effort. But if you really want to try to get your AI coder assistant to work with the Django 6. 0 features, to work with the latest Wagtail features. It's gonna work 10 times better if it has direct access to your docs

Speaker 1: for the latest versions. And the way to do this is lms. cxt So basically Sage for block settings if you want to speed up adoption of the new feature which will definitely help people. they 'll uh have a much easier time if the data is available in this kind of LM friendly format. Um so that's the that's the goal I suppose um allow people to have better results with their coding assistance. I already know how much we want to encourage people to vibe code their Wagtail sites, but I definitely like the idea of those new features we spend a lot of time curating, refining, making it easier for people to adopt them.

Speaker 1: for something like the Django 6 release notes, I don't know how you all manage your Django upgrades. Take some time to review the release notes and make sure that uh you know exactly what might change And MMs are really good at doing a first pass of that. They give it the release notes in Markdown and then it gives you exactly like a report of what you might be wanting to consider. So yeah, I guess for Backtail we want to have it as a feature of our developer docs and of our user guide websites as well. We spend a lot of time curating the content of the guide, organizing it into different pages. But I think the reality is lots of people who use Wagtail, they only use it like maybe an hour a week, maybe an hour a month as a stakeholder,

Speaker 1: will really help them to have quicker access to information on how Wagtail works And we're hoping that's some kind of AI integration, like obviously again, like an opt-in, optional integration, uh, will help those people get to the information Does that make sense?

Speaker 2: Yeah, uh yeah just yesterday I was starting to test the block settings feature that I worked on on and there are just so many different combinations that it can be used so I just fed the uh fed an LLM the documentation that I wrote and asked it to test all the different cases and yeah it especially for like generating this just you know test projects it was really useful um I'm not I can't speak whether it would be any good for real life projects but I guess with with better documentation it might be

Speaker 2: um even better.

Speaker 1: Yeah. And hopefully it helps the um humans steering the ship too.

Speaker 2: Yeah.

Speaker 1: And that's it for February.

Speaker 3: That's what symbol. No, sorry, it's not a ship. We're the ships don't use roads.

Speaker 1: It's a bus name. Is it a bus? Are we on a bus? It's a boat

Speaker 2: mobile.

Speaker 1: Um yeah, February, that's the roadmap. We do have a few other features coming up. I'm gonna give a shout out to a couple of them while we're here. Um Baptiste recently did the right thing and took his uh I guess longing for a feature to the best logical step in open source which is to upstream the changes. Hooks for settings you wanna tell us a few Key bits of information about that?

Speaker 3: Yeah, essentially it's like the same hooks that snippets have, but for settings. uh only when it's relevant so snippets have a lot more hooks because you can create a snippet or edit a snippet but settings you can only edit them so essentially they have Some hooks that weren't there before makes it easier to customize your settings edit page in the admin.

Speaker 1: I don't know how I feel about the after edits being documented before before edits.

Speaker 3: You have to take that up with the English language. It's alphabetical.

Speaker 1: Oh It's a good reason, but ugh. It hurts. Nice one, Baptiste. That's really cool.

Speaker 3: It would be the same problem in French, so we have to find a different uh language that sorts the word before before the word after

Speaker 1: It's um it's a really nice thing. I think um that's uh been a long-term theme for us, and when I say us probably you stage more than anyone. to get the features we built for pages in Magdalene initially and then replicate them to other types of models with the the snippets and arbitrary models being like the obvious target but also settings as well Like we released preview support for settings, thanks to work from uh Sebastian Corban not so long ago, right? Yeah. So really great to see this.

Speaker 3: And it's a testament to what you're saying. This was actually very easy to implement. I think there's more documentation than code and more test. The code itself is just a few lines because of the way that it's structure where everything essentially uses the same uh Python views underneath. Yeah, that's that's the code. You know it was It was very easy because of this work of extracting what was space specific to something more generic and then can be reused. I think that shows you the payoff of that. So

Speaker 2: class-based views is the go.

Speaker 3: That's that's one of the power of classes, they're easier to extend than functions, but they're also easier to make it a bit bit of a mess Maybe that's the subject for the next next one. Like optics functions versus class. That's a long debate in a Django in the wider Python world.

Speaker 1: I like that idea. Alright, I'll just uh shout out one more to wrap it up. I think something that I really liked with this pull request as well was just uh Again with how little code it is, it's definitely easy for people to not realize that if they get up to speed with open source, they can make those improvements that they'd like to see. So that it's not that much work at the end of the day if you have been in that mindset before. And um a similar one is um our file size For the AVIF image format, which is one of those modern formats with support as of like about a year ago now. And someone saying like, hey guys, it's just um Way too big those images. Why is the quality configured like that?

Speaker 1: And I'm hoping we'll be able to lower the quality for equivalent. results for uh real-world users and much lower file sizes in the next release and uh that's thanks to the research that's been happening in this github issue so still some decision to be made there but um yeah really promising as a as a feature that will as a change that will ship in the next release even though it's not on the roadmap And yeah, May soon after and maybe we'll discuss this next time. And with that , thank you, Baptiste. Thank you, Sage. It's been fun. Any parting thoughts before we leave?

Speaker 3: I don't have any parting thoughts.

Speaker 1: Sage, what about you?

Speaker 2: Um yeah, I I just want to say thank you for anybody tuning in and be uh all of these like pull requests and issues, it's not only for us to discuss but also for you. So if you if you have any interest in all the the things that we talk about or like if you have such suggestions for future um releases uh be sure to post something on our github and maybe we put it on our roadmap.

Speaker 1: Love that. GitHub issues, definitely good place. GitHub discussions if it's more open-ended. Social media very happy to help people like triage towards the right discussion venue. Don't worry about it. Any place is good. And um yeah if you wanna keep tabs on those features outside the roadmap, just be aware of what's shipping when. Um quick plug for our sponsor, the Wagtail newsletter uh white. org slash newsletter and uh with that thanks it's been fun

Speaker 2: okay

Speaker 3: thank you