 Alright, welcome to Drupal Camp London, lovely new facility, I've never seen a lecture theatre set up like this, this is great, very communal, so you've got to try and find some of this here, of course. And right, so I've got a rather cryptically titled future of content and the unknown consumer, so this is a talk that I've done a couple of times now and it's really, it's trying to give you a little bit of a guide to where we are right now in content management, where we are going to be in the future and the sort of things that we need to be doing today to prepare ourselves. But first of all, I just want to quickly introduce myself. Those who do know me from the past have been in the Drupal community for many, many years, but you probably would have known me from Icos. Since this time last year, Icos has officially merged with Invika to become one, because we used to run as these four separate brands and so this time last year we were still Icos and a part of the Invika group and now we're purely known as Invika, so if you're wondering who Invika are, Icos is now part of that unit. Enough of all that. So what we want to talk about today is the unpredictability of today's web. We want to talk about the things that we are seeing already changing around us and the things that are going to change in the future. So there's going to be a little bit of future gazing, a little bit of speculation and a few examples of things. Now I have to say, from having done this talk before, the examples you hear are not real. They're theoretical. There's no NDAs involved. It's purely theoretical stuff based on examples of businesses out there. I got questioned quite heavily last time I did this to an audience of journalists who thought they'd got a scoop. So just to put down on the bed. So today's web. Now I've called this talk the unknown consumer and in order to do that we need to think about, well, what's the known consumer? So when we think about the known consumer, what we're really doing is we're thinking about pretty much anything we're testing for and everything else out there is unknown. So when we started out in doing web development in Drupal and web development in general, we were thinking about desktops. We were thinking about different browser compatibilities and that was the extent of the problems that we had to deal with. And then over the years we've ended up in a place where we've now got to think about mobiles and think about tablets and different form factors and this sort of thing, as well as of course different browsers. Although the different browser situation is now not as big a deal as it used to be. So what we can assume then is that if we're going out and thinking about a project, we're going to be thinking about aiming at these multiple formats, whether it be desktop, tablet, mobile, super wide desktop or whatever. But everything else out there is what I'm talking about as the unknown consumer. These are the things that are out there that can consume the content of your website that you didn't think about, that you didn't plan for. And what we've heard about of course is this internet of things. So you're here, everyone's heard this phrase now, it's very much what's going on in the press at the moment. Well what we're seeing is that the internet of things when it comes to the press at least and a modern popular perception is that you've got these headline devices. You've got smart refrigerators, these things that know what's in your fridge and can make an order direct with the supermarket to restock your fridge. This is the things that have caught the imagination of the public. And we've got these other household domestic appliances that we're thinking about, whether it be the Hive, these types of domestic appliances that can also connect to the internet now. And really what we're talking about today is what are we doing with these devices? Then we've got a whole other sector of devices. That white doesn't come out very well. But this is an example of a billboard that was run a couple of years ago about British Airways. So what's happening here in this advert, it's controlled by a number of beacons that are detecting the flights flying over in Spickardilly Circus. And what you can see here is it's able to understand what flight just flew over, brings up the idea of that flight, the flight number, and where it's going and spinning up on the billboard. Now this is a couple of years ago, this is an award-winning ad. But this is exactly the sort of stuff that we're thinking about now and that's going to face us in the future. Where does the data from this billboard come from? It's content management system. And then we've got this whole other realm of devices. We've got environmental monitoring, infrastructure management, manufacturing. So big in factories, that sort of thing. Energy management, smart meters are now becoming a big thing. There's a big campaign, at least where I live, to replace every meter in every household with a smart meter in the next two years. And then we've got medical devices and healthcare. Pretty much anything that can be connected to the internet in some way is being connected. I won't even go into the examples that were coming up in the office yesterday. I mean the stuff, crazy stuff. And then we've got the stuff that's also been on the headlines, which people know about and people are aware of, but they don't really make the connection to the content. So we've got the consumer devices, the wearable devices, the quantified self. So quantified self is things like your Fitbit, anything that's gathering data about you. And then we've got this concept of smart retail where you have devices like beacons in shops that can actually tell what you're looking at, what shelf you're looking at, which pair of shoes you've just picked up and also with the use of an app can actually give you a different retail experience. And this is already happening and we're going to see much, much more of it. But the key is, in our context anyway, how many of these are actually content consumers. So we can eliminate a big swath of those devices because they're not really content consuming devices. Some of them are data devices that, you know, your Fitbit, you're not going to read the news on your Fitbit or anything like that, well at least not yet. So we can eliminate some of them, but there are some other examples. And again, these are examples that we know of through case studies that are out there. So Vodafone have a kiosk system in store and we know that it used to be controlled by someone going around to each kiosk and sticking the needed in and updating the content. That system has been replaced by a Drupal system that has all the content separate from the stores. And so that whenever there's a content update to be made, which of course is quite often, that content is pushed out to all of those stores via a content management system. So these are the things that, whilst not immediately obvious, are the types of things that we're seeing happening now. So even if you get cash out of a cash machine now, there's adverts in front of you, there's content in front of you. Every single place that you see a screen, there's content being pushed at you. And this is the future that we have to be ready for. This one is probably one of the most obvious ones. So that was an echo at Google Home whilst we saw with, this has been coming for a number of years with Siri as one of the early ones, but Siri wasn't really open. It wasn't accessible. And it's only when Alexa and the Amazon Echo has come along with a very, very open API, allowing the likes of us to just hack away and build something. And it's amazing to see how many of our Drupal shops and stuff around us are all having these little Amazon Echo hackathons going on. Because it's actually quite easy to develop an Amazon Echo skill that can deliver content. And again, there are Drupal modules that can connect to the Echo, and it makes it the perfect platform really for developing this kind of stuff. But it has to get content from somewhere. So we're going to look a little bit further ahead now, some of the things that are either happening right now or maybe not that far away from us. Again, theoretical, don't get excited. But anyway, this one, FIFA 17 football game, if you're into football, I'm not really, but I understand the concept. So FIFA 17, there's an idea of player rankings within the game that determines the AI, how, what they play, that sort of thing. Immediately this was launched, there's news stories like, oh, these rankings are wrong. Because this data goes out of date really quickly, or it's maybe it's wrong, or maybe someone's opinion isn't the right opinion. So what about if we could connect together the actual source of the data with the game? What if we could expose someone like a Premiership team? What if we could expose their content to the game? What if we get to a situation where, for example, I am watching a match on a Saturday afternoon and a player is injured, I picked the game up in the evening, the game knows that that player was injured and doesn't let me play with that player in the squad. What about if we got to that place where content and other consuming devices can actually do that sort of thing and this doesn't seem that far fetched to me. And this is again what we're talking about with different ways of consuming content. There's not a web page, it's not a phone, it's not a tablet. This is another example. This is the website of the FDA, the US Food and Drug Administration. We have the equivalent in the UK. But every medical device out there has the potential to be recalled for whatever reason. There's bound to be a fault in a batch or it's just bound to be dangerous. The only way to know if, say I work in a hospital, say I'm a paramedic, I've got this device in an ambulance, how is the FDA going to get hold of me to tell me to take that device out of service? It's going to happen via the procurement department of a hospital, probably a big complicated flow of communication before it actually gets to the end user that says don't use that device. So what if these types of medical devices could directly communicate with our content? What if our devices could check for themselves whether they've been recalled? And what if in a rather extreme scenario they could turn themselves off, deactivate themselves? I'm sure there's a few ethical arguments about that. But ultimately, what if these kinds of devices can actually talk to our content and act on that data? So this one, this is a concept from Mercedes. We've been hearing about the autonomous car that's going to be upon us within the next 10 years, if not sooner. And the fact is that once you've got a self-driving car, you don't even have to be facing the right way. Once they've properly got it right and you don't have to take over. So what about if this device has different screens inside it? Again, these are form factors we're not used to. We're not used to serving these form factors. We're not used to having this type of content consumption going on. So these are the things we have to be ready for now. And there's too many of these things. I've given you three examples. And the fact is we can't anticipate what all of these different consuming devices are going to be. And that's why we have to do what we do, which is focus on the data and how we present the data. And the reason for this is very much this one. Software isn't very good at interpreting meaning. No matter how much AI you plug into it, there's still room for error. But what we need to do is find a way to help that situation. So taking the example here. So we've got the Google autonomous car and we've got the root guide from the AI. Now, the root guide from the AI is very nice laid out for a human to read. And do you know what? It probably could be read by a computer to some degree of success. But it's not designed that way. It's designed for visual human consumption. So how we structure the data for machine recognition is a completely different thing. Let's take another example. This is BBC. BBC Good Food site. It's a recipe. And on the other side there you've got a diet tracking app. So what you're seeing here is, again, the recipe presented in a way that's human readable, very pleasing on the eye, very easy to understand, great UX. But how does that diet app understand that content? It can't. It can make a guess, but it wouldn't be a very good one. So these are the things we need to think about in terms of structuring content. Structuring content in ways that means other devices can understand that content. So how do we support them? This is the crux of it. What do we do about this problem that's facing us? A small problem now is going to be a big problem in the future. Now, we've already moved slightly away from this model. And this is the education process we have to go through. The web is not about pages anymore. But a lot of people do still think about the page model. Now, in the last few years, we've invented this semantic markup, semantic elements. And that makes things make a little bit more sense. I can define where the header is, where the navigation is, what's the main content, what's the side content, and so on. But really, this is only sort of signaling. This is only signaling to the devices which bits of the content are important. So what we need to do instead is we need to move beyond this sort of page-centric thinking into a place where you're thinking about the content model rather than about things as pages. And so our essential ingredients for doing this sort of thing, first of all, is a content modeling system and a way of structuring content properly. And, of course, a way of getting this data out there. Funnily enough, both things that Drupal and Drupal 8 excel at. But there are some challenges to this. If we take this kind of approach, then what we've really got to do is tell the content creators that they're not in charge of the design anymore. Every time you give someone a whizzy week, there's temptation to add some design to it. So the biggest challenge here is to step back from that and help content creators understand that what they're creating is content, not for a web page, but for a multitude of uses. And there's huge online debates that have been raging for years on this. So I'm not going to go into them, but I will reference some of them. So the blobs versus chunks debate. This is a great one. Sometimes known as the battle of the body field, which I think Eaton is one of the prime movers on. And again, this is a couple of years ago, but it's still going on. There's still a debate about should you give people a whizzy week? The moment you give someone a whizzy week, they start trying to do layout. We don't want them to do layout, so should we just not do that at all? So the battle for the body field, I encourage you to Google that one and you'll get some great content on that. The second argument that goes along with this is the adaptive versus responsive design argument. Now, again, Karen McCrane is one of the key advocates of this one, and it goes back a long way. And the main thrust of this one is that do we deliver the same content every device, regardless of its capabilities? Or do we change what we send to the device knowing that it can only consume this? Now, the original argument is we should always send the same content. We should let the device decide for itself what it wants to do with it. That's one side of the argument. Without sort of server side device sniffing and so on, we have to assume that we're always going to be fair and deliver the same content. So this argument becomes relevant again, much more so in that if you're talking to an Amazon Echo, there's no point in sending out 20-page piece of content because it's going to want to read the top paragraph. So we have to think about how we structure our content and what we do with it. So the next question that comes to us is, well, why would we want to do this? What's in it for us? It sounds like a lot of work. What's the point? So we have a number of business models here that come into play. The first one being the open data model. So open up your data in the most granular way possible and people will use it. People will use it in ways you don't even think about. So you take a really good example of that, someone like Strava, who all of that writing and running data that they've collected, you can extract that data and do whatever you want. You can remix it. There's great apps that can put all that writing data onto a video, a 3D video, which looks amazing. And they're not necessarily charging for that. So having everything wide open and making sure that your data can be consumed by as wide a variety of people as possible, of course you can have paid API access so you can make it to a chargeable model. You can remix our content for a fee or even a slightly different one being that you can actually pay per access to the API. So these are things that we can think about. And the other thing we can think about is if we're a media publishing company or something like that, maybe we can add more value to our existing content by offering these different devices and different options. Maybe we can give our news feed to a service that can do something with it that's interesting. Again, that's outside of our control. And this always made me think when we were talking about this, maybe this concept of naked content, unstructured, well it's very structured, sorry, but undesigned content. Is this the way we get around the ad blocker? We changed the model, we do something different. So okay, that's all very nice. But we are where we are. So how do we get there now? So this is where we get to a little bit more specific, a bit more practical. We need to have a structured content model and those of us who have been working in Drupal have been doing that all along. And we need to expose the content using a document of API. Now again, this has been possible via the services module in Drupal for a while, but with Drupal 8 this has become much more mainstream and much simpler to do. But the first thing is the fundamentals. It's before you even get near Drupal. It's getting this content model right. I want to give you another theoretical example again of a news article. So traditionally this is what we would do. You've got your headline, you've got your body text and you've got an image. Fundamentally that's it, right? You don't need to do much more than that. This one is taking an example of an article that belongs to a football team as the referencing back to the example earlier. So, well okay, it's an article about a football team. So it might relate to a specific team or to a specific player or to a specific match or fixture and maybe that fixture is related to some highlights reels or what happened the last time we played that team. Or what about if there's commentary? Okay, well we need the results as well. And maybe that fixture is part of a competition, FA Cup say. So we want to see what the standings are in that competition and what if the players in that team for that article or if that article is about specific players, they might have their own series of content, they might have their statistics. So there's a whole bunch of stuff that very very quickly builds away from that standard model of an article. So we get to this place where we have these lots of small pieces of discrete content that all interact with each other. And our process very much is to start thinking, forget the technology, think the content model through how all these things can relate to each other. And then again from what we're talking about today, how we can use those individual pieces. So for example player stats could be very finely granular and could be used for all sorts of reasons. So this one's a it's, you know, loosely theory. But since we've been doing Drupal 8 and we're all switching our heads to OOP, what I want us to do a little bit is very loosely pick this some of these concepts up. Now I'll say very loosely, I did this presentation to a business audience, not a technical audience, so I could get away with it. Will you lot? I'm not sure I will. Anyway, we'll try. So what I'm going to do is take some of the concepts of OOP and apply them to content modeling. So the actual objects, the classes, we're going to say are the same as the content types. And the code is in the form of methods. And then you have a single responsibility principle. So the basic thing about OOP programming is that an object does one thing and that's the anything it does. And it's single responsibility. So if you loosely map that over to the content model, your content type should be really, really simple. It should only do one thing. It shouldn't be ambiguous about what it does. And we don't want to assume that anything else about that content type is present. Also within the content type, each field within the content type should be really, really clear about its single, single purpose. So from my trawling through history of Drupal in many, many projects, to become a bit more practical, I want to show you some anti-patterns that we see all the time have been guilty of, I'm sure. And I'll give you my top three. This is my first one. This is one I really hate. Do you know the non-content content? And we see this one a lot. What this is, is when you have a content type that doesn't do anything, a content type that's only purpose for existing is to take you somewhere else. Basically a link. Now, we do end up in this situation from time to time. But it's just really annoying. Because the moment you've got there, you've got these little bits of content that make no sense on their own. They get picked up by Google, they don't really have a formatted page, and they have to put things in like the rabbit hole module and all these hacky things to stop it happening. But instead of that, what we need to do is think about view modes and how we have the same content viewed in different ways. So this is an example of a teaser. How's this going to work? Okay, a teaser. And the full screen, the full article, which leads up to the full article here. So I'm just going to flip back a second. Instead of having a jump, have a teaser is pretty much the basics of this. There was no need for the jump to exist because we can just show a short-form version of the article. And that way, we've got our article completely in one place with all of its content together. That's number one. This is my other favorite. I refer to the Godzilla content type, the monster content type. What happens here, and this is very, very common in sites that have evolved over many years, you start off with a very clear content model, but then gradually more fields get added, things get hacked around a little bit, and it certainly immediately violates this single responsibility theory. And often it leads from a team's reluctance to have multiple content types because they perceive that multiple content types makes a site more complicated. But in fact, by having one content type that can do many, many things, you're actually making more content, more complicated that way. So instead of that, yeah, it's okay to have discrete small content types. And we think about the relationships between those content types instead. And again, we think carefully about that single responsibility. So there's never any question about, okay, I'm coming as Craig some content on the site, I know exactly what I have to do. And the next one is sort of related, and that's field ambiguity. And this is one where you've got multiple fields in your content type, but you're not quite sure what they do. The way they were named maybe isn't clear, or maybe even worse, they do different things depending on different scenarios. The moment you've gone into this area, you've got a lot of structure of your content type, it doesn't quite make sense anymore, and then you're in a bad place. So instead, we do have to do this content modeling exercise up front with all content stakeholders, not just the techies, we make sure that the people who are actually creating the content are involved and every content stakeholder is involved. And of course, nice clear help text so you know exactly what it is that you're creating. Oh, I've got a fourth one, another favorite. This is the using content for logic one. So again, what you're doing here is you're creating fields within your content types that aren't really content, and you're doing it for reasons like if I fill this one in, make the text, make the background color blue. And it happens all the time, but if you think about, again, you're thinking about non-web page delivery, that field makes no sense whatsoever anymore. So we have to think about this and we have to think about the right way to do it. Don't mix your layout with the content and make sure the application theme layer is doing the intelligent stuff because that's where it belongs. Okay, so what do we do next? We need a CMS with a good content modeling tool set, which we have in Drupal 8, which is great. We need to start the education process or at least continue that education process so that people understand why we have structured content. We're not doing it because we're developers and we like things that way, we're doing it for specific reasons that we've talked about earlier in the session here. We need to split that content from the design, we need to make that separation happen. And in order to do that, we need to handle these creative objections. We need to help these editors and content creators have that creative freedom without actually being a designer. So taking away the witty week. And we need to spend a lot of time on the content model, in fact much more time than you might think you need in order to get this stuff done. And what I see here is that by going through this process, I don't know about you, but every project I do or I get involved in seem to have a massive lump of migration work involved and that might be bringing historic, you know, seven years worth of historic content across to a new format. If we take this approach, this content model approach, with an open API, then maybe we never have to do that piece again. Maybe we end up in a place where that content can live on, even if we change systems or we change our front end or other things come along that we don't even know about yet. So I say future proof of content, but really we know we can't do that. So the best thing we can do instead is prepare, prepare our content for the future. And that being, you know, ensuring portability of content between systems now and in the future. So I think the underlying message for me is this one. It's embracing the unknown, preparing for it now, but really importantly creating a legacy. There was a keynote, I can't remember which conference, it might have been a Drupalcon, from the Internet Archive, about how much content has been lost. You know, it used to be the problem we had was disk formats when it came in and out of style, you know, mini disks were here for no time at all and then they're gone. And now we can't read those devices, no one has anything to read them with. And it's the same with content. Because of the fast-moving pace of the web at the moment, we're in a place where we're going to have a 20-year period of content that just goes down the tube somewhere and we'll never see it again. I've worked on projects where the decision has been made to, okay, let's just migrate the last two years of content and not worry about the stuff before. And once we go down that slippery slope, we're going to be, you know, have a gap in history of this really, really important content. Even though we're creating loads of it millions of times more than we ever did, I personally think it's really important that we're creating a legacy in our content and having a content management system with an exposed API that we can exchange the other pieces of is really key. So, I think that's my time and that's the end. So, I think I might have time for some questions if you have any. Thank you. It's difficult to say. I mean, in the end, anything we do, we're making big assumptions. And there's no real stakeholder today that understands what's going to be there in five years' time. There's lots of speculation, but no one really predicted the Andoneco properly. No one really knows what impact the autonomous vehicles are going to have. They're going to have a massive cultural impact on us. And maybe the sort of bit I'm talking about is probably very marginal. But I think we can probably assume that, again, you know, iPads, tablets, and no one sort of, apart from maybe Star Trek, predicted these things very well or what their impact would be. And we're very good at knowing, we're very good at trying to figure out extrapolating what we know now. What we're not very good at is when something completely different happens, which is pretty much every time. And this is why, you know, when cars were invented, they were like horseless carriages. But people didn't really think, they think evolutionary to the next step, they don't think five steps ahead. And nor do we now. And we still are not really capable of it. So all I'm saying here is that we have to do the best we can right now with our model to make sure that we are prepared for these things that are going to suddenly jump out. Maybe we'll be the ones that are in some sort of place to benefit. Hi, thanks. Just think about the canonical model of data. To what extent should we all be just using something like a schema or using that as our chemical reference? So that is doing our own modeling and thinking about how the world might look to our particular project. We should say no, no. But in the same way you're taking away the WYSIWYG. Yep. And the emphasis, because thanks for the choices, should you be taking away the content modeling from the content model and saying no, let's use what is agreed and defined already? Yeah, that's a really good point. Schema.org does come into things. Whether it covers every scenario, the trouble is with something like schema.org is that it can back you into a preset shape. Which is useful when you're, for example, when you're sharing content out to Google or Amazon or wherever, then using those types of models is going to really assist you. But when you're talking about something like the example I gave earlier, it's not really a direct mapping system out of schema.org. So it's a bit of both, really. I guess. Hiya. Hi. Okay, thanks. Yeah, it's been loose. It's been loose, you know. Yeah, but one of the obvious things that we see from what you'll see, Drupal's content type, is inheritance. So you can't have a generic article type that only inherits or is inherited by it. Yeah. And is that something, is that thing, you know, is that something we should be looking into? Well, it's true. And I've not, I've not tried to solve that as a specific problem, but in a way, by breaking the content into the really small elements, you, it's a real stretch to say you are having inheritance, but what you're doing is reusing pieces. And so, you know, fixtures, teams, players, that sort of stuff. So we do find that there is an element of reuse and trying to move away from that gigantic content model or content type, because everyone thought that was easier, is that the content, it doesn't have to think they're just, I'm creating an article and then I'll fill all the bits in. I personally think it's much better that they know that they're ever creating an article or a press release or something else or something else. That, and then they're filling in the minimum they need to fill in and then making relationships with other bits of content, is the way I think. Yeah, exactly. Yeah. And you know then that the moment you go to create your content, you're already prepared for, okay, this is going to take me an hour to get this one article out there or whatever it might be. And you probably don't remember what 40 of them do. Or, yeah. It's not just that, it's that you're in a relationship to access it. Yes, true, true. I wasn't saying, we should have, I was asking. Yeah, yeah, yeah. And I'm just giving you a comment on the question. Sure, yeah. Come on, say hi. Thank you. We've tried this thing of separating content out into a separate system. One of the things that you've touched on is, is breaking people away from page design. Yep. Are we going into a tip on that process? I wouldn't say it's just, yeah. So to repeat the question, the question was, if we're going to split content from design, have we got any tips on how you actually achieve it? My question is in the kind. Yeah, sure. I'll answer that together, maybe. So I would like a short one to tip through people who can see the state of the mind. Yes. And get in shape and change what it looks like. So the main question is how do you start to educate stakeholders to develop a structured content and how to structure their content in the larger part of the site? Really, the question? Sure. The larger part of the site. Yeah, so a related question, which is about, you know, how do you educate stakeholders to the benefits of structured content? I give them this talk. I try and open their minds to, this is the stuff that you're going to need to be ready for, that it's not in your spec. And if you don't think about this stuff now, your website, the life of a year, maybe two, and you'll be doing this again. And maybe that's what they want, in which case maybe this time I didn't win. But on the other hand, it's about, yeah, as I say, opening their minds past the spec they've got of, I need to build this insurance website, to, does my insurance website need to give quotes over Alexa? And they may be, that might be in their roadmap, way, way, way down the road, or it might not. And they just haven't connected it yet. They haven't connected the, oh, there's a team over there doing Alexa. Well, hang on, why aren't we talking to them? And they'll probably end up talking to each other, six months down the road, and it's too late to do anything about it. So our process really is, yeah, get in early, before we do a lot of discovery, and that sort of stuff at the beginning of projects. It's very much getting this type of thing out there, helping them understand that there is a benefit, and that's the thing. There is a benefit to you not doing this. And actually, do you really want to do this? Are you really a designer? What are you really saying is, I want the image on the left or the image on the right? And we still end up building sites with things like paragraphs, which maybe isn't fully embracing this, but it's a step in the right direction. I think part of an administrative staff, they see a staff page, they want to change the bio of a person. We're telling them now that you don't get in that page, you go to somewhere and you do it, then you find the field in the form, you get the updates, and they say, well, I don't know what that's going to look like. Do you think it's something else? That, I don't, I mean... You don't go to the same... Yeah, it's a difficult one, and you have to... You have to go with the staff, that's the best way... Yeah, and it is very much, you have to sort of show them, and show them that if you do... And currently we're building a project where it's 50 franchises around the world, but all the content is entered in one place and then beamed out. They never see it until it goes live, but we've had to go through the education process of saying if you fill in the headline and the body in these fields, and here's your template of what it will look like, and it will work, and it's definitely a process. It's not a, just accept it. Yeah, yeah, there is a lot of that. So I'm going to... There's another question at the back there. Yeah, yeah. Okay. What's your view on... So you dispose... So the question is, how do we deal with content that disappears after 24 hours? So Snapchat style, disappearing images. I mean, I don't really see there's much difference. I mean, the final few slides I had there was about the content legacy and how I strongly feel that we need to keep the content legacy, but actually in the context of that kind of data, obviously there's no intention to keep it for long periods of time. But I don't see there's any difference. Yeah, there's not so much in that bit. Mm-hmm. How do you... Yeah, yeah. Yeah. Yeah, it's very, very... Yeah, it's really interesting. I think, again, it doesn't change technically how we achieve it, but maybe you could extend the concept of the unknown consumer is the unknown consumer behavior, in that we never really thought that that was going to be a thing that people would want disposable content. Then when it came, it was obvious. So yeah, I think... I don't know if I can really specifically answer the question, but certainly how you would do it and through the APIs and that sort of thing would make it perfectly possible to do it, even if you did keep it. But yeah, trying to predict be flexible enough to predict these different ways of paving, and especially in media and publishing now, we've got all these different places that content can go, Apple News and Google and all that sort of things. So, again, not necessarily predicted, but when you're using a system and design this way, it means we can pivot quickly into those new ways of consuming. I think... Can I do one more? One more? No, apparently not. Sorry, maybe you can chat to me afterwards. Thank you very much and enjoy the rest of your day.