 Hi, I am SEO Joe with Powerful CMS, a sponsor for this event today. Today we have a case study from SPS. SPS was established in 1975 as being a provider of multilingual, multicultural content in radio and television. For those of you from U.S., I think the closest comparison would be the PBS. I hope that's alright. And the questions that, if you have these questions on your mind on how does SPS handle their content management system? Why did SPS choose Drupal? How is SPS managing Drupal? This conversation from Matt is going to be super exciting. Matt Costain, technical director, online engineering platform at SPS. Please join me with a huge round of applause for Matt Costain. Thanks, Joe. As he said, I am the technical director of online and emerging platforms at SPS, largely responsible for technical strategy, architecture, development and operation of our digital non-broadcast platform. We provide services and content to multilingual, multicultural Australia. The idea of that is to promote social harmony and inclusion. We're different again to other broadcasters here because we're a commercial, not-for-profit organisation. We're about 70% funded by government, 30% from commercial activity. We have a very strong focus in news and current affairs, football, cycling, food film documentary and in-language content. We actually have content in 68 different languages and that's across audio, video and web-based content. SPS online, which is where I work, we have two main supporting objectives for the organisation that is to increase our audience and be more relevant to our audience. We have over 90 websites, so the content management challenge is not insignificant. We have mobile sites, mobile apps, connected TV applications, as I said, 68 different languages and we currently deliver that content on 15 different platforms. Around 12 of those websites are of pretty large significance in terms of their size. There's probably 40 cookie-cutter small TV sites to support our broadcast. The rest are medium-sized or content-heavy pieces or standalone multimedia projects. We do about 1.5 million unique browsers a month. We serve over 2 million videos and about 20 million page impressions. Those numbers, especially in the page impressions and videos, serve to double during an event period such as the World Cup or the Tour de France. The challenge we've had is we've rapidly grown over the last five years. That 1.5 million newbies was 700,000 four years ago. As we've grown, we haven't had any real product development strategy and certainly no accompanying content management strategy. Over the last eight to 10 years that SPS online has been around, we've had about six different versions of CMSs, all developed in-house. We've had a changing roster of people, we've had a changing view of how we're going to deliver this content and changing technology stack. The one consistent thing is it's always been on PHP, using MySQL and previously everything was built on the Zen framework for the tech user. The challenges here, well, there were many. For a start, the current system presented massive maintenance nightmares. There were totally disparate features across all of our websites. There was no consistent way to be able to roll out features. We had one, say someone in the world game, which is Australia's largest football site, wanted to add Twitter or Facebook integration into their site. We then had to go and do that to every one of the other sites and build the appropriate back end into it to support that. Content became siloed. What I mean by that is that football content was available to the football site. Food content was available to the food site. Radio content was available to the radio site. There was no way to actually share that content without a non-trivial development effort. Sharing content between sites as a result was non-existent. There was no way for us to cross promote content between different sites and leverage the work that other people in the organization had done. The CMS, due to its reactive nature, was always built to support the current project's aims and goals. Totally reactive, totally unintuitive to use, to the point of it actually being a liability of content. There's no security around it. There was no scalability. Every time we needed to do a new site, we basically had to take a code base, kind of copy it, and then customize it. As a result, there's a lot of copying and pasting of code, and I'll show you what happens when you do that. So, you know, we got the runs on the board. We were becoming very successful. We've had, you know, 100% growth over four years in terms of audience. So, we needed to do something to actually take the network to the next level. Here's a screenshot of the current CMS. It's essentially a mess. It's called Redback, which is a very dangerous spider for our overseas guest. You can see here there's a whole heap of fields which have got random values in them, completely meaningless titles. Half of the things aren't even populated. We don't know what they're for. No one knows what they're for. But if you remove them or add data, something will break. Here's another, this is an image library. Again, there's no metadata around the images. There's a whole heap of vacant fields. Again, no one knows what those fields are there for, why they were put there in the first place. And just another shot. Somehow it all hung together. It worked. It was a bit of a minor miracle, really. Everything was totally coupled. We couldn't do anything with it. We couldn't curate our content. And, you know, somehow we managed to deliver. Some pretty amazing websites. The world game biggest football site in Australia. SBS on demand is probably the most innovative catch-up platform in the country and also available on 15 platforms. We're the official partner for the Tour de France. We've got lots of news and current affairs websites as well. And, of course, we serve a lot of video, being a broadcast of that now. Key differentiator to a lot of the other sites out there. So we had to take a step back and look at what we were doing. The problem is, putting a new CMS in is incredibly disruptive. We've got business, being a media organization, we're 24-7. We have business as usual every day of the week. We've got this incredible fire hose of content coming in and out of the building. To actually stop all of that and put in a CMS was a big deal. But we had to do it. So we kind of applied, you know, there's this incredibly traumatic funding process within SBS and we applied for some funding. And after a period of time, people began to listen to us and saw what we were doing. So the CMS addressed four clear objectives, none of them technical. Increase the reach. SBS is reached by using multiple distribution platforms. Developing optimal delivery technology for SBS online. Developing capability to store, retrieve, and deliver content to these multiple platforms. And streamline processes, development efficiencies, and content production efficiencies. We went through a selection process for the CMS. My background before it at SBS was working in web agencies. I've had about 12 years of experience working for different media organizations. And I've implemented a lot of CMSs. Pretty much all of them failed. The reason this happens is, you know, people go, I want this, and this, and this, and they do a product comparison based on a matrix. That's great, the product can deliver. But you end up being locked to a product. No one, you know, you've got expensive training costs. Your requirements change, and they're not addressed by the product. Also totally ignores the users. And when I say the users, I'm talking about the back-end users, the people that are actually interacting with the system on a day-to-day basis. The business objectives are not normally made clear. We want to put this website out. It needs to serve 20,000 pages a second, and be just totally awesome. It actually doesn't address the real problems that a business are trying to solve, which were the four points before. To get around that, we brought in an independent VA. They sat down with the content editors, and users of the actual existing system looked at the inefficiencies that were in the current processes, the tasks that they were doing repetitively, and came up with a number of practical evaluation criteria and use cases that we would use to select a new CMS. We then went out to the market, looked at what was available, both open source and commercial CMSs. These were initially shortlisted around being able to meet both our organizational requirements, and then we'd look at how the user experience was going to play out. I won't bore you with the details there, but after we did that, we got down to two vendors. Both of them were engaged to provide reference implementations against the use cases that the VA came up with. So we engaged them commercially at that point. I suppose if you look at it, it was a closed trial on a number of use cases. We evaluated these against the users. We had a point-based matrix about usability. Do I like the interface? Does it achieve what I'm trying to do? First and foremost, will this actually make my life easier, or is this just going to be another system imposed on us by developers without any real idea of what the user experience should be? Drupal 1. It was the highest rated system by a long way. It met every one of our criteria around technical, multi-platform, multilingual, multi-site, secure, scalable, and flexible. It also won out because of another whole heap of things which weren't really considered when we first went to market looking for CMS. For a start, as I mentioned before, we're a PHP development house. It was a really good match with our in-house skills. So going to something like Sidecore, which Drupal's often compared with, is a .NET CMS that would have involved throwing out our entire infrastructure, get retraining, or getting a brand new development team. It's open source. The virtues of open source are extolled in the last talk. And that's not something to be looked at lightly. And the Drupal community, I didn't realize how strong the Drupal community was until I went down to Drupal down under last year, and sort of blown away by the enthusiasm by the locals. Drupal has an increasing market share in large enterprise, whitehouse.gov, NBC. Media organizations, especially in the US, are starting to pick it up. There was an incredible amount of local support. You can see the sponsors of this conference. They're all present. They're all around. They're all willing to provide professional services. There's also a large amount of international support, largely through Acquia, but also a number of other organizations. The local labor market's fairly strong, highly competitive. It is difficult to get good Drupal developers, but they are out there. There's a module for that. It's very true. There's tens of thousands of modules. And of course, there's no vendor lock-in. All of this, we sort of hope, will deliver a lower total cost of ownership to us over the three to five years that we're sort of basing this project on. So the things to fix. As mentioned before, the previous CMS, it was tightly coupled to a database schema. It was essentially the administration interface was not really that different to just plugging straight into a database. The individual website features were also there on a site-by-site basis, but weren't common across the network. It was no easy way to share, repurpose, reuse content, and I've touched on that already. So some sweeping changes. We took all of this and went, well, this is not just a trivial problem about putting in a new CMS. What do we do to actually fix this across content management and also network-wide functionality and capability? We gave it the original title of Network 2.0, which has been shoot off because it doesn't make any sense. Network 2.0, though, was a consolidation of visual style, user experience, functionality, branding, templates, social and identity management function, advertising, and it was all underpinned by a platform agnostic content repository. We got a pretty ambitious two-year plan to migrate the entire network across. I would suggest that that will probably take a little bit longer due to some of the complexities which I'll talk about later. Quickly on Network 2.0, it was a current crop of SBS websites. They kind of look as though they're part of a network they kind of don't. There's a common header and a filter. The masked heads are reasonably similar. But it's not when you jump on the Guardian or on the BBC and you go, wow, I'm in the Guardian or I'm on the BBC site. So there was a very, very long and drawn out design and branding exercise that we're still in the middle of around what Network 2.0 should be. If you look at this page here, you can see color palettes, angles, design, layouts are all contributing to a completely new look for the site. The new site will start to take on this sort of approach. And you can see in this slide here, we've got locks of common functionality, headers, sidebars, right-hand column widget, lists, curated items, and so on. All of those things are going to be created as reusable components deployable across any site without too much effort, hopefully. The content repository is also completely key to what we're doing. As I mentioned before, the content repository is a platform agnostic store of all of our content. Each site previously had a number of databases that supported it. All the content went in there. We couldn't do anything with it. If we wanted to expose that content, we had to do a development exercise around writing APIs. We had to scratch our heads and wonder if we do this, what else will break. We're going to throw all that away. What we're implementing is a bucket of content that sits under all of our CMSs. Every piece of content that gets entered into the CMS, Drupal is the actual administration interface to manage the sites and the content. As that content is entered, it gets pushed into this repository where it's available for use for every other site. We've wrapped that up with our own services. We had to build it ourselves. There's too many standards out there for this kind of thing. None of them are completely useful and certainly not allowing us to do what we needed to do. For the techies, we're using MongoDB. We're using Symphony 2, which is a PHP framework. And we've written what we'll call a notification queue. And I'll talk a little bit about that. It's very important. Drupal itself communicates with the APIs that we've written, not with MongoDB. We've got a very traditional Drupal deployment on top. This content repository is completely decoupled from the system. If we move away from Drupal or we want to put other things on top of it, we can. Technical diagram. MongoDB. This is technical, but I'm going to touch on it because it's important. We have 90-odd websites with an undefined way to represent the data and content that we've got. MongoDB doesn't care about schema. It doesn't care about SQL. It doesn't care about all of those things that make building websites or used to make building websites hard. It doesn't care that our data is bad. It cares that we have the data. And the data web page might contain a title, an abstract body content, images, associated videos, other documents that are attached to it. We can just take all of that and throw it straight into the content repository and pull it straight back out. When we do that, though, we do need to be careful about how we map that back to the Drupal interface. So there is a fair bit of adaption that goes on. MongoDB has also chosen it super fast. It doesn't use that many resources. It's very scalable. As the content repository gets bigger, we can just add more servers and it scales out, doesn't really care. As I said, it doesn't care about our data. And also tagging, indexing, and search. We're moving away from an article by article approach to the way that we deliver content and more to a storytelling approach, which is, you know, SPS's tagline, 7 billion stories and counting, where we're really trying hard to tell the story, not just give you the information that you need. So being able to tag everything up and then pull it back out based on its topic or tag is absolutely fundamental. As I mentioned, content is created and ingested into individual Drupal sites and then pushed into this repository for all to use. We wrapped up the content repository with our own service layer. It allows easy access by any internal or external system. We haven't actually opened it up externally, but the plan is much like in the way the Guardian and BBC have done to make our content accessible to all so that people can do interesting things with it. We are a public organization. The content belongs to the people. Schema.org is a way to describe things. As the internet moves famously to what's known as the internet of things, you need ways to describe these things. Schema.org is an initiative by Microsoft, Google, Yahoo, and a few others to put some sense around the way that things on the internet are described. If you can think of any kind of content type, there's probably something in Schema.org that will help you describe it, whether for us a film and then a film review and an actor and a producer or a recipe and an ingredient and a measure that makes up those ingredients, it's all there. So we've basically used Schema.org to steer the way that we describe our content. And that's also important because search, people need to find your content. Schema.org gives you a really simple way to market up so that search engines can interpret it. Thompson Reuters have a service called Open Calle, which semantically analyzes your content. So every time a piece of content is added, we visit it through their service and it extracts all of the terms, it extracts the taxonomies, it says what it thinks it should be, where it should be classified. For a lot of the archive content, we do that automatically, we push it through there and we use what it comes back with. More generally, though, as people create content, push it through there. It'll suggest the appropriate taxonomies. And the people creating the content can curate the content appropriately. Drupal has incredibly good taxonomy support, so it plays really well with Drupal. So we're in the process of migrating our content to the content repository. It doesn't deal with all the legacy systems. So we've had to write a system that will capture any content changes in the legacy systems and push them into the content repository. Migration has been made somewhat easier by the fact that Mongo doesn't care about what our data is. But it's also, Mongo is not particularly good for searching. So we've actually indexed all of our data with Solar, which is another open source platform for searching. And that index is made available to Drupal, not Drupal talking to the databases directly. Use case here. I don't have a screenshot to show you, but if a user is creating an article on the food side about Italy and then wants to perhaps link to something about the Italian football team, they can type in Italy, hits the index, everything comes up. You can search through the different facets. You're looking for people. Are you looking for places? Are you looking for food? Are you looking for cuisine? And so on. And you can then just grab that content and use it. So Content Editor has the ability to create new content, link to existing content, or make a copy of existing content and repurpose. That's quite important when we're supporting 68 different languages. How do we actually, there's all this content in English, but we might want to push it out to Mandarin. We might want to push it out to Farsi. How do we translate that intelligently? And what happens if content gets edited? If I've used someone's content on my site that was created over here and then the source content changes, what do I do about that? So we wrote this thing called the notification queue. It basically looks after our content concerns. So when someone uses content that was created, not by them, but by another author in the organization or on another site as its source, they can flag how they want to handle that. As they use that, they can say, let me know if it changes, or just pass all the changes through. Again, for the techies, it works a little bit like a MySQL binary log. You can take off the servers, and it remembers where the content repository is at. When you turn it back on, it goes, OK, I'm here. I've got all these changes I need to run through and see if my site has anything of significance that needs to update. Another boring chart, which I won't go into. But essentially, it says here that if the content has expired on my origin site, it can send a notification that the content has actually expired. It gets marked as expired in the origin. The action on the client site might not need to do anything, but the status changes. So how do we do this in Drupal? Well, we're creating an archetype type site. This is a site that contains absolutely everything that anyone would ever want to use in SPS. Of course, it's a work in progress. We're targeting one site for launch. And this one site will have as much as required to get sort of a minimum viable product out the door. As new features and new sites come online, we will have to build on top of that. So every site we put out there will inherit from this. As alluded to before, it contains a library of modules, components, and features, accessible to any of the new sites. When you attach or you place a new component on a different site, you can just assign it a data source and it will populate that content. You can curate that content or you can do it automatically. All of those things are in Drupal. Makes life very easy. As a result, a five-page promo site for a TV show will be using this system as will a site with thousands of pages and incredibly complicated content structures. All good, but people still have to use the site. Network 2.0, as before, we're using a responsive grid approach for a device adaptation. We've integrated this into Drupal as a base theme. So every other site picks this up. Drupal 7, current production version of Drupal, does support server-side device adaptation and content delivery. It's a promise of it in Drupal 8, as better supported. But we, again, using a sort of platform-agnostic approach, we decided that we'd actually like to decouple the device adaptation and delivery from Drupal itself. So while there is a base theme that we're using, we're doing all of the detection within the browser of using CSS3 and HTML. These are actual screenshots of the work in progress. The food site for international guests, koalas, are on the menu. This is the big, broad, you've got a 1900-res monitor. You'll get that. Scale down to a smaller size. You'll get the one on the left. And then if you're on a mobile device, you'll get the one on the right. A little bit ugly, sorry, I didn't have time to get some nice, proper content in there. So things that Drupal doesn't do. It's not all roses, I've got to say. It's generally pretty good. But we've had to write a lot of custom modules to do all the system integration work that we previously had done using our own custom framework. Increasingly, at SBS, we're finding that the role of the development team is more about system integration. We're not a technology provider. We don't want to be rewriting commoditized technology. We don't want to be reinventing the wheels. So a lot of our systems now are outsourced. They're software as a service platforms. They're in the cloud. Things that manage our audio legacy systems. Radio is the oldest part of SBS, and we've got the dinosaur systems that don't work really well. And we have to manage that. We've got to come up with a, there's nothing in the community that will handle that for us. Video, on the other hand, we use an organization called the Platform, it's a US-based company that does video CMS work. There are Drupal modules out there that integrate with the platform. We've written another one, which we think is better. So we're going to really step back into the community. So everyone else that is with the platform and decides to go Drupal can use it. So single sign-on, always a big issue across multiple sites. Drupal does handle it reasonably elegantly out of the box. We have some sort of deeper concerns, especially from the marketing department, who want to integrate really tightly with our CRM system and start building up intelligence on our audience. And as a result, we can start to deliver better personalized content. We can target advertising. We can do all of those things that people spoke about in hallowed terms about five years ago. We're not doing it yet. We are aiming to do that. Out of the box, Drupal's identity management is pretty good, but we've actually integrated an external system. We're using, for those that are interested, it's Jan Rain. And we're using LiveFire, which is another software as a service platform, to do our comments and social integration. The other thing it doesn't do, I mean, there's plenty of Drupal themes out there. And there are things that will adapt to devices and give you a nice experience on different platforms. But one of the things that when I came in with a bit of prejudice with Drupal, because so many Drupal sites are really ugly. And people put the sites out there just using what's available in the community. And there's nothing wrong with that. But we want beautiful, elegant, functional designs. So we've had to go and kind of almost reinvent the wheel a little bit with that theme. So where are we at with all this? Look, we follow an agile methodology at SBS. For those familiar with that, we're four sprints into the rollout of our first site. So we're about eight weeks into the development of our first site. We've probably spent about three or four months in the back preparing everything else, getting the content repository up and running. The content repository's there. It's basically ready for prime time. The responsive grid, as evidenced by the rough screenshots before, actually works. You can hit this in TVs. You can hit it in your iPhone. You can hit it in your Android phone. You hit it on your tablet. And you will actually get a really consistent user experience tailored to that device. Content will adapt. We will serve up different things based on what we think you should be seeing when you're on that device. Things are moving a little bit slower than we'd like. The Drupal learning curve is reasonably steep. I've got a highly talented development team, but they have found the change from, even though they've had training, moving from a bespoke platform where it was free for all and there were no rules, moving to Drupal, it has been a little bit difficult. I will say, though, that in the last month, our development rate has rapidly accelerated. Once you get it, it's pretty clear. And things do start happening. And I'm very confident now that we will meet our prime frames and probably exceed them in a lot of ways as well. Another problem with that is Drupal offers you tens, if not hundreds, of ways to achieve exactly the same results. So trying to work out what the best practice is and actually deploy that can be a challenge as well. Again, we're leveraging the community. We're leveraging people providing professional services and support in the city to help us with that. That's going pretty well as well. The other thing we're a little bit concerned about is the upgrade path. It's Drupal's famously difficult to upgrade compared to a lot of other systems. Drupal 8 has a lot of features that look incredibly appealing, especially for media organizations such as ourselves. Whether we choose to jump on that bandwagon before everything's better done or not, not sure yet, a little bit scary. Yep, that's mostly good. As I said, development velocities are rapidly accelerating. We're now getting to a point where we're actually able to plan our projects out and know where they're going to be and what sort of development rate we're actually going to be able to hit. Importantly, costs have been constrained and contained. Development resources are not cheap, but I'm pretty sure that given the amount of resource that we've thrown at this, we'd still be hundreds of thousands of dollars ahead of if we use the commercial CMS. Part of that is because the bespoke hardware and infrastructure used to actually run this environment, it's just a standard Linux box running MySQL and Apache web servers. The developers, you can train PHP developers up to use it. There are no software licensing costs. Well, yeah, there aren't, it's open source. You can actually go and get a lot of support for Drupal, which we are doing to a degree, but I'm still pretty convinced that this has been a very cost effective exercise for us. Check out SBS in a couple more months. It will be radically different to what it is at the moment and hopefully almost entirely Drupal powered. So to sort of wrap this up, we have worked with a few people and quite a few people have actually helped us get to where we are. We partnered with Previous Next, a local Drupal development house. They were instrumental in getting us and our architecture up the scratch and helping us with best practice. Hostworks, hosting company, based out of Adelaide and Sydney, their Drupal isn't their specialty, but they have come to the party and given us a big hand with what we're trying to do. TenGen provide MongoDB support as the official Mongo supporters there. They're ecstatic that we're using Mongo in such a context in this area. We're going to be one of the larger, and if not the only media organizations in the country doing so. Of course, Acquia, they've been with us all the way. They very came to get us on board and have provided excellent support, consulting, access to community, and so on. And New Relic, US-based company that does application performance monitoring, has incredible Drupal support. You just drop a module in and it will tell you absolutely everything about your app, where the bottlenecks are, where your database is falling down, even down to the code, and it's like this piece of code here is operating really slowly. So without all these people, we probably wouldn't get to where we are. That's about it. So anyone got a question? The question is, when delivering to a mobile device, can we push out a low bandwidth version of that site? The answer is yes. Tomorrow at 5 PM, there's two of the guys who are lead on this project. They're doing a deep technical dive about it. So if you're around, I encourage you to go and see their presentation. They will touch on all of that. Yes, the answer is yes. I couldn't tell you which library we're using, but there is a, we are using a library that will push out a low bandwidth version of the site. We're also looking at in-network optimization. So using something we're not actually using at the moment, but it could be web acceleration technologies either delivered from a company like Akamai, or our own hosting provider, or an off-site sort of proxying service that will do those optimizations in case you can serve it back to the user. It's certainly not private information as such. I would have to have a look at what confidentiality agreements will be signed, especially the two organizations that provided the reference implementations. In terms of the ranking and weighting based on straight out-of-the-box features, that's fine. I could probably put that up somewhere. Yeah, I mean, those kind of references we use, we leverage them heavily, especially right at the start, like, is Drupal actually going to do what we need it to do? There was a presentation, it goes to about an hour. It was a Drupal versus Sitecore, and I'm actually quite impressed with Sitecore of the CMS. It does a lot of the things that we need it to do, and it's very heavily marketing-focused, marketing guys love it. It's got a lot of stuff out of the box that's prettier, and all these things. Stuff like that is incredibly invaluable, because you sit down and you look at it, and you go, well, yes, Drupal does do this, it does this, it does this. Oh, it doesn't do that. OK, well, how are we going to fill that gap, and what's the effort required to do it? So yeah, we'll take that on board. OK, sure. So if you're interested in, say, the Syrian conflict, and there is an incident that's happened, and it's capturing headlines, and you go to it with the news article, and you read it, and you go, wow, that's incredible, but why did that happen, what's the back story? How do I find that? So many news sites, so many content sites don't actually frame that story within the actual greater context. So taking something like, we'll use the Syrian conflict as an example, marking up content in a number of ways, saying, well, yes, this is Syria. This is where it happened. Here are the geo-coordinates. This is the time it happened. Being able to plot that on a timeline, or plot it on Google Maps, surround the article that you're actually looking at with all of that back story. We've got these great ideas about how we can visualize that information, how we can navigate that information, which previously we haven't been able to do. So having all of that in the content repository, having all of this metadata around the actual piece of content itself in all of those different aspects will allow us to do innovative services on top of it. That's the idea. It's about the story. Exactly. So you might do a search on Google about Syria and land on airspace site. Instead of taking it directly to an article, we'd rather take you to our topic page on Syria, which will allow you to then navigate the actual story, not the actual article itself. That's the kind of end goal. We're a fair way from that yet, but we're working towards it. Up the back, I think, this first. The question was, have we been following what the BBC have been doing around open data and semantic? Yes, they're massively ahead of us, largely due to their infinitely larger budget. It's exciting. I mean, that's kind of the benchmark, I think. No, I don't. That's a really tough question, because in terms of pages, like outright article pages, if we just took our football site, for example, there would be hundreds of thousands, if not millions, of different pages. Every game that's been played in the European leagues have all had their individual pages. So whether we do that dynamically or whether there's a separate mode for each one of them, we're still debating. We're not touching football yet. It's a really complicated website. Things which are article-based. Again, we've got hundreds of thousands of articles. They expire. We might get a dump of content from our news providers, which add more nodes. So we're talking millions and millions of nodes. Good question. As an organization, especially within the technical part that I look after, I encourage the guys in the team to strive for best practices. We've also, the production team, and led by the head of digital, is always looking at what other people in the world are doing and how they're doing it and should we be following them or should we be doing something completely different. So it's a continual process, specifically around Drupal and what we're doing around the network redesign. We've probably spent around about seven months looking at the technical aspects and probably about three months in development or maybe four months in development with ideas ticking away for a couple of years beforehand around the network side of things, probably close to it a year in terms of theory and testing hypotheses and so on, either against internal users or against our content. And that's still evolving alongside the technical. So short answer is it's always been there and better it's evolving. Right, so the Solar Search Index is every single piece of content in there. They find it through the Drupal interface. As I said, I don't actually have a screenshot of it now but it's pretty cool you start searching. It will then auto complete the terms as Google does and sort of start dropping things down. Once you've found the term you're after, it will then break it out into the different taxonomies that that term exists in. So whether it's people, place, thing, object and then all the different facets. And so you can drill down and find that term in a number of pieces of content then you can search for that content again to actually find the relevant piece. We're not quite, we haven't quite finished that yet. It's working to the facet level but to actually put it in front of users and make sure it's really useful, not just what a developer thinks is useful needs to go through a bit more work. Yes. No, the thing is a media organization, what we continually need to do is measure, measure, measure, measure and make decisions based on data. The other platforms that we're bringing in to Drupal provide incredibly good analytics around what our users are doing. We can see in a much more efficient manner how much, how users are engaging with our content, whether they're sharing it, whether they're posting it on their Facebook wall, whether they're doing stuff on-site, whether they're off-site and these platforms allow us to aggregate that information and report on it and then make decisions in a much more meaningful way. Did we do something? Sorry. Yeah. Oh, sorry. Sorry, I missed the question. Ah, look, it's pretty straightforward to get out of the box, install it on your machine and I'll talk to you about it after this invite. Pretty much, yeah. Yeah, it might, which version of it goes out into community? We're not sure, but yeah, the intention is, one of the, and again, one of the reasons we talk on Drupal is because of the community and it doesn't make sense to be such a heavy user of it without giving something back.