What’s New in Wagtail CMS | Release 2.12 | Telepath, Webstories, Commenting & Documentation Sprint

Speaker 1: Hello everybody and welcome. This is our third instalment of What's New in Wagtail, so it's brilliant to see so many of you joining us today. So I'm Lisa and I head up our events at Torchbox, including this one and so I'm always interested to hear any feedback that you have and any suggestions or topics. And I am delighted to introduce our speakers for today. So we have Tom Dyson who is a Torchbox co-founder and our technical director and heads up the Wagtail tech team as well, or who's a Wagtail lead. Tom 's going to be taking us through the results of our survey from last year and what functionality has been implemented following that. We also have Lara joining us today and she is a graduate developer at Torchbox and she's going to be sharing the results of our documentation.

Speaker 1: Sprint from a couple of weeks ago. We've also got two people who you might be familiar with already, Matthew Westcott, otherwise known as Gasman, and also Carl Hobley, and they are senior developers and Wagtail consultants. We also have Jacob who is a developer and Wagtail consultant as well. So we've got 60 minutes for the session and we've got quite a lot to get through. So we're going to have time for at least one question after every section so please do use the chat and the Q<unk>A facility and for any that we don't manage to get to we'll answer them at the end or if we run out of time completely then I will follow up with an email and send you all of the answers afterwards. We are recording this today as well because there is quite a lot to get to. So if you need to watch it back afterwards you'll be able to. And I think that's

Speaker 1: about it. So I will hand over to Tom to get things going.

Speaker 2: Thanks Lisa. And it's just a question from Al here and just to want to reassure you that you are all on mute. So when you're kind of participating in a webinar like this we can't accidentally hear or or see you. So uh don't worry about that. Um so it's been uh it's been an exciting few weeks for for Wagtail. Um there's the the new release which I'm going to talk about in a minute, but also some some some very exciting sites have launched and in particular one that you might know about uh by jpl so uh we had a hard deadline for this site but um which was time to to be ready in time for for the mars landing So we're all it was an incredible experience for us to be to be watching the Mars landing through the Wagtail site that um that was launched earlier this year. And I know there's a couple of people here from JPL on the call. Uh if you haven't seen the site already,

Speaker 2: It's at uh jpl. nata. gov and uh it's something we're all very proud and excited about. Um but uh I also want to tell you about some some of the other changes that that uh some of the other improvements in Wagtow recently and uh got a very short presentation to show on this. So you you're probably aware, I hopefully aware that uh 2. 12 came out pretty recently, um a couple of weeks ago and uh Although the previous two releases, 2. 10 and 2. 11, were really bumper releases, probably the biggest two that we've had in Wagtail's history And 2. 12 doesn't have quite the same number of uh kind of amazing standout features. But nevertheless, it's a it's an exciting upgrade and one that I hope those of you who are already using Magtel will upgrade to quickly. It's an easy upgrade as usual.

Speaker 2: It supports Python 3. 9. So we've always tried to keep track of the latest version of Python. In this case, 3. 9 came out in October. So we're kind of shortly afterwards we were able to have official support for it. We have a new type of permissions, which we'll I'll mention a bit later, but this is a step that really helps Wagtail become a kind of fully fledged multi-tenancy system. Something that sounds maybe a bit more niche and technical is in-place stream field editing. And this was a kind of uh under the hood change, but actually it uh opens up some pretty interesting possibilities within Wagtail. For example, the ability to create new stream field components on the fly when you when you save your pages. And then other changes like this is a really interesting contribution from someone in New York

Speaker 2: who may be on the call. I think his first big open source contribution. And it's a really cool one. It's a uses some features of CSS that I didn't know about and it mean makes it really easy now to theme your your admin site. This could be useful if you have a staging and production environment and you want to make it really clear about the two versions you're in, for example And as usual, there's a collection of performance improvements and accessibility improvements. And we're really, you know, this is kind of a constant direction for Wagtail, just that when you upgrade and things just get better. We ran a survey last year and um I'm sure some of you participated in it. It was it was pretty wide ranging. Lots of lots of participants from around the world, mainly people who are using Wagtail

Speaker 2: already. And we backed that up with doing quite a few in-person phone calls and interviews to kind of get deeper into the subject And there's some really interesting results, but uh these are the top-level things that that people wanted. These are the priorities that people had. And uh it's quite a big list, but I'm really proud that in the last six months we've delivered on a lot of it. And I should say that's that's with a lot of help from the community and with from generous sponsors. So internationalization, this is the big one. And uh those of you who came to the the last What's New Imaged in Wagtail webinar will have seen the uh amazing localized feature, which I think makes Wagtail now really like best in breed for uh for open source content management with with translations.

Speaker 2: And um we're really grateful to Mozilla who who funded most of the work on this because they needed it on their own sites. There's also been a quite a push on the page editor rewrite, and this is less visible, and this is something that Matthew's going to talk about in a minute But this is some kind of refactoring about the way that White Town, particularly the streamfield editor works, that's gonna open up. um possibilities for some really interesting work. And so that is largely done. And that's thanks to Ugov who who sponsored that. And it it makes things like live preview and Wagtail admin API, they're not, they're not there yet, but they 've been unlocked by this work and that's really exciting for us. Workflow is another feature that was on that was kind of top

Speaker 2: high high priority for a lot of people. And that's been delivered. You'll maybe remember that from Wagtail 2. 10. And that was sponsored by Motley Fool, who's been fantastic support for Wagtail over the last year. Multi-tenancy, this is the choose permission thing that I just mentioned. This was another contribution, but not uh this was a contribution in code and um and this comes from Caltech. I think some Caltech people on the call here. The uh multi-tenancy has been an important requirement for them from the beginning. They had their own solution for it and and now they've contributed it to Wagel and that's that's really fantastic. We're really grateful for their help on that. And then finally, there's a continuous push towards improving our accessibility and our documentation. And neither of these are features which we can never say

Speaker 2: are finished or complete, but they're things that we we continue to push forward on Accessibility has been there's been a lot of progress on this over the last year. We had an accessibility sprint last year and more recently a documentation sprint, which Laura's going to tell us about later. In these cases, there's been a huge amount of work from the growing community around Wagtail, and that's something we're we're really grateful for. But next up, I'm going to hand over to Matthew, who's going to talk about the Streamfield Rewrite.

Speaker 3: Okay, yep. So um so yep, uh so Screenfield is uh one of the most enthusiastically adopted features of Wagtail uh the the model that it gives you of uh mixed blocks of different kinds of content that you can arrange in any order is one that finds really widespread use in content management in ways that we may not have anticipated when we first built it, which is really great to see. But it does mean that As people have got more and more bold with their use of Streamfield, the technology has sometimes struggled to keep up with people's ambitions. So if I share with you an example of this, which perhaps represents the worst case scenario for

Speaker 3: Streamfield Performance, you can see we've got various uh different block types. From sort of plain paragraphs to block quotes, calls to actions, embedded videos, carousels. And we're allowing the content author to arrange these intersections of three columns here then one column then two columns uh and if I show you the uh code for this uh you can see we've got sort of uh the half a dozen or so different blocks defined here, which are all put together in this stream, and then that stream can appear in sort as in in any of these positions, either as a single column block or on the left or right of a two-column or left middle

Speaker 3: right of a three-column. There's a lot of nesting going on in this definition Now, this isn't something we'd really encourage people to do, having content editors have control over their own page layouts. That's something that we say is better done in the template within code But nevertheless, this is something that the data model permits, and so it's only fair that the Wagtail editing interface should support this kind of setup without it falling over. So if I go into the editing interface of this, hopefully I'm still logged in here. Yep. And if I click on the edit uh page for this you'll notice there's a few seconds before it even responds to uh that

Speaker 3: uh before it starts serving this uh editing interface and then again a few more seconds for that to load um so before it's uh fully usable. And the reason for that is the amount of uh content that's being the uh that's being transferred here, just the amount of HTML, I think there's close to a megabyte of HTML here. And that's because the Streamfield editing interface is at its heart still a traditional Django web application. where everything is being rendered server-side. So all of these content blocks, these form fields, those are being rendered to HTML on the server. and and sent over to the client. And yep, there are bits of uh bits of uh JavaScript

Speaker 3: involved here um for for the dynamic elements being able to insert and delete blocks. But it's all implemented in this kind of very primitive way. It's kind of uh it's kind of like an extension of the server-side code where it's just defining when you click on this uh this button here, insert this. this block of HTML. And that means that not only do we have to have all of these form fields sort of as part of the page rendering, we also need to include every place where a block could potentially be and since we've got six or seven block types which can appear appear in each of six or seven different positions, then that sort of adds up like 30 of these things. It all sort of spirals out of control pretty quickly.

Speaker 3: And yeah, it's all written in this uh way that's only really understandable to back end developers. It's certainly not something that a front-end developer could easily work with if they wanted to. implement new features like copying blocks. And for a while it's been clear to Wagtails core developers that the way out of this root is to shift the heavy lifting onto the client using a framework like React to manage the data model in the browser. And in fact A previous attempt at this problem was uh Bertrand Bordage 's uh crowdfunded React Screenfield uh project, uh which was to uh other than as the name suggests, to to re-implement the stream field interface using React.

Speaker 3: And in fact this has led the way for a lot of the uh design elements that made it into uh both the current implementation of Screenfields we uh um we sort of Implemented the visual design of this a few releases back, but also it's informed the way we've built this new implementation that we're going to be showing today. But this uh approach rewriting everything in React comes with its own problems, particularly around backwards compatibility, because uh a lot of these uh form elements like these choosers They're written in this sort of in a way that's very much rooted in the Django world, where they're designed to be rendered on the server.

Speaker 3: the JavaScript code doesn't know sort of what this thing here represents uh or how to how how to extract a value from it or to populate it with a value. It's just a bit of opaque HTML. Uh and we didn't want to say, okay, right, we've got to throw away all of this Django widget code and rewrite it in React now because we've invested a lot of time in building these components as part of Wagtail. And also so have you in the Wagtail ecosystem and the Django ecosystem. So what we really want is something that allows us to keep our business logic that we've written in Python classes, Django widgets. Wagtails, streamfield blocks, and push that data model over to the client.

Speaker 3: And that something is a new library that we've created called Telepath. And uh if you're familiar, so for the uh uh Python developers amongst you with the uh Pickle module in the Python standard library, which allows you to take a complex uh Python object, serialize it to be written to disk or perhaps stored in a cache, and then sort of later to you read that bag, unpack it again and get back the the complex Python objects again, then uh telepath is um more or less the same thing except that you're Unpacking it into JavaScript objects on the client side. Now this process isn't magic, it won't translate your Python code into JavaScript automatically But it does mean that

Speaker 3: when you've written your client-side JavaScript logic, you can set up a one-to-one correspondence between your Python model uh your Python data model and your JavaScript ones. So where the Python side code knows how to retrieve the data from the database and do the static rendering and the front-end templates uh uh rendering, then the corresponding objects on the browser side know how to render these blocks dynamically. and deal with these interactive elements like reordering and adding and removing blocks. So um Since we announced first announced telepath, I think there were a few questions about what this means for people building Wagtail sites and Would they have to replace their stream field definitions with telepath field or anything like that?

Speaker 3: And the answer to that is no. So everything I've described here is internal Wagtail code. This is something that has helped us to build the new implementation of Streamfield, but it's by no means something that you would have to uh to get stuck into yourself. If you've built your uh if your Wagtail site using the sort of standard stream field model of uh taking the built-in block types and building those up into structures and streams, then This will be just a straight upgrade, no need to rewrite any code. So if I bring up the uh uh Wagtail Bakery demo project And hopefully this is going to behave because it's uh when you're switching between different different implementations, it can get a bit fiddly.

Speaker 3: Hopefully that's going to let me log in. Yeah, so uh so if I uh go and edit um one of our Screenfield pages, and as I say, this is there's been no code changes to this the demo project And um this uh behaves uh pretty much the same way as uh as you've seen uh the the the existing stream field implementation. But the sort of differences , what this means for you as a site developer is that you'll get the performance boost from not having to render all of these things server-side. um in our tests. This is something like sort of 30 to 40% faster to render and much smaller data transfer.

Speaker 3: because all of this is happening client side. We're just passing in an optimized definition of the screen field and the data, and the client-side code is smart enough to do the rest. And perhaps more interestingly, having the front end work directly with this data makes some new functionality possible. including uh being able to uh duplicate blocks. So you can see that's uh picked up the change there because uh it's a we the front end code now has uh a concept of what this block contains and extracting the data and uh pushing it back in into populating this new block and also being able to uh to collapse blocks and get this uh little uh sort of preview representation.

Speaker 3: Which again is pop uh possible because the front-end code knows the data that these blocks are representing. Um so while the um the details of uh of telepath isn't something that uh developer will tip typically need to concern themselves with if they're just building things in the standard way. This is going to open up a lot more possibilities for front-end developers to uh to to build extensions uh that that are uh sort of following uh a well-defined uh front-end code uh API. because there and this is something that front-end developers will be a lot more at home with because they're working with this data as a rich client-side app, not just as an offshoot of the Django code.

Speaker 3: So everything here is uh on course to be part of the next release, uh Wagtail two point thirteen, all that's really remaining at this point is developer documentation and a bit of final UI polish. But really this is just the the start of uh of what's possible with uh to im improving the front-end UI of Screenfield because what telepath brings for us is a new approach to increasing the richness of the client-side code And that's going to open up new possibilities within Wagtail and indeed in Django development in general. So I'm sure we're going to be seeing uh a lot a lot more of uh outcomes from this work in uh future releases.

Speaker 3: Okay.

Speaker 2: Thanks, Matthew. Some questions coming in and one from Eli. Would telepath make drag and drop more possible?

Speaker 3: Uh yep, that's uh we've kind of got that as a bit of a uh stretch goal um with the the uh it's uh we're hoping this can get us But yeah, that's uh one thing that we're uh we're hoping to uh get in um again because uh where where uh we would we've we've got uh more the fr front-end frameworks at our disposal where we're not try having to rig rig that up within the the old school Django code. Yeah

Speaker 2: I'm glad you asked that, Eli, because that's exactly the kind of thing that we want to achieve. Another one is something that we were shown in the last Wagtoff space by the New York public radio team. We had a great demo of this. Uh and they've they've built this cool thing for splitting paragraphs, and uh that's something that we should be much more achievable now. There is a question from Bill. I'm just scrolling up a bit now. About, let me find it about Caching, I think you probably asked this, answered this afterwards, but regarding delays and stream field editing, is there a cache for the info once once retrieved I think that's sort of been handled now probably by the explanation. Hope Bill that what Matthew went on to say is okay.

Speaker 2: Caleb's asking, uh, do we need to write React for each new modern block?

Speaker 3: Okay, well the um yeah it sh it should be the case that if as I say if you're building things up um sort of uh as in uh the standard uh just buildings up from the building blocks then there should be no changes. Um if you're doing anything that's doing Those of um JavaScript heavy things. So an example might be if you've got a a map uh uh a a location choose away or clicking on the map. then um that that would involve writing uh a bit of an of adapter code to tell the front end code this is this is how you populate this with a value and get a value out of it. It's not dependent on React. This is um using the um just plain uh JavaScript um

Speaker 3: objects. But it's all kind of very sort of, yeah, we've made kind of as low level as possible. So uh it should be yeah possible to build uh new components in React as for example Draftale is. So uh yeah it's definitely not a requirement but it's possible yeah

Speaker 2: Thanks, Matthew. I just want to just kind of clarify that as well. There's a question from Chris Wedgewood on is Wagtail aligning with React. This is just about how we're building. this particular part of the the the back the admin api it's got nothing to do with how you how people build their their front end sites so work to remains remains completely agnostic on that front There's lots of incorporations coming in, but we're going to have to keep moving on to the next one. But please do keep asking questions and we'll try and answer them through the Q<unk>A system. Next up though we have Jacob who's going to talk to us about commenting.

Speaker 4: Hi everyone. So commenting in the Wactor Admin has been something we've been interested in for a while now, and we've taken several steps towards it in the past First, with an extension called Wagtail Review that some of you might have installed, that let you leave comments on the preview of the front-end version of a page in Wagtail That was really useful. But it had several downsides. And I'll show the review repo in just here. You could only comment on the preview, so you needed to switch out of the editing experience in order to do so And it was difficult to carry comments forward between revisions because they were attached to the front end. Then last summer we took another step with the release of WagTel's new configurable moderation system, workflow. In this, when moderators approved or rejected a page, they could

Speaker 4: even overall a single overall comment on why they were doing that to give an idea behind their reasoning. So if I switch over here. You can see if I request changes, I can add a single comment. However, what if you wanted to add kind of more granular feedback? If your comment applied to just a single field on a page, or even just a single word or phrase inside that field So to address those um those issues and uh to uh fill that gap, we've been looking at build uh bringing uh Microsoft Word or Google Docs style um commenting into the Wagtail editor itself. And this has been sponsored by Motley Fool, so many thanks to them. If you're here at the last What's New and Wagtail webinar, you might have seen some of our initial designs for that

Speaker 4: So I'm going to share the mock-ups again and you can see a few little tweaks to the designs. And then I'll show you the progress we've made or been making on influencing the commenting itself. So here are the mock-ups, as you can see the comments have a light theme and they're on they sit on the right side of the page, floating in line with the field they're attached to. The top comment here shows a field level comment, a comment attached to a field as a whole. And on the rich text field below, you can see the button where you might add an inline comment. And I'll show you that more when we go on to the implementation later. So first on the design, let's just quickly see the flow of adding a comment. So clicking to add a comment next to a field

Speaker 4: and having it float alongside. Comments will be saved along with the page. So now we've seen the mock-ups. I'm going to switch over to my real Wagtail demo site and so you can see the progress we've been making on this so far So here I am inside the Wagtail Bakery demo, our standard Wagtail demo site. You'll immediately notice the comments here have a dark theme. This is something we'll be changing to reflect the designs. as we move forward towards the natural release. So you can see here an example of a comment thread attached to a field level as a field level comment So this is attached to the image field here. You can see by clicking the annotation we can bring it into focus.

Speaker 4: And if there were loads of comments floating on the right, this would scroll the right one into line with the field And we'll see this a bit later on. Here's the comment thread with the initial comment and its replies, and I can add my own reply here. And I'll get a little notification that I'll need to save the page to save those changes because the comments are saved along with whacktail revisions. You can see that some of these comments in the thread I have the option to edit or delete. As you might expect, these are the comments that I myself have added. So let's say I maybe want to be a bit more enthusiastic here. I can make that change. Or I don't think this is worth adding. And I could delete it. You can only edit or delete your own comments or comment replies.

Speaker 4: But you can resolve anyone's comments to say, okay, I've acted on this bit of feedback. It's not relevant anymore. anymore and I'll do that now. So here, these are field level comments, one of our two types of comments, and they also apply to stream-filled blocks So if I scroll down here to a string field and add a new image block, I can choose to add a new comment. Uh so you should be able to add those for any uh fields within stream field. But what happens if you wanted to add a comment to, as we said, a single phrase or a single word? Well, we can do that with the second part of commenting, which is

Speaker 4: inline commenting. And we're enabling that within any rich text field So I can do that by just highlighting and clicking to add a comment. Maybe I like the phrasing here. But down here I'm not so sure. Clicking each comment uh brings the right highlight into focus. Uh but similarly, since there are too many comments now on one field, they're kind of squeezing each other out of the way. So you can click each individual annotation to move the right comment into line.

Speaker 4: So that's the example of inline commenting. Again, all of these positions will be saved upon saving the page. You can also, if you've decided to um If you decided you don't want to be working commenting mode for now, you can enable or disable comments globally. And this top bar indicator will be moving over to the right of the column. We're expecting Cononcing to launch in either 2. 13 or 2. 14. So hopefully you'll get to use this feature soon.

Speaker 2: Thanks, Jacob. That looks great. I'd be interested to know how many people think they might use this feature. Maybe you could just say in the chat if you think this is something that you or your editors might find useful. Oh good. Nice to see him. Yeses there. Validation. No immediate questions on this. Do if you think of anything, please do ask them and we'll try and get around to them. But um otherwise I'm going to move back to Matthew and Web Stories.

Speaker 3: Yeah. So this is something that we've been uh working on with Google as uh part of uh their uh AMP uh project um to sort of bring sort of uh more the uh lightweight streamlined uh the version of HTML uh to the web that's uh sort of optimized for mobile And uh one feature there bringing to this, uh bringing it to AMP is uh the uh idea of uh of uh con presenting content as stories. Um as you this is the format that you might well have seen uh in the likes of uh uh uh of uh Instagram and uh ev every other sort of uh social network under the sun is uh of jumping on the bandwagon too. It's uh this um sort of slideshow type presentation.

Speaker 3: Let's bring up this one from uh CNN and uh see this is uh mixing of various different kinds of content, um the videos and images and text and um and and with uh so with google being uh avid users of uh of wagtail um it's uh the uh keyword google blog is uh implemented on wagtail they were keen to showcase uh web stories uh on there. So uh we've uh built uh uh an uh add-on for Wagtail an add-on package that will uh make uh possible Now there's uh several um different uh packages available that will let you compose stories. Generally they're done in this uh design-oriented drag and drop way

Speaker 3: kind of not a million miles away from doing the PowerPoint presentations where you've got a lot of control over sort of the positioning and the sort of design of the of the slides. And um We chose not to try and turn Wagtail into another of these design tools as uh Wagtail strength is really in structured content following uh a fixed template. So instead the um sort of the mode of operation for this is the uh ability to import web stories that have been uh created elsewhere So um if I uh go to our uh uh White Tail instance here, this is uh White Tail installation that has uh our uh web stories plugin and uh Wagtail Media

Speaker 3: uh uh installed and uh this is a story that we've uh previously imported uh and The the uh so there's uh again there's various bits of uh the video and uh image content that's been uh imported into the Wagtail Media Library. So we've got both the images here and the video files And if I show you the process for importing a new one, there's one that I sort of picked out that was uh From the BBC about uh junk that's been left behind on the moon. Uh so if I uh paste in the URL of that one, I'll select our story section

Speaker 3: and import there and then that's going to take a few seconds as it's pulling these images from there and then you can see we've got a local copy of this story It's now uh part of our Wagtail site. And uh well, so what the things we can do with this uh um since these stories have the well-defined metadata in Including a poster image, we can sort of use that to build up these automated listings in this nice card layout. Another thing that we can do is embed these into our standard non-AMP pages. So if I go into our

Speaker 3: blog section You can see there is a blog post in draft that I've been working on 10 things you don't didn't know about the moon. And this is uh implemented with uh screen fields in the usual way. And I've defined a story embed block here. So If I select our moon story and then preview that page, then you can see that is now displaying in line in this blog post page. So this is uh is implemented as uh an add-on that works with uh current uh versions of Wagtail. This is the sort of Wagtail Web Stories package and We've got the documentation on

Speaker 3: how to integrate that into your own sites. So if your audience is in the Instagram generation and you're keen to ride the wave of what might be the next big thing in web publishing, then why not give it a go?

Speaker 2: Thanks Matthew. I hadn't uh I hadn't come across web stories before this project, but um it looks uh looks really cool and uh It's great that it's so easy to embed directly into Wagdale now. Next up we have Laura who participated in the documentation sprint and is going to tell us about how it was for her.

Speaker 5: Hi everyone, I'm Laura. I'm a graduate developer and I joined Torchbox in January this year. I'm going to talk a bit about the recent documentation sprint and then I'll show some of the key goals and outcomes by comparing how the page looks now and how it will look in the future. And in this sense, when I talk about a sprint, I'm talking about an open source code sprint rather than an agile methodology sprint Before starting my role at Torchbox, I'd heard about sprints and I was really interested to see how they work for two main reasons. Firstly, I wanted to see how they worked in terms of sketching out some of the challenges, and then collaborating together to find solutions to these challenges. And the second reason is that I wanted to learn how it could be completed in two days whilst also being faced with the challenge of working via Zoom and also in different time zones.

Speaker 5: And the way this sprint was structured was that we started off by having a talk by Daniela Prashida, which focused on how best to approach writing documentation. We then split off into groups of two or three based on our preferences of what we wanted to work on. And at the end of each day, we shared and demoed our work and provided feedback to each other. And so here are some one of the first changes we made, which was reworking the Wagtail documentation site theme. And this was to make it easier for users to move around. And on the left hand side, you can see how it looks now and on the right hand side how it will look in the future. So the way we did this is that we built upon what was said by Daniele

Speaker 5: and put clearer and more descriptive headings on the pages. Further, you can see the sidebar on the left is now able to be accessed without refreshing the page. And on the right hand side, you're able to see the main content headings within the page, which means the user doesn't have to scroll the whole way through And the outcome of this is it looks a lot cleaner, it's more user-friendly, the headings are more purposeful, and the navigation is clearer for the user. Another change that we made, and this is actually something that I worked on, was establishing a clear writing style for the Wagtail documentation and providing guidance on how best to write the documentation. And again, we use Danielle as methodology to provide clear differentiation between tutorials, how-to guides, explanations and references.

Speaker 5: For example, a tutorial should have clear actions and outcomes for user and the user should be able to complete it without any prior knowledge of the subject Whereas a how-to guide should or can assume some basic understanding of a topic and should answer questions that only someone with a bit of experience is able to ask. The outcome of this is that we wrote documentation, which provides clear guidance about the language, formalities, and expectations to be used in the different documentation styles. And hopefully this will ensure that when tutorials and how-to guides, etc. are written, they're pitched at a correct level for the user and provide the correct type of information. And another feature we made, which I think is really cool, is creating a

Speaker 5: faster and more accurate search widget, which provides better search results to a user. The way we did this is by using Algolia Doc Search. As you can see in the example, when typing first, my aim was to look for my first Wagtail tutorial. The updated search on the on the right hand side shows a widget which has the search result higher up. And also what you can't see in this picture is how incredibly fast the new search is And the outcome of this is that it provides a better and more meaningful user experience. And also the search function provides search analytics for Wagtail maintainers, which is Great because it means you can identify which topics are or are not frequently searched

Speaker 5: and which searches don't provide many results and as a result you can change the docs accordingly. And this slide shows all the pull requests that were made over the two days and some of the contributors are shown on the right hand side To me, it really demonstrates the inclusive nature of the sprint, and this is because loads of these pull requests were made by people like me who have never contributed to Wagtail before and also by a lot of people who Maybe they wouldn't consider themselves to have a tech background. And overall, I really enjoyed the sprint. I learned a lot about Wagtail. It was great to work with people internationally, and it demonstrated how powerful collaboration can be in making what I think were really impactful changes in a short space of time

Speaker 5: and I'm really looking forward to getting involved in more open codes, open source code Springs.

Speaker 2: Thank you, Laura. It was a really great, really great two days. And actually I think a few of the people uh those places there are are on this uh webinar. So uh thank you to all of those of you who are here who participated. We're going to race on because we're going to run out of time. But next up we have Carl who's going to talk to us about another feature sponsored by Mozilla.

Speaker 6: Hello everyone. Yeah, so today I'm going to demonstrate the new Wagtail A B testing package that we developed into with sponsorship from the Mozilla Foundation. This package allows you to create a variant of a page which gets served to 50% of the users and the rest of the users still see the original version. And it then measures how many users of each version, of each goal that you can define. The goal could either be visiting another page, submitting a form, or something custom, like making a donation And then once that test is finished, it presents that data to a user so they can make a decision about whether that change should be applied permanently or they should roll it back to the original version. So I'm just going to share my screen now. Here we go, can you see that?

Speaker 6: Yep, thanks. Yeah, so this is the Wagtail Bakery demo that we normally use to test um new Wagtail features. So on this demo I've got the Wagtail A B testing package installed and I'm going to demonstrate setting up a test on our homepage where we're going to change the title. And then we're going to the goal is going to be visiting the buyer sandwiches here page. So we're going to have two variants of the home page and we're going to be measuring how many users of each variant reaches that buyer sandwiches here page So to get to do that we need to firstly edit that homepage. And then let's change that title to from Welcome to Writer based to Welcome to Writer

Speaker 6: Sandwich Shop. And then instead of just publishing the page, what we do is we go into the menu down here and we click uh save and create an A B test. So this saves a new draft. and it takes us to the A B test creation form. So we're first you're presented with the difference that you've made, so the difference between the two variants of the page. We create this test. And then next, we first need to give the test a name, a nice short name, and a hypothesis, which is a more longer description. about what we're actually testing. So does changing our name make more people want to buy sandwiches? And then we select that goal page. So if we go in here and we select buy our sandwiches here.

Speaker 6: And then the actual goal event itself is set to visit page. On form pages is also submit form page as well. And then you can also define your own custom goals. And then finally we need to set the sample size. So it's important to uh select the sample size correctly based on how many um views you typically get and the amount of variance you're looking to achieve in order to you know have a successful test. There's a few tools that we've linked here for deciding this, but today I'm just going to type a thousand. We've also got a few little comments down here. So yeah, traffic is split evenly 50-50% between each version. So when users visit the home page, 50% of them will get the variant, 50% of them get the old one.

Speaker 6: All do users with do not track enabled will always get the control version and won't be tracked. So then we now can click save and start test. We could save a drop if we want to, but we'll just save and start test. And this is what the uh the dashboard looks like. So uh we we will record the uh the total progress. So once you've reached that total sample. um then the test ends. And then we also show you where how many conversions for the control and the variant we have. And then there's a graph at the bottom. So I'm going to now end this test because I want to show you one that has already been completed and has some data in it. So let's end that test. And then we go to this A

Speaker 6: B testing tab here that shows you the past tests that were run on this page. And I'll just click this one that has been completed. And as you can see, 100% complete. the control one because it had a 39% conversion rate over 19%. And as you can see we've got a nice graph here showing overtime those conversions. This package is available now. It's on PyPI. It's also already in use and production on donate. mozilla. org as well. So it should be all production ready. Yeah, that's it.

Speaker 2: There are a couple of questions coming in. One from Kate who asks if A-B testing will work on headless implementations.

Speaker 6: Not at the moment, because all the logic is in uh Python, so you actually have to visit the page on the Wagtail instance in order for the um the logging to work and for it to swap the variants. But I'm soon going to be implementing like a sort of Cloudflare support which will involve adding an API to allow a separate service to query. which pages have variants and also to send back um results as they come in. And that could be reused for a headless site.

Speaker 2: Cloudflare is the um the kind of caching proxy that we're we use most widely, but uh a similar approach should work with other kind of intelligent caches like um Lambda on the Edge, which is the AWS equivalent. or uh fastly where you can do achieve the same kind of logic in um varnish syntax and there's a question from Naomi does or can the A-B testing exclude logged in users

Speaker 6: Uh not at the moment. Um yeah, I'm sure that's possible to add. Um Yeah, the answer is no, I think, to both of them at the moment. It probably would be nice to add a add the ability to add your own custom logic and then you can add that. But at the moment, yeah, it will it will count login users.

Speaker 2: It's great to have this kind of on-the-fly feedback though and uh future direction. And a question from Ralph, if you hit save instead of save and test, do you get an option to start the test later?

Speaker 6: Yes you do, yeah. So it it what it what it does is it tests the latest draft against the live version. So uh if you save a draft, then if you come back and save and add tests, it'll it'll include those draft changes as well.

Speaker 2: That's it for all the uh all the new things we wanted to show you. Um do you keep questions coming if you if you've if you can think of anything? But while you're thinking, I just want to talk a little bit about what could be coming next. And I've got uh just one slide to show you on this And um uh this is so here's here's our roadmap and the first item on our roadmap is is a roadmap, which uh which isn't isn't a typo. I think it's something that we haven't been really strong on. And we've we've had various attempts over the years to um to kind of project on the the uh to to forecast the the features and the direction we want to take, but it's it's quite hard with an open source project because. Of course, you don't know where the contributions are going to come from or uh what

Speaker 2: what the demand is going to be. Nevertheless, I think I think it's important for us and and the community to to do a better job of showing this the the direction that we want to take. And so that's something that I hope you'll see more of in the next in the next few months. Having said that, there are some items that we know we want to achieve. And at the top of that list is the completion of this admin comments that you've just been seeing from Jacob. So it's in a good state now, but we can we can take it to another level quite quickly, I think. And some ideas for how we do that have been suggested already in in your your questions and comments. The really important part is this thing that we we call admin API, which is again we've made we've made some progress with this and that part

Speaker 2: that's partly what is uh making telepath possible. sort of the decoupling of the the the content and and the editor UI but we want to go further and and you know ultimately we would like Wagtail to be uh a kind of this powerful flexible repository of of of the content you want to manage that can be accessed through different mediums through through just through different UIs. So you know the the the the UI that we're going to continue to build and make better, but also you know potentially other UIs. And um autosave is another that's and it's it's nice to see this has come up a couple of times in the comments already that um that's something that I think people people care about. It's not super straightforward for us to do that because as you probably know, Wagtail stores a new version every time you save. And if we're doing autosaving, then we

Speaker 2: know we we don't want to keep uh making a version every time someone presses a couple of keystrokes. So we have to think about the right the right user interface for that. We want to kind of to do autosave but but make it manageable and uh we've got an idea about how to move forward with that and uh Yeah, I think I think you know a combination of these things, the the the kind of features that are going to be available through telepath. means that I think we'll see some really dramatic improvements in the in the editor experience in the coming releases. Finally, I would like to say that a lot of what you've seen today has been made possible from the generosity of sponsors. And so we, you know people like Mozilla and Motley Fool and Caltech

Speaker 2: and Ugov. And I would really encourage you to kind of to think about whether the organization you work for. might also be able to make a contribution, particularly if Wagtail is forming an important part of of uh of what your organization is doing. And uh it doesn't take huge sums of money to make some pretty dramatic steps forward. And we would be really, we would, you know, the whole Wagto community would love to work with anyone who does have funding available and would can can think of ways that uh we can improve Wagtail to make it better for you. So we're really kind of encourage all of you not to think of Wagtail as a sort of black box operated remotely by, you know a small group of people but but actually is but something uh that's very open

Speaker 2: and um and you know we want to work with you to make white ill the best it can be Thanks all for joining and hope to see you for episode four in uh about three months' time.