 As Eduardo said, my name is Tom Dyson and I run Torchbox, which is a UK agency. We do digital work for people making the world a better place. People like Greenpeace, Oxfam, Red Cross, United Nations. We built a content management system called Wagtail and that's what I'm going to talk about for the next 25 minutes. This isn't a particularly technical talk so if you're not so interested in the story behind Wagtail then you can just pretend to listen and you can use the time productively by building a little Wagtail site. So inspired by Microsoft I've got a promotional idea and if you show me a Wagtail site that you've built by the end of today I'll post your t-shirt. Here's the one minute version to help you get started. This gets you as far as the admin interface. If you don't have a photographic memory you could take a photo of the screen, although that would give the game away. Here's a link for the extended 10 minute version. This shows you how to build your own page models and templates. If you get stuck with anything I'd be very happy to help you afterwards. Finally, for the super lazy you could just try out the demo. This is running on a little docker container on my colleague's $5 digital ocean box so maybe you don't all try this one at once. Back to the story. Torchbox has been working with Django since the early days. My brief, my fleeting claim to fame in the Django community is that I've made the first ever Django screencast in 2005. Soon after that I hired Simon and Willyson and Andrew Godwin. In fact the first version of South was built by Andrew for a Torchbox project. We have a team of developers at Torchbox using Django to build things like SMS apps delivering personalised agricultural information to subsistence farmers in Kenya. Ecological footprint calculators, grant management systems, tools for booking beds in care homes. But for the last five years for big public content managed websites we've mainly used Drupal. Is anyone here used Drupal? Maybe about half of you. It's easy to be rude about Drupal. But it's very powerful. It has an enormous community. The ecosystem of modules in Drupal is probably as big as the ecosystem of Django applications. Most importantly you don't get fired for choosing Drupal. That's especially true in the non-profit space where most of Torchbox's clients come from. We've made some Drupal sites that we're really proud of. Particularly perhaps Oxford University and the Royal Institute of Foreign Affairs. Both of these are high profile sites, big sites with masses of content, high traffic. They work well for their users and lots of people say nice things about them. But Drupal has some big flaws. The first of these is that configuration happens in the database. You can imagine why a developer would think this is a good idea. But it becomes very painful when you move from developer to staging and then production environments. And then your client calls you and there's a problem that you can't replicate because they've configured things differently to your version. And on a similar point, Drupal is too flexible. The power that Drupal gives administrators and particularly around creating new content types through the user interface and generating columns and tables becomes pain for developers. Performance is an issue. Most Drupal sites rely heavily on varnish. And that's okay for a mainly static, mainly a read heavy site. But varnish doesn't help the logged in editors who have to put up with a sluggish authoring experience. And when we deliver a Drupal site, we have to train the editors. That's not a disaster. But I think ideally if you can sign up for a Netflix account or buy a book on Amazon, you ought to be able to understand the fundamentals of creating and managing content on a website, on a CMS. But Drupal's worst sin, in my opinion, is that it's opinionated about markup. Drupal generates HTML for you. This restricts our design and our UI choices. And it makes site maintenance slower for our developers. Most importantly, it makes us more expensive for our clients. So faced with these frustrations, we persuaded one of our clients, the Royal College of Art, to commission us to build them a new CMS in Django. We launched their site in late 2013 and we launched the open source project in February 2014 at Django weekend, an excellent short conference in Cardiff. I guess this was half about being a good open source citizen, but half commercial. We knew that we couldn't persuade new clients to let us use Wagtail to build their sites if the only people maintaining it were a small company in the Oxfordshire countryside. To be honest, we weren't very well prepared to manage a reasonably sized open source project. Despite that, everything seemed to go perfectly for the first few weeks. On the day my colleague Matthew announced Wagtail at Django weekend, I posted a link on Hacker News and I asked a couple of friends with decent karma to upvote it. And it hit the front page and it stayed there for a while. And for a few giddy days, we were in the top trending projects on GitHub. And then the contributions came flooding in. Obscure European language translations, feature suggestions. One evening someone in Sweden noticed an issue and an edge case with admin permissions. But by the morning someone in Mongolia had fixed it. It felt like we'd discovered perpetual motion. People on the internet doing our work for free. For three weeks our core team, two developers, worked hard on what we thought was the most pressing issue, our lack of tests. We went from 0% to 80% coverage pretty quickly. And then we eaked out a couple of percent every day until we plateaued it about in the low 90s where we are now. Still documentation additions and thoughtfully worded enhancement suggestions kept flooding in. In our weekly team meetings we were referring to these generous strangers by their first names. Have you seen Jess's new work on refactoring the JavaScript? Did you see what Phil's ideas around documentation? But after a couple of months we realized that as we were investing more and more time fixing the bugs that other people were kindly finding for us, the volume of contribution started diminishing and the tone of engagement shifted. It took us a while to work out what had happened and I think we've addressed most of those reasons. So from my vast experience of launching one open source project these are my top tips. The first is to use that energy of launch. People want to be part of the new thing. When we announced it on Hack and Use and it got on to the front page, that's what engaged people and made them want to be part of something that looked interesting. I guess I'd imagine that there was going to be a gradual increase in engagement. But there was a big rush in those first two weeks that we've never really recaptured. And I think if I were doing it again then I would make sure that we had even more resources available to support people and respond and feedback in that early phase. The second point is about establishing a predictable rhythm for our work. So this means giving people clear indications about how often we're going to deliver new releases, how the beta testing process works, what the roadmap looks like. In this case I think velocity isn't so important as just giving people the impression of constant motion. That's what people want to see, that it's steady and it doesn't stop. If I were doing it again I would start with better documentation, particularly around making it really easy for people to get started and I would start with tests. Not because tests are critical for a project that's only two weeks old, but because it avoids you having to answer snarky comments on Reddit. We made some assumptions about how developers work. For example, a torch box we use vagrant heavily. It means that we get clean parity between our developer and production environments. And it makes it much easier to get started on a new project and you can forego the pain of installing libjpeg and the Postgres drivers on OSX. And we imagine that everybody else felt the same way. But it turns out that quite a big proportion of the Django developer community don't want to spin up a virtual machine just to test your shiny new content management system. Similarly we use Postgres and we imagine that most of the world does too, but it turns out that's another case. I think reducing barriers to installation is really important. An example here is that we use SAS to manage the CSS for the admin interface. And my colleagues had a philosophical objection to shipping the compiled CSS files in the repository. So this meant that we required anyone using Wagtail to have Libsas, which is, again, it's fine on vagrant, but it's a pain to build on OSX and other developer environments. And I imagine there are a lot of people who, again, might have been interested in Wagtail and seeing these posts and who would have tried it out and after 15 minutes got frustrated about having to build Libsas and gave up and probably never came back. And finally, this last point is about communications. And I think it's easy to feel that if people aren't constantly replying to your tweets and blog posts and Google group updates, it doesn't mean that they're not there. And this point came home to me with one of our first big Wagtail clients, a big broadcaster in LA. And I went out there for the meeting and it was a surreal experience for me. I was sitting at this big mahogany table and leather armchairs just like in the films. And through the window I could see the Hollywood sign. And the guy across the table who I'd never met was talking with amazingly precise detail about the coding habits of my colleagues. And I realised that even though people aren't writing to tell me that they're using and they're interested in this stuff, you are under scrutiny and people are interested in the fact that they're not communicating back with you. Doesn't mean that it's not important for you to keep posting and talking about your work. So after we fix these problems, particularly the ones around documentation and tests and establishing a predictable rhythm for releases, we started seeing some really high quality contributions. In particular there were two agencies on either side of the Tasman Sea. They both decided to switch to Wagtail wholesale and to invest in its development. Springload is an amazing agency in New Zealand. They've been building Wagtail sites for the Red Cross and the New Zealand Government and they started prototyping a next generation user interface with React. Take Flight is another fantastic agency based in Hobart and Tasmania who politely suggested and then implemented some fundamental changes that we should have seen before we'd started. And then in the US we started to get interest and I guess that's why I felt I should make this trip from Oxford to Austin because I started seeing blog posts and work by really respected agencies like Cactus and RevSys. Lincoln Loop referenced Wagtail in the high performance Django book. Wharton School of Business who are here and Tivix. Is anyone here from Tivix? I've never met anyone from Tivix but they're doing some really good stuff on Wagtail. And then there's some big sites, NBC, the broadcaster I mentioned before. They're building a massive news site on Wagtail. There's a political campaign and a tech giant, both running sites that you've heard of but we're not allowed to talk about. Incidentally, both of those sites use Wagtail's static site generation feature which isn't really prominent in the documentation but I think makes sense for sites where scale and security is paramount. The UK and Finnish and US governments are using Wagtail and I know this because I can see their projects on GitHub. NASA and Oxfam are using Wagtail but so are porn sites and car manufacturers and this has raised some unexpected moral dilemma for us. We wouldn't work for some of the organisations who are benefitting from using Wagtail because we don't like what they're doing. I can't think of an obvious way around this. As far as I know there are no open source licences which limit usage to organisations who conform to my fluffy liberal western ethics. That's where we're at now. The next steps are really around defining our roadmap more clearly. The killer feature of Wagtail is something called Streamfield which is a bit harder to explain than it is to demonstrate. Essentially it's a content type that lets people build a long-form narrative content rich content like we're used to seeing on medium or New York Times or The Guardian in the UK but without storing everything in a big blob of unmaintainable HTML. For those of you who heard Andrew Godwin's talk about database anti-patterns I was pleased that he thought that storing some CMS type content in JSON fields is the right way to go because that's our approach with Streamfield. We've got ideas about making Streamfield even stronger and starting to remove the requirement to have WYSIWYG interfaces at all to have rich text editors at all. Otherwise in the roadmap we've got this support for internationalisation in Wagtail but we need to have a better built-in interface for it. Wagtail stores versions of all the content that we can't currently revert to previous versions through the UI. We want to have a cleaner separation of the internal API and the user interface so we can start doing cooler stuff like the React-based prototypes that Springload have been doing and we want better support for really massive sites with millions of pages and terabytes of content on remote storage. So we're identifying all this in the roadmap but more particularly we're using WEPS. So you all know about PEPs, Python enhancement proposals which has been a very successful part of the Python community and has been adopted as you may know by the Django community with DEPs and you can imagine what WEPS are. This is our own version where there's a GitHub repository of a structured feature request that explains the motivations behind a feature and the implications and how it might be dealt with. The idea with a web is that it's a package that another developer or agency could pick up and understand that by contributing they'd be delivering along the lines that we want to see Wagtail grow. Finally I'm going to address the title of my talk. Why did we build yet another content management system? As someone who used to code and now mainly manages coders I recognise the constant fight against not invented here. And it's true that maybe we would have been better open source citizens if we had contributed that effort to an existing platform rather than building our own. There are, as you know, some very established projects. Mezzanine is one. We used mezzanine for a project two years ago and we liked it. In fact some of Wagtail is inspired by mezzanine's key principles. Django CMS of course is very powerful, very mature. We recently inherited Django CMS project for a UK government project and it's going well. But there's some fundamental differences in our approach. One is around control versus flexibility. This is a bit similar to the Drupal point. In a way Wagtail gives you less flexibility from an administrator's point of view and it hands control to the developer. So new fields are defined by developers. We use migrations to make changes. We use standard Django templates, the tools that you're used to working with. Django CMS focused recently on front-end editing and WYSIWYG editing, which is appealing and works in lots of situations. But for us we follow more the so-called COPE model. Create once and publish everywhere. That means having a more focused editorial interface that enhances the authoring experience. Aside from all that, we had a basic commercial imperative to build the content management system that our clients wanted. In basic terms it was quicker for us to start from scratch and to build on an existing project. But I don't think this is a problem. The demand for new content management sites is growing more quickly than the supply of new content management systems. More quality tools in the Django ecosystem should be good for everyone. When your newer, cooler Django-based CMS hits hack and use next year, I'll smile roofily and I hope that you'll make fewer mistakes than we did. Thanks very much. Hi, I'm excited to get started with Wagtail. I didn't understand your description of stream fields or webs, and I wonder if you can demonstrate. At one point you said it would probably be easier to show than to tell. Okay. I think the best way to show webs, it might be tricky for me to find this. This isn't mirrored on my screen so I'm looking over here. The Django ones are a better example. So an example. So here's one, which is a kind of template for a Django enhancement proposal, which shows the metadata and gives some guidelines for how you might want to structure your feature request. Oils are a bit simpler than this because I think we just want to make it easy for people to get started. But basically it's a structured, standard way of describing features and their motivations that then gets agreed, collaborated on and agreed and becomes part of an established roadmap. I think I won't have time to show stream field right now, but I'd be very happy to demonstrate it to people straight after this. I've been building a Wagtail site for the last month or so. I've been really enjoying it and I highly suggest everyone here gives a shot and plays around a stream field and wraps their head around the idea and see how it allows you to build your own widgets for different types of content. One thing that I was noticing, reviewing my code over the last couple of days, is that I have a lot of hacky ways that I'm including resources for individual stream fields such as having a widget that may be displayed six different times but needs an individual resource each time, a little bit jQuery code, so it gets included eight times in the code. I was wondering if there's any better way or any future plans to integrate some more front-end functionality ways to include resources in stream fields as we built this up, because I see that just continuing in what we're building and expanding. I think that's a really interesting point and it's so important for us to look at the ways other people are using our software. I discovered this yesterday with Margie and I asked the first question and I went through the process for 10 minutes of her setting up the site and immediately just looking over her shoulder noticed some things which are obvious to me but wouldn't be obvious to someone coming at this for the first time. Similarly, the way that we build our stream field objects are in the same way that we made the mistakes about assumptions, about the way developers work. Almost certainly it's not going to be the case the same way that you're building stream field objects. We may be having a section of the documentation around recipes so we can have some examples and guidelines of how to do this in a maintainable way but also I'm sure that there are improvements to the way that we can offer stream fields and particularly provide hooks around the JavaScript injection which means you don't have to repeat it many times. It would be good to talk about that. Did you manage to make a Wagtail site during the tour? Great. Five T-shirts. I think that's it. Do you have any tips if you have one of those other CMSs? Django CMS let's say. If you wanted to migrate one of those sites to your system any general tips that you might offer for something like that? I think this is somewhere where we can learn from Drupal. Drupal has a very good module called the migrate I can't remember if it's called a framework or a module that the way they approach it is they have an interim database and you write the rules that get into the interim database and then that becomes a common format that's easy to import. I think we could do something similar to that. I guess our standard answer to that kind of question is Wagtail is just Django so anything that you would be able to do to migrate any project into Django you should be able to do with Wagtail. There's a bit of a cop out I think because there are some conventions that we use that may not be immediately obvious. If our goal was a massive adoption of Wagtail which perhaps it is then I think providing some simpler migration from common platforms would be a good move for us. Is there a way to hook it into an organization's existing username and password infrastructure with LDAP or Kerberos or any of that? Yeah, that's a really common requirement and it's one that we've done many times. In fact, for our first ever Wagtail project the Royal College of Art, that's all based on LDAP. LDAP is really, Django is doing all the hard work for us but LDAP is just a one line contra change in importing the LDAP library. We've also done it with SAML and Sibyleth for some other university sites. So in Wagtail a page is structured content and a block is also structured content and you're currently using JSON for stream field and I'm interested to know because I've had situations where maybe I would want to pull out a particular block inside of a page. Would it be possible to use models so that it's represented in the database in that same way? Because when you think about how the pages are represented in the explorer, it has a path, right? But then you get infinitely nest blocks, like blocks within blocks. So then a block like 10 levels deep would technically also have a path within its own page. So I'm just curious to know your thoughts on representing blocks and pages as being one type of data. So one idea is that we do, we move away from the JSON representation to modelling in a relational database. I'm not sure that's necessary and particularly, as you're probably aware, the JSON support in Postgres means that it is possible to index and filter on content within JSON and performance for that is getting better and better and I think Postgres makes a fantastic document database in competition to something like Mongo. So that's possibly one step, although obviously that doesn't help my SQL users so much. Things do get harder when you have deep, deep nesting, but at the moment JSON is handing it reasonably well.