 So, for a long time, especially after starting to work with Drupal and really getting into building out lots of big sites with it, I really had this dream, I had this conviction that we'd solved a lot of the really fundamentally crappy problems that the web had presented us with. How many people were building out big content websites, even medium-sized content websites in like the late 90s, where like we actually went and made HTML files, did anyone, yeah, made with Notepad. Back when we put badges for the HTML editor that we used on like the bottom of the web page and everything, those were the days. Yeah, that was also really hellish because although we had like complete freedom and complete flexibility to do whatever we wanted to on a given page, it was also a giant horrifying pain whenever we did a redesign or whenever we decided that we needed to adapt some of our content that was on one page to use in another part of the site. Reuse was incredibly nasty. I mean, the process of redesigning a website was basically hiring piles of interns and just remaking hundreds to thousands of web pages. That's terrible. We've solved a lot of that in the modern era. We've solved a huge number of those problems. A lot of what we do day to day in Drupal site building is all about building out content types, fields, structures that link these different types of content together. We've taken all of the ugly muddy blobby aspects of the stuff that lived in those big fluid HTML files and turned them into well-defined fields that editors can just pop up in a form and type stuff up into and have a good time. And then the theme layer template pushes things through templates and everything gets turned into a cool responsive design. It's awesome. I for a long time thought we'd pretty much wicked a lot of this problem that when people put nasty, ugly, cruddy HTML into the body field of a piece of content that it was user error, that it was just a problem that we were slowly but surely getting rid of. Like, you know, Marxism is ultimately just going to solve all of our problems. And it's just all the little ripple effects of, you know, the old system dying away. No, no, humans. HTML, it's still there. Yeah, that was a little bit of a stretch. But I always try to get a weird political reference in when I can. The real problem is that even though we put tons of energy and built fantastic tools around breaking up these weird, ugly HTML blobs, into nice structural pieces that we can manage and pump through templates and treat as structured data, we've only really kind of pushed the problem out to the edges. The body field, that big wad of stuff that an editor pastes in from Microsoft Word or that somebody pops open the whizzy wig editor and just starts slamming on buttons until it looks right. That stuff still has all of the weird, ugly dragons and nasty bits that we tried to solve with old HTML files moving into this new system. It's still there. I thought it was something that we could just train people out of. I thought we could just strip more and more features out of the body field. If we could just get a better whizzy wig editor, convince everyone just to use markdown. Everything would be fine. That's not true. And about probably three or four years ago, there was a project that broke my spirit. It really convinced me I had been looking at it wrong. It was a really, really big website, about 50,000 pages of a corporate HR intranet. I mean, not like a fantastically high profile project or anything like that, but a big multinational organization said, we've got thousands and thousands of pages detailing our policies, our insurance signup forms, travel policy, where to go to get a replacement key card for the door and building 59, literally everything. It had to be localized for 20 different countries in different languages for all of the European countries and cover all of the different employment statuses, HR policies, everything that was possibly conceivably needing to be documented, they had on there. And it was being maintained by hand by tons of people. And it was just nasty. They wanted to turn it into 50 pages. Super customized, super personalized. They had all the user data. People were going to be logging into the website. We could do cool stuff. We could just reduce all of that special casing. I was like, yes, yes, structured content, fields, content types, roles, permissions, user profiles. We can do this. We have the technology. Super cool. And it actually was really cool. They had a great vision for it, great solid, clean design. The idea was they were going to have their actual HR team editing all the content. It wasn't going to be like HTML designers doing crazy stuff in there, but they really actually had some very specific ideas about what they wanted. They wanted it to be really rich. They didn't want to just have text in there. They wanted to have things like on the 401k page. There was a calculator right in the body of it where you could just start calculating stuff. If you already had your personal information entered in, it would even pre-populate it with what your 401k data was, and it would show you all this cool stuff. And with just 50 pages, maybe 70 by the time it ended. But the problem was none of this stuff was predictable. None of it was like followed the kinds of structures we would think of using templates to solve, or using all of Drupal's normal tools. We couldn't say, well, what's this type of page? Well, there is no type of page. It's just these pages, and it's just all fluid and crazy. We just needed all of the structure, but they needed total flexibility. It was a little bit frustrating. And then on top of that, they needed the personalization stuff to be very fine grain. I thought, oh, well, perhaps we can layer maybe some access controls on top of Drupal's fields. When there's a piece of information that's for one type of person, we could put it in one field. And for another type of person, it could go in another field. No, at the sentence level, they wanted to personalize it. So this particular phrase might only appear for a manager. And for a retail employee, this bullet point would appear in a bullet list in the text, but it wouldn't for anyone else. It was a really bad match for a lot of the tools. I'd spent so much time deeply investing in and getting really good at using. It was really frustrating. But at the same time, they knew that it was a dead end just to throw editors in a raw markup at the problem, because that wasn't sustainable. They needed basically all of the power and flexibility and reusability and structure of the fields and the content types and the templates. But they also needed the flexibility of basically raw markup and the ability to go in there and tweak and twiddle things at a very fine level. And they also needed the editorial interface to feel simple and smooth, like writing something, not like clicking together a bunch of Lego blocks into something resembling a sentence, because they wanted to be natural and smooth and easy to read and also easy to translate into other languages once they'd written the canonical version in one language. That broke me. We did solve it. It took some time and it took some smart folks like putting their heads together. I won't go into the details, but it was a crazy combination of input filters, CK editor plugins, panels for certain layouts, special like block stuff embedding. A lot of different pieces ended up getting brought to bear on that. But it really got me thinking, why was this so tricky? Why was this so hard? Why was it so painful that what, you know, it was a big pile of content, but like it seemed like all these incredible tools we had should have been able to like just crack that nut. What made it so tricky? And right around the same time, there was a big, big splash in the world of journalism and digital content that got everybody's attention. Does anybody remember the Snowfall article from the New York Times? Does anybody still dread having a client say, you know, like Snowfall? If anybody remembers, in 2012, they released this incredibly huge, deeply researched article about a group of hikers that had gone off into the mountains, been trapped in an avalanche, and it was rich with like data visualizations about the path they'd taken through these weird, you know, winding canyons. Little interview clips with the people that searched for them and the people who discovered just when they were missing and pieced the story together. Interviews with the hikers themselves, you know, little flyouts of the equipment they were using and how some of it broke down on them and some of it was critical for their survival. It was a really, really interesting and rich piece of very compelling narrative, and everybody loved it. And I started looking at it, and I was like, wait, so why aren't we always doing this kind of stuff? Why don't we constantly produce these things? I mean, it took a lot of investment just to make all the content for that, you know, producing all those videos and visualizations and interviews isn't something that's cheap, but it seems like, you know, we should be doing this kind of cool, rich media stuff all the time. And, you know, if you look at, you know, this is a screenshot from about halfway through one of the chapters of this article, it's just littered with little bits, like the first time a person is mentioned in the article, their little bio appears up in the sidebar right as they're first discussed. Not just, you know, somewhere in the sidebar when you're scrolling through, but right when they're talked about. These little photos that are interspersed throughout it are actually full complete slideshows embedded right when they start talking about different things that were going on or a particular base camp that they ended up staying at as, you know, Nightfell or something like that. And I realized, wait a minute, this is that same weird slippery problem of trying to take those complicated, weird like structural elements, things like the 401k calculator and the information about, you know, how to go on your trip to Europe with the rest of the company, that we can't really just throw into a field and hope the templates will take care of it. We actually need to be able to weave it in through the structure of a narrative piece of text the way like a writer or a journalist would sit down and write. And the tools that we've got make that really hard to replicate. And I mean, we can do it, it's HTML, it's computers, they can do anything if we try hard enough, but it really bypassed a lot of the tools we'd built to make things smooth and efficient and reproducible. So the New York Times made this, but I think it was something along the lines of a quarter of a million dollars they ended up spending building out this article and the text stuff that they ended up doing and, you know, the visualizations. So it was a huge like moonshot exercise to do this without all of the preexisting supporting tools. And then when I started looking around, I started seeing this kind of stuff everywhere. It was one of those, you know, once you notice the thing, you can't stop seeing it everywhere you go. I saw other articles, this is from The Verge, it's a review of the Apple Watch that just came out. And it's just thick with like background images, washing behind paragraphs, little interstitial, you know, graphics of how the watch is assembled, you know, the little dots give you progress indicators as you scroll down through the article. And this isn't actually how every article on their site looks. They heavily customized this because it was a high profile piece that they wanted to really promote. This is, I think, Polygon.com's review of the Xbox. They had little SVGs that like animated like how the case opens as you scroll through. This is a piece from CNBC. It's not quite as obvious, it's not quite as flashy, but like that little picture of the Pope sitting there is actually a relatively complex little bundle of HTML there. It's got captions, it's got links, it's got photo credits, it's got the actual photo. Behind the scenes, it's actually got a link off to another article about the Pope that's there. And it actually needed to live at a particular spot in that article. It couldn't just be a related article that we slammed in after the second paragraph on every page or something. And we find this a lot with media clients. Like if you're, say, writing a big article about a speech and you've got a video clip of it, you don't just want that slammed at the top of the article. You may want it in the middle when you're actually talking about the content of that particular speech. This is another news client that we've been working with occasionally. It's, you know, you've got actually a fair number of little structural elements in here. We can all, we've worked with Drupal, think about how we would break this down into fields and stuff like that. But the important thing to note is that these little pull quotes with the attributions and the sourcing and stuff like that are actually at important, meaningful places throughout the text. They're not just associated metadata for the article. They're part of the flow and they need to be treated like that. So I started to see this everywhere. All the clients that we started talking to had some sort of need for this kind of stuff. And it was part of like an ongoing series of increasing pressures that more and more content publishers are facing. They needed greater flexibility so that they could do cool and interesting things. They needed to be able to reuse their content more efficiently, pushing it to other platforms, putting it on mobile apps, being able to adapt it to responsive design as they rolled out those kinds of projects. They needed to be able to produce it faster with less effort. And in a lot of newsrooms, the need to create more and more interesting compelling content was not coming with some new wave of extra hands to help produce this stuff. They actually had to figure out how to make it do with tighter budgets and fewer people in the newsroom. And then there was more and more competition in the world of people building these interesting and cool, grand websites. There was more competition to make their narratives rich and interesting and attention grabbing. It was all really tough. So after looking at a bunch of this stuff, I started thinking about it and identified a couple of really key characteristics. The things that were common factors that made this particular really tough problem, what it was. The first part is long narrative text, something that actually needs to be read from start to finish and has a flow to it, not just disconnected little chunks of text. We have a lot of really cool tools that if what you're assembling is like a bunch of different statements about a product and a call to action and a photo, you can assemble those really easily and really quickly with different things we have in the Drupal world. But if there's long narrative text, we say, oh, well, that's the body field. And then we get back into that danger zone. Then we've got the problem of islands of structure, things like photo galleries or step-by-step instructions that don't necessarily just fit into a simple unordered list or data visualizations that you want to embed that require more than just an image or something like that. It's like little pockets of complex structure that need to live in there. And then the final one, the real sticking point, placement that actually matters. Like the classic one is footnotes. It's usually simple textual content, but you can't just have a footnote sitting at the end of a chapter. It has to be meaningfully linked to the place where it's referenced. That connection has to live there. And any combination of one or two of these things is pretty easy to solve with the tools that we have. But whenever all three of them are there simultaneously, it got super painful. This is actually a screenshot of an article about Flipboard that Dries mentioned in his talk. They do a lot of stuff with super smart templates. They have templates that adapt to various layouts and stuff like that. It pulls in RSS feeds, parses what's inside of them, comes up with cool and interesting layouts. But the problem is, templates like this aren't able to respond to what's inside of the content. It's still a body field with photos. It can maybe pull those out. It can come up with an interesting layout, but even in the Drupal world, with all the PHP we throw at it, this kind of stuff isn't something that we can really solve just by telling the themeer here, go do something crazy. And more fields and entities, trying to break down our content into smaller and smaller chunks is also not quite a good solution. The paragraphs module is actually one that I really like for those kinds of assembled aggregate pages where you've got, say, a blurb of text and then a listing of some stuff and then a photo and then another blurb of text. But the problem is, is if you're treating a long narrative chunk of text, like an article or, say, a novella, in that manner, it becomes really, really difficult to actually edit it like narrative text. You've chopped it up into a bunch of different fields. What happens if you wanna take that image and move it up to another paragraph? Well, you've already chopped half of it into one field and an image in this field and it ends up becoming a really difficult way of editing things that disrupts that narrative flow. And another thing that I think all of us in the Drupal community have lobbied for is the idea of cleaner, more semantic markup. The idea that if we just get people to use less crappy HTML, if we can get them to stick to a magical subset of tags or maybe use markdown, that will just solve everything, then we can just have CSS and some lightweight JavaScript that just magically on the front end solves this. Well, the problem is, this is about as semantic and clean as I could get a photo gallery to be. All of the actual heavy lifting of how it should look cool, how it should be presented, that's somebody's problem to solve with JavaScript and class skating style sheets. But this is the structure of a photo gallery that I say wanna place in my news story at a particular position. Now, the interesting thing is as simple and streamlined as and semantic as it is, it still imposes a lot of things that are inspired by the design that's currently there on my hypothetical website. The fact that three of the photos from this gallery are listed there. The fact that each one of them links to a particular photo, not to the gallery itself. The fact that there's a particular tagline that goes to a particular URL. The fact that there isn't any particular other text underneath the tagline. There's no title, there's no attribution. These are all important design decisions that may be perfectly valid at the moment that that chunk of HTML is dropped into the body field. But six months from now when somebody says, oh, hey, you know what? We actually wanna put an interstitial image in the fourth slot in each one of our slideshows. Well, if we relied on pure semantic HTML to solve this problem, we're back at square one. We've gotta go through and we've gotta pick through all of our HTML and try to fix it. And it's terrible. And this is actually one of the reasons that increasingly more and more powerful and more and more streamlined whizzy we get editors aren't necessarily the problem. If we give people a button for every different HTML tag and we take out buttons for everything we don't want them to put in there, they're still using those elements to spell out a large structure in HTML that really just represents the idea of, I want that gallery to go there. They're still doing the work of a front end developer basically right there in the body field and that's dangerous. The problem is a vocabulary mismatch between what we're giving people and what we actually are asking them to do in the text that they create. HTML five is great. It's given us a lot of new semantic tools, things like asides instead of just a div with a class of sidebar. We've got sections, unordered lists, paragraphs, citations, emphasis. Nobody uses the itag anymore. We all know that we shouldn't do that. But in content, the actual stuff that editors are working with are things like teasers or chapters or related stories instead of just an unordered list. They are thinking about author bios or photo credits or the fact that something is promoted, not just emphasized. These are all the language that the people working with the content and even the people designing the content are using as they try to work with it but we're giving them like this different set of tools. Doesn't matter how smooth and convenient and attractive it is. It doesn't matter how much we hide actual markup codes from them. We're giving them like flashcards for the wrong language and asking them to make the best of it. And that's where a lot of these long-term maintenance problems end up coming out of no matter how rigorous we've been about trying to make everything quote semantic. So there is actually a solution. This is the good news. I've been sort of building up to the existential horror of all of this terrible stuff living in body fields. The really important first step and this ties in with that idea of the vocabulary mismatch between HTML and what people are really talking about when they talk about the content. We already do this in the Drupal world and like in the content strategy world. When we start planning out our content we're very used to looking through and picking out the essential little bits of atomic content that live on a site or in a project. Things like, oh, well there are chapters or prizes or stock quotes or sessions or blog posts or something like that. We're used to thinking of those content type boundaries and we're even used to thinking of teasing out like what the individual fields in those content types are but what we need to start doing is thinking not just of content types and fields but what the actual vocabulary of the content is. For example, if there are always next steps and calls to action laced throughout the text of news stories, well that's an important structural element even if it doesn't become a Drupal field. It may have design treatments that go with it. There may be certain ways that editors always approach that and always input it. Even if it's very lightweight that's something to hold on to because the developers need to know about that. The designers need to figure out how to treat those things and how to build design components around those things and the editors, if they're thinking, oh well I'm gonna write up an announcement or something like that. Even if it's all going into the body field, even if we don't have structural elements to support it they're thinking about those pieces. So that vocabulary that we provide people is the first starting point. That's not something that any individual team, the dev team can't go out and figure that out. The designers can't just go off and whiteboard and wireframe that into existence. That's something that requires everyone to get on the same page and talk it through. The next step to that is starting to look through the stuff that people are being asked to enter into that body field and locate and eliminate the boilerplate HTML. Like that gallery example we were looking at. Technically, the only things that were really actually in there that captured the fact that this was a particular gallery at this particular place in the article was the ID of the gallery and that special tagline that they happened to have entered in when they put it in there. Now, did anybody who's ever had to work with an XML based system don't freak out? We'll talk this through. What if, and I know this is crazy talk, what if we took this and just put this in there? What if we just said gallery one should go here with this tagline? Just gonna, yeah, okay. Okay, you sir, I'm with you. Do I get an amen? Thank you. Just stick with me here. So the key idea here, I'm not talking about like crazy XML business, nobody needs to think about data, is taking all of this stuff that is really just the design manifestation of the idea of what a gallery currently looks like on the site and just store the fact that gallery one with this particular tagline is what somebody entered. That's our starting point. The next one is when positioning matters. We were talking about those structural elements that need to be placed in important meaningful locations throughout a long piece of text. Well, the same kind of stuff that we're talking about reducing the complexity of markup structures can also be used conveniently enough to capture that something ought to go here in the text. That same gallery tag can be laced at a random point through the body field and be used to say import a gallery node from somewhere else on the site and slap it in there. Or say you've just attached a bunch of photos to this particular node. It's now carrying those around but you want them to live right there. You can use tags inside of the body field to say that stuff should go right here. You're no longer putting piles of weird structural markup that have all kinds of design dependencies and complex structures that editors or content authors need to memorize and figure out how to enter properly. You just have these simple, relatively short tags that conveniently enough, it's also very simple to create WYSIWYG editor plugins that can insert and manipulate those kinds of things as opposed to trying to parse the full structure of a photo gallery and manipulate it accurately inside of the body field. The actual details of what you use for those kinds of placeholders is way less important than the fact that they're just storing the essential information and that they live in the body field itself. Like this is more of an XML custom tag thing. This is an HTML5 div just with an extra data attribute on it. This is just like a Drupal token. All of those things, there are tools in our ecosystem to make those things work. Once you have that vocabulary and you know how you wanna put these things in there. And the final step that's really important is accepting that there's always a transformative step when content that just stores the essential meaning and structure of what you care about and what the author is capturing. When that goes out to another form like your webpage or a mobile app or an RSS feed, there's always going to be a transformational step going from your content vocabulary to the language of a web browser. This takes a little getting used to sometimes because especially in the Drupal world, we've gotten used to the idea of input filters and content filters just taking stuff and like scrubbing out bad things. The idea is that the real markup that we wanna show, it's still being stored in there. It's just being tidied up a little bit. Occasionally we'll enhance that but even though we've got this fabulous input filtering mechanism running in Drupal and we can do all sorts of interesting transformational stuff to what's been entered into the body field before it goes out to the public, we've never really as a community accepted that there's just always going to be a step where the stuff that people get entered gets transformed into what ends up being displayed. An example like this little gallery ID one with a particular tagline, all kinds of interesting stuff can be done with that when it actually comes time to put it out to the public. On the mobile web you could say, hey, our basic like baseline mobile first website is just gonna show the title and a link to the photo gallery. We'll transform that before it even gets sent to the browser. On an enhanced website we may end up turning that into like a complete scrolling gallery using client side scripting that loads after the page is already in. When it goes out to an email on say like a mail chimp link, we may include one static image and a caption and then a link off to the rest of the site. Partner APIs that need to consume our content will just strip out all of that rich stuff entirely and give them pure text feeds. The idea is that once you've stored just that actual meaning, you're no longer like trying to write all of the smarts of a web browser to reverse engineer what crazy weirdness happens to have gone into that article from 2004 and turn it into something meaningful today. You're just taking the bit that says this is what's here and turning it into what you want it to be on the output. That's a big step. And the nice thing about this is that although it's a mental leap, it's a mental shift to start thinking about planning and designing and architecting a Drupal site this way, it's not rocket science on the technical front. We have lots of the individual tools that do each one of these things but each sort of piece in this puzzle ends up mattering when you're in one of those big rich long form narrative text scenarios where you can't just sort of fake your way around the fact that weird detailed structural stuff needs to live at various places. I see a couple of people that are thinking I don't know. I'm not sure. I think I'm being tricked into using XML somehow. That's okay. The thing is, this is not actually a crazy pants idea. It's actually in use on a lot of sites on either a large scale or in small ways. This is a screenshot from Haslett. It's a Canadian literary magazine that we've talked to. I mean, it's not as media rich in this example of some of the other things we've looked at but things like certain portions of the text being pull quotes, certain portions of the text being called out in like footnotes that float in the sidebar next to where the, where the footnote notation is. All of those things are technically possible to do with pure HTML. But when they started saying, hey, instead of a bunch of spans and classes that our editors are asked to sort of go in there and add manually, how about we just like have a footnote button and support that? It really dramatically simplified things. And they can transform that in different ways like the printer friendly version can actually format things differently very easily. This is one of the very, very lightweight examples. We're easing into it. Don't worry. There's going to be crazy PantsXML shortly. This is another interesting example from the BBC. Over the past couple of years, they've been moving to a complete like responsive stack for all their different websites. And one of the things that they've been doing is looking at the patterns that emerge as their journalists write and produce stories. Things like what requests are journalists putting in for support assets from their design department? What things keep coming in and people keep wanting to use? This is an example of something they ended up calling the data pick, data pick. It's basically a combination of a photo, a title, some number of different statistics. It's all like a percentage or a number or whatever. And an attribution at the bottom where this source, where this information was sourced from. Now, structurally, it ends up being like a bunch of nested divs, some CSS classes, ordered lists, all of the little bits of markup that are necessary to make that consistent and reproducible. But as far as an editor or a writer or a journalist is concerned, that's the title, the image, the stats and the attribution. And they standardized on this and actually made it a reproducible structural component. Now, what they've done is they've made a little builder. BBC journalists can go to their data pick generator entering all those things and it spits out the stuff that they can just paste in there. Now, I would personally say perhaps they should put some markup in there that strips that down to just what it needs to be and transform in the output, but you know, baby steps. The idea is they're identifying what the vocabulary of their particular site is. The data pick, this particular way of capturing and presenting little bits of information, is at this point, distinctively uniquely BBC. This is how their journalists capture and communicate certain things and identifying it and turning it into a normal part of their shared vocabulary so that their devs, their journalists, their writers, even their business stakeholders could all understand, oh yeah, we're making a data pick to drop in there. It'll take about this amount of time. They'll need these supporting tools that gave them a bridge that they could coordinate around and actually make support tools that made something rich and compelling a lot easier for them to produce. They could standardize around it and support it. This is an example of Bravo TV, the reality TV station. Under the hood on the Bravo TV blog, they litter their posts with lots of little bits interstitially interspersed throughout their posts. Could be dramatic pull quotes from a fight on the real housewives of Hollywood. It could be tweets from someone on one of their shows that caused a buzz, things like that. Most of those things have embed codes that they could just drop in there, but that's horrible and no one likes embed codes and they're hellish and nightmarish. So there's actually a Drupal module, I think called Entity Token Embed or Token Entity Embed. It's those three words in some combination. I've got it in a later slide. But that's being used to just drop in little tokens using the WYSIWYG editor. When they click it, comes up and they can choose what of those different like seven things that they always want to embed and reuse throughout their posts are. They can choose one. If there's, it does a little AJAX-y thing in the pop-up window and says, oh, I want related posts, how many, or I want a tweet, here's the URL of the tweet or something like that, it puts a token in there. It's not even fancy from a WYSIWYG perspective. It doesn't give you a preview or anything like that, but it gives them exactly what they need and it means they're not dealing with piles of weird cruft every time they need to do that. And it means that they can selectively transform those things in different ways whenever they output to different types of sites, different types of themes, all kinds of destinations. This is the news site that I mentioned before that had the surprisingly rich content woven throughout their news stories. They're actually doing a lot of really cool and interesting things with this. Behind the scenes, they actually have an editor that stores pure structural markup. They've broken up all of their images and information about companies and personalities in the news and stuff like that into supporting Drupal assets. So they've got this rich asset library that leverages things like entities and fields and stuff like that in Drupal, but they use custom tags throughout all of the text to embed a reference to, say, Steve Jobs autobiography or a reference to the current stock price of this particular public company or an embedded version of this particular video clip from their TV show in the flow of the text. And behind the scenes, they're not even storing HTML. What they're actually storing is a custom, I think, 20-tag XML schema that they developed that is a literal XML expression of their native vocabulary for their content. I apologize, the lighting is such that the actual markup kind of vanishes and it just looks like a very oddly spaced version of me talking about myself, but I swear to you, there is actual markup there. But the idea is they have tags like pull quote, pull quote quote, pull quote attribution, pull quote title, goes way beyond just like the existing vocabulary that HTML provides. They've got things like I want an asset to go right here or I want an inline reference to a company to go here. And in their WYSIWYG editor, they've given editors just the buttons to enter in those native elements. The editor that they have isn't a list of HTML tags, it's the list of the things that they put into their stories, whether it's simple tags like the emphasis tag or complex ones like I would like a full media asset to go here, they just use those things and they're always using their own vocabulary. And then they can transform that on output into a bunch of different formats. They have third party partners that look at stripped down pure text feeds, they turn it into responsive HTML on the front end, they have apps that consume it and it's worked really, really well for them for a long time. It took a little getting used to for people who thought, oh, I'm doing HTML, but it really, really worked smoothly. And this theme of finding the native vocabulary of your content, what those nouns are that your authors are working with. That's a really, really important theme here and it's not always super obvious. It's not something that you can necessarily see just from looking at like the page and what pieces are there. I think one of the examples I've always loved was two of the clients that we worked with with NBCUniversal were Bravo Television and OxygenTV. They turned those two sites into a multi-site instance, into two instances of Drupal running on the same multi-site. They have the same code base, different themes, but like the same content types. They're both reality television networks. They're both owned by the same company. They have obviously different shows and different personalities and stuff like that. But man, on paper, that's just like, that's an easy win. Two channels, same stuff. But the interesting thing was under the surface they discovered that there were actually some very significant differences in how they thought about and communicated about their content. On Bravo, a lot of the points of engagement that he talked a lot about were seasons and competitions. And the structural elements of their content emphasized like the season of say top chef and what was going on over that arc. On Bravo TV, it was very personality driven where a particular person might appear on three or four shows and what someone arrives there for is I want to see so and so on all of the shows they're on this week. I love New York by Golly and I want to see everything she's been on. That didn't necessarily change their model from a Drupal standpoint, but it meant that they had to think about what native elements their editors and their media people were talking about and using commonly. And the design treatments had to take those kinds of things into account. That's the kind of subtle distinctions that I think about when I say the native vocabulary. The difference between a personality focus and say an event or a contest focus can be really meaningful when you start thinking about what affordances do we give the editors who are working with this stuff? What design treatments do we want to focus on so that we can really smooth the process of working with them? This is a little bit deeply nerdy, even nerdier than we've been so far. But there's a great book called Domain Driven Design. If anybody feels the need to wait into a code book, if you don't, I'll give you the short pitch, it emphasizes the idea of developing what it calls a ubiquitous language for an organization or even an individual product in which you figure out what the core element of the domain you're working in is. What are the important pieces of this business or the elements of this message that you're communicating out and getting developers, the business stakeholders, the designers who are figuring out how to present it and the content authors who are actually producing it on the same page using that shared vocabulary so that they're not just talking past each other with one person talking about, say, a module when they're thinking about a design component and the developer's saying, what, we've got a bunch of modules, why do you want to add a new one? We've had that happen a couple of times. Has anybody ever had the module confusion during a meeting with designers? Okay, thank you. At least a couple of hands. This makes a really big difference. That idea of building the shared vocabulary, that's something that can even endure beyond a given project or a site built out. And it allows all of those different roles to communicate meaningfully as content is developed, as new features are added, and in the case of something like the BBC Datapix project, when you start noticing new patterns emerging, it's not just a particular bunch of markup that keeps getting jammed in there, it's a new noun suddenly appearing in our vocabulary. We're using this new element in what we communicate and perhaps we can build on that. This is where I really go off the rails. One of the things that I think is really interesting is that in linguistics, a lot of the things that we start talking about, like how editors can interact with rich, arbitrarily structured content using these tools, they're also the common factors that distinguish human language from just animal noises. Like one of the qualities that makes human language distinct is duality. The idea that small individual pieces like phonemes and sounds that we use to construct words are actually distinct things in and of themselves, but we assemble them together into words and phrases and sentences in order to communicate complex ideas. Those little atomic pieces, you might call them say components, those get assembled into important parts of a whole. The other quality that makes human language unique is creativity, the idea that it's not just a set list of sounds that correspond to particular emotions or dangers or foods or something like that, that we can take those little components and we can assemble them new and interesting in novel ways. Like I could take photo galleries and maps and tweets and raw text and say progress indicators. If those are parts of my core vocabulary and let's say personalities, like a little bio and whatever goes along with that, if those are the core elements of the vocabulary that I have in my content, there's actually a lot of interesting things that I can assemble out of those in a fluid and creative fashion even if we never thought to make a special big template for that type of content that allows for creativity and reuse of the small elements. And the other one is things like, the other quality is patterning, the idea that those elements aren't just arbitrary, they get assembled according to certain rules, like say an article can't consist of just a pile of tweets, it has to have other things in it, validation rules, design systems that support and sort of undergird all of this stuff that's being done are an important part of it. I'll stop talking about linguistics now, I swear, that's all. But I find it really interesting and personally inspiring when we talk about content that has to be compelling and communicate interesting and valuable messages that a lot of the challenges that we start facing here and a lot of the solutions that we can find end up being very close to the problems of how linguistics and the basics of human communication work. It just makes me happy inside, this is the stuff that makes my day go around. So making it happen, we've done all the highfalutin stuff, we've got our big grand vision for what human communication and the body field all mean, but day to day, how does this actually become reality on a Drupal project or any web project really? A lot of the basic building blocks, the starting points of developing like the shared language and the shared vocabulary are already in use, things like style guides and component libraries in a lot of organizations are starting to serve that purpose already. I think it needs to go another step beyond that to include voices like the editorial team and how they write, not just how it's presented, but the idea of these kinds of component libraries is an already a very valuable sort of touch point for this kind of stuff. Has anybody seen patternlab.io? It's a very sort of opinionated tool for doing wire framing from like tiny little atomic components and building up to page modules and page types and specific pages, but the idea of using those sorts of reproducible atomic elements as parts of your design and assembling them in interesting and creative ways throughout the rest of the site is very similar to what we're talking about on a content level. A lot of the concepts and principles that are there in patternlab and the atomic design concept are really, really applicable to this. If anybody's messed around with a lot of client side hacking and react in the JavaScript world, it does very interesting things. It's built around the idea of you basically defining your own little DOM elements to go inside of an HTML page and using JavaScript components to define what gallery means and what it ought to do or what navigation is. In your markup, you enter the gallery tag or the navigation tag or the call to action tag and then you have a component that goes and handles that stuff. Like in the front end development world, the toolbox to actually build out interesting and worthwhile implementations of these core vocabularies that we're talking about, it's already there and it's pretty sweet. In terms of like Drupal build outs and the stuff that we can just click in and turn on already to make these things happen, a lot of really powerful tools we have are things like the node embed module, the token insert entity module. We saw that in the screenshot. It lets you drop tokens that represent other entities on the Drupal site just inside of the body field. There's also a module called entity embed that's being developed for Drupal 8 and has been back ported to Drupal 7 now that does a lot of really cool stuff. It comes from like the same team that did the media module but it's been expanded to include all different types of Drupal entities and the ability to say drop an entity into the body field and then choose what display mode you want it to be rendered in when it goes there. Cool stuff. If you've ever used WordPress short codes, that's actually really common in the WordPress world and it's another example of this kind of idea, shortening big chunks of boilerplate markup or weird embed codes and turning them into short little representative bracketed tokens that can be easily entered in. There's also a short codes module for Drupal that is roughly an equivalent API to the WordPress short codes module. That's one that I think the Bravo TV team used heavily on that project in order to get a lot of their different wacky embeds to work smoothly. It's not everything has to be XML, not everything has to be developing some sort of like custom schema like that news site as long as you start with that vocabulary and you're looking at these things as tools to make that vocabulary happen and put it in the hands of the editors easily. There's lots of different tools that can make it happen. I mentioned the embedding of nodes and entities inside of other things. Like just the concept that we have in the Drupal world of being able to create different view modes for a particular type of content and say, well, I've got teaser mode or full mode or promo mode that I want to have for these things. Those can be a part of this vocabulary too. The idea that certain kinds of content appear in different forms in different places and we can use those to establish consistency as we're embedding them across various places and putting them into different contexts and reusing them. And if you're just really crazy and you want to go all out, it's totally possible, especially in Drupal 8 with CK Editor built into Core to roll your own using custom editor plugins, designing your own tags with HTML5 and using Drupal's output filtering system to transform them into whatever final markup your design requires as long as people have entered in the actual meaningful semantic underlying content. This is actually a real CK Editor plugin that lets people enter in crazy mathematical stuff. I don't understand it, but it's got lots of Greek in it so it looks impressive. So how are we gonna tie this up? That shared vocabulary is really the core building block of a lot of this. The technical solutions have actually been with us for decades, like the XML community, they solved this stuff like back when we were trying to figure out how we could actually keep people from pasting XSS into everything. They figured out interesting ways to treat these problems. On the upside, they still have to hire Java developers whenever they want to sort a list of posts. So the sort of entities and fields and templates model that we have, it is super powerful, but if we start combining these things and treating them both as tools that allow us to bring this core vocabulary for our content to fruition and put it in the hands of the editors, it's really, really, really cool. It's very powerful. So we've got those three problems, the narrative text, the islands of structure that occur inside of it, placement that actually matters and can't be ignored. And that's really the crux of this particular problem that we've got. The four steps to solve it are defining the language of the content, that shared vocabulary that we can use across developers, designers, content editors, and even business stakeholders. We can use fields, entities, Drupal content types, and custom markup when it's called for to capture that content language. And when we store content and manage it and give people tools, we use that vocabulary, not just buttons that mirror the vocabulary of HTML and the browser. And then we transform it for output into whatever form we need. It's cool stuff. And when it's actually done, when we actually are doing this stuff, there's five core payoffs that consistently end up coming to fruition here. More creative freedom. Because once the tools are in place, that sort of creative expressive aspect of being able to combine these elements in new and different ways becomes a lot easier. So editorial freedom, the, ah, but I just wanna put stuff in places. I don't have to worry about all the, getting new templates designed and stuff like that. That becomes a lot easier to achieve. It actually becomes easier to transform and repurpose content because instead of big wads of HTML that just had to get pasted in to make the deadline, we've actually got these meaningful bits that are easy to detect parts and transform into other forms. The editing experience is a lot easier to streamline because the stuff that we're talking about putting into the body field is actually really easy to write editing plugins to support. There's less one-off development because as the editors have more creative freedom with the tools that they've got, custom development is much less necessary to come in and handle edge cases for a particular kind of article. The $250,000 like moonshot big media article isn't as necessary if the reproducible tools are there. And also that ubiquitous language that shared vocabulary is all about improving communication between different groups and different teams that are very often siloed on our project and anything on our projects and anything that we can do to get those people talking to each other and collaborating with each other and sharing knowledge and coming up with solutions without spending their time, just arguing in a boardroom about whether the slider should be bigger or not, I think is a big win. So if you're looking for more interesting books and you don't mind diving into some nerdiness that domain-driven design is a good one for people from a programming background, there's also a great book called Designing News that's a couple of dozen case studies of how different news and publishing organizations have tackled the design challenges of publishing things at scale and on digital. And then there's a book by Abby Covert called How to Make Sense of Any Mess. It's a great sort of guided tour of the core tools of information architecture and decomposing weird thorny problems like this. When it comes time to actually like negotiate that shared language with a roomful of people who are used to speaking their own language, her book has a lot of great tools to make that happen. And if you're interested, I'm gonna be posting the slides and there's a whole mess of different articles and links and websites that have more explorations of this kind of stuff. I think we do actually have, in a shocking turn of events for my presentations, a couple of minutes for questions. I know this is unprecedented, but thank you. Hello. Okay, thank you. So I'd like to invite you for a Dita talk. Yes, for those who don't know it, Dita is the Darwin Information Typing Architecture and they basically cured cancer a decade ago and no one noticed. So because I'm here actually in LA, I'm staying with one of the members of the Oasis Dita Committee that's working on lightweight Dita. And they're looking for ways to do kind of a markdown HTML5 kind of way of doing Dita. It's really, really interesting and right. That sounds like a fascinating conversation. We, I would love to do that with you. Definitely. Okay, but I'll, and anybody else who's interested to join. Does this actually work? Okay, get really close. I kind of have a feeling I know how you'll answer this, but how do you get the content editors on board with this kind of new way of entering content if we've trained them on WYSIWYG and like tips. Well, we still use WYSIWYG editors. Right, but like there's tokens and stuff in there. It doesn't show them the picture necessarily that they want to drop in there. Well, I, If we've spent a lot of time doing that. It didn't actually appear in any of these screenshots. So the question for anybody who didn't hear it was, how do you get editors on board with like tokens going into the body field instead of actually a picture? With a number of our clients, we actually have written the CK Editor plugin that actually turns that into an image or even a placeholder in the editor. So that's totally a possibility. It's just in the example that we had, the editing team was already used to a WordPress site in which they inserted short codes. So they were actually perfectly comfortable with that. But that is one of the advantages of using this approach that it's very easy to layer a like editorial view of these things on top of it. The client I was, I think we were talking about their first iteration actually just showed the YouTube logo or the Vimeo logo instead of the actual video because it let them turn it around in an afternoon. But then in future iterations, they made the like the in editor preview richer. But it was remarkably straightforward. When you're talking about outputting this stuff in say an API type format, how do you recommend rendering the stuff in the middle? Do you recommend outputting it as HTML along with everything else or as a separate field? It generally depends on who's gonna be consuming it and how. I know a couple of our clients who've actually just kept XML style tags in there and in their documentation they say, when you get our content, there are these four tags that will represent placeholders for media attachments that you will get in other parts of the API payload and stuff like that. I've also seen situations where it just gets stripped off and treated as just attached data and they consider that an acceptable loss for certain formats but not on their website. It depends like to some extent, the ability to decide how you're going to do that in different contexts is what you get out of this approach. Right, thank you. So I'm buying what you're selling as far as the. Just got a trench coat that I open up and there's a bunch of XML. So the. Like hey, you need some markup. With as far as the tokens and when you're rendering content for that piece of atomic content. But what about if you're also, you wanna build experiences elsewhere so you don't wanna just display the gallery one on this article but maybe gallery one is used on 50 articles throughout the site. And if you're giving up that entity reference potentially. That's an excellent question. So this is a subtle distinction. Like what if I'm writing an article and I want the droopily like entity reference meaningful connection between this article and that gallery. I wanna be able to like write a views query that pulls that up. But I wanna be able to position it meaningfully. That's actually something that on the Bravo site was done in technically when you're inserting those references on the Bravo site, you're not just inserting arbitrary references to other entities. You add those to an entity reference field and the whizzy wig editor actually lets you pick from the things that you've associated with it. In that context, your node sort of becomes like the giant crate that all of the stuff for this particular piece of content needs and the body field has just what's necessary to assemble the stuff in that crate. It doesn't necessarily have to bear the entire weight of all of the relational stuff. I got a couple of questions. I'm assuming this works for TinyMCE as well, right? Yeah, well actually one of our clients who was working on Drupal 7, they did need to do this in MC. I don't like the TinyMCE like API as much but yeah, the basic capabilities are definitely there. How do you deal with like developer, not developers, but designers that wanna go in and manually edit that HTML? Do you take away the ability to swap out from the whizzy wig view? Well, if what you're actually inserting isn't HTML, but a meaningful tag that says the gallery goes here and the HTML for that gallery as an example actually lives in a different templated section, some of that is sort of overcome. You don't run into quite as much of the, by golly, no, I just wanna switch to the HTML and look, if I could just put a style attribute on this span, then I could solve everything. You know, I mean, if what you've got is experienced HTML designers who just need to dump stuff in a body field because that's how you're deploying fully formed HTML, to some extent, you know, it's, the purpose of this is to reduce the need for that as much as possible. Some people like going out at old school. So you kind of time down to the buttons then, pretty much? Yes, to some extent. And do a good selling job. You do, and oftentimes, if it's actually a front-end designer who's doing that kind of stuff, yeah, you know, they may be the person who's editing the templates anyways, you know, when stuff actually gets piped out. But what we've often found is that editors who are tasked with that kind of stuff are actually pretty darn happy to relinquish manual tweaking of the code as long as they can accomplish what they need to accomplish in their jobs. And that's where, like, bringing them into the conversations so that it's not just handing off a bunch of buttons to them and saying, knock yourselves out is a really important part of it. Okay, last question. Thanks, thanks so much for this, Jeff. It's really great. It's like you're inside my head. Um, I can, we've had a good deal of success confronting these issues with something like paragraphs or inline identity form or some variation on that theme. And it seems to me like it sort of comes down to an interface decision, whether to have them doing it in the WYSIWYG or doing it that way. And I wondered if you might be able to speak a little bit more about what problems that you encountered trying to confront it with something like paragraphs. The biggest challenge with something like paragraphs, for people who haven't used the module, it basically turns like the node editing form into like a stack of elements that you can add. It's like a multi-field form where you say, I want a bunch of text. You can enter text. I would like a view underneath that. I would like an image next to a call to action block. You can assemble really interesting and rich stuff very, very quickly using it. The downside, at least in my experience, comes when you've got something like, say, a 9,000-word essay. And it needs bits that live at special places in the middle. Theoretically, you could chop that at the places where those media elements live, turn each one of those into a different field full of HTML, but that almost always ends up turning it into like a final stage. You're almost like, it's like in the old days when we would hand cut JPEGs to get them ready for the design. It's sort of like that process, but with our text. If that's an acceptable process, then there's nothing to prevent you from doing that. But it also means that if you say we're to want to output a feed of just the text or change where certain things are presented, now you're gonna be going and parsing through basically a Drupal object model and trying to reassemble it differently. It's specifically that flowing narrative text that has the elements inside of it. We actually have seen the paragraph style approach be really effective with like, say, marketing pages for a product where what you're assembling is a number of distinct statements that might build on each other and have supporting images or whatever, but they aren't like that flowing text narrative. Does that make sense? It makes a lot of sense, thanks. Okay, well thank you, I will stop talking now.