 And I hope you enjoyed that useful interlude to get you into the movie with this presentation, or at least potentially make you up if you haven't added up probably this morning. This is Why Can't We Be Friends? Making Drupal Play Nice with Content Authors. My name's Danielle Lorette and I'm your friendly neighborhood content strategist. Is anybody else here in a heavily content related role? Okay, a couple people, excellent. I mean, technically that's everybody as we saw with Todd's talk, but I'm often a long content strategist at these points. So I always kind of like to see if there's any of my people, but I do really want to convince everybody that we need to take the content first approach. Go. Hi, I'm David Castellari. I'm the CEO of Cold Front Labs. And- I wrote you into doing this. You wrote me into doing this? Yeah. Yes. No, so we wanted to take a look at, well, I guess we'll get into that. Yeah, so let me handle the technical aspect. Thanks. Do you want to do the next couple slides too? The next couple slides. Oh, all right. Yeah, I guess about Cold Front Labs. So we build a Drupal applications for a whole variety of clients from a lot in the public sector, and but really for any kind of businesses and sectors across North America. But, all right, do you want me to do this one? Doesn't matter. All right. So we'll get into actually the meat of our talk. So first, we're going to clarify what this talk isn't going to be about, which is what traditionally sort of content author and talks have been about regarding Drupal. And it's not going to be about configuring the WYSIWYG editors. Which Suzanne from Wellingwood has an amazing talk about. So if that's what you came here looking for, I highly recommend her talk. It's on YouTube. But that's not what we're going to talk about today. And if you want to see some really, really weird things happen with WYSIWYG editors, come to my other talk about building impossible applications with Drupal and DJS, where we build probably the strangest WYSIWYG editor that you'll ever see. So here's what we are going to talk about today. So first I'm just going to give you a content strategy 101. What is it and why does it matter? Is the varying levels of understanding the content strategy in this room, I just want to clarify. And also content strategy is a little confused about what it is right now. I don't know if anybody went to or followed Convab, it just happened in Minneapolis, it's like the big content strategy conference. And there's even conflicting definitions of it within that conference. So I just wanted to let you know my working definition and why I think it's since it matters to all web projects. And then we're talking to some people that are extremely about content style guides. Most of you are familiar with design style guides, but I want to sort of drive from a point about content style guides. And indeed it's going to help us talk about. So I'm going to talk about how do we implement that in Drupal and how do we do that in the most straightforward and easiest way possible. So how can we get up and running with these topics or bring these topics to your content authors without needing any other major requirements? All right, so content strategy 101. The definition that I like to work with as content strategy is guiding the creation, delivery and governance of useful and usable content. And I do want to distinguish this from content and marketing. Content marketing often sort of functions as content for the sake of content. You're trying to drive users in with your content. I like to think of content strategy and it's the truest incarnation to be very user-focused. So you really have to know and use your stories inside and out of what your users want and deliver it to them first and foremost before your marketing sizzle, if you will. So content strategy, it's not content marketing and it's not design incarnation that we know it but it's really interested in what kind of content, why it's there, how it's going to be developed, when is it going to be published, whom is it going to be written for, what resources and workflows are we going to use, how often will we publish and then looking at that content life cycle and operations in your organization. So I've drawn some of you here today with the promise of Scott Hunt Requences. I think I show up hands for those of you who like that was like a huge deciding factor. God, God's my man, I've got one more, excellent. So I'm just like Scott Punk Band. We took really nerdy skills from high school and figured out how to apply them in another context. For Scott musicians, this was, you know, they were assigned a trombone or a saxophone in Grey Night Music class but they wanted to rock but they knew how to play the trombone and they're like, I can make this work, right? Launching strategists and organizational nerds and we figured out a way to apply this in a way that was unconventional. So I feel very akin to Scott bands but I also listen to a lot of them in high school so this is just really fun for me. And they'll be throughout dinner, a little demo, we'll have a little Scott feel for those who are here for that reason. So I want to talk about the elephant in the room and the elephant in the room is not Scott. The elephant in the room is content and I really appreciated Todd's keynote this morning because it was just like this perfect precursor to a lot of things that me and Dave want to hit home with and I think there's a lot of changes happening but if you look back to Christina Halverson who's kind of like the content person, she wrote content strategy for the web, she wrote a list of her article in 2008. Just basically talking about, there's this giant elephant in the room called content that no one is talking about. We're talking about design, we're talking about code, we're talking about functionality and we're saying the client can handle content, right? And you end up having them drowning in this massive thing in that very little direction. I don't want you to read this entire thing, I know I'm breaking the carbon rule of PowerPoint slides but this is from her article and I just like the blue parts where we think we the people who make websites we're rather quiet on the matter of content, the client can do it. But you think it's a coincidence then that web content is for the most part, pardon me, crap. Content is the web, it deserves our time and attention and we have to stop thinking that the client will just do it by themselves, they can't wrangle this elephant all alone, it's just too big. There's been a lot of advancement, Drupal Conte Seattle had a content trap this time, it was awesome, there was an amazing keynote this morning with the focus and content strategy is starting to be integrated into web development projects at the beginning as opposed to at the end as sort of a saving grace. So I think we've made a lot. Has anyone seen this graphic before? Or a variation of it? Hey, you're all content quadrogens, this is the content strategy quad, this is a graphic representation of the work that I do every day and these are the four places that I focus my attention and my advice to clients. So these four sectors are essentially editorial experience, structure and process and they all have different characteristics but they all work together and you'll notice that structure and process are on the bottom because they are the foundation of content but here's the tricky thing, structure and process often have to do with corporate culture, people and workflows and editorial and experience rise above that and that's where we often try to change things like we'll come up with a content style guide or we'll think about a new content type but we have to really understand that if we're going to create change in the upper part of the quadrant we really have to analyze and look at what needs to change in the bottom part of the quadrant. So editorial is really focused on how do we know that this is the right content and right in a lot of different things? Experience is what do our users need? What are they looking for? What is the experience they're driving towards? Structure is how are we doing to organize and engineer the content and make it right for our users? That's sort of that content design or content engineering aspect and then process is how will this be created and maintained from the content operations to work for the perspective within the organization. And like I said, we often get a really obsessed with the blue section at the top but if there's problems in the bottom foundation change will really happen. Design is not a cool design. I think everyone in the room here today knows that but so often I will walk into meetings with clients and people want to talk about the color of the font or the type, the style of the font or the images that are in the background. Content strategy, we have to play really nice with web designers and then you have experts but that's not really what we do. We're very consumed with the content assets which is the core writing and images that are a part of the asset. And as I said, we tend to get really wrapped up in the functionality and web development aspect of developing a site but this is my one off-brand meme but everything the light touches is content. It kind of, not that it doesn't matter how good your site is but you can develop and code and design the most robust CMS ever. But if your client isn't guided into putting appropriate content in it your functionality is not going to shine. So from a developer perspective it doesn't matter how awesome your code is. If the content you put into it is broken, inconsistent and haphazard the site can be viewed as such and this also ties into the concept of the rest of our goodwill. Anyone heard this term before? Okay, more hands, I love it, thanks David. So this is a concept from Don't Make Me Think which is a really great UX book by Steve Krug and he talks about how as we enter a website we start with a reservoir of goodwill. We're excited to get the information that we're going in to get and we believe that we can achieve it. And as we go through the website that makes that process difficult, go ahead. Brings down the reservoir of goodwill and makes this cranky, which makes this cranky towards your organization in part. And this isn't all content but for a lot of it content that's out of date inconsistent right out of one page it has a really different tone than another page. I'm going to be hiding the information of the user once behind some marketing sizzle or a million pop-ups about I want your email address and by the way we use cookies and here's the 800 things I'm going to show you before I get to where you want to go. This really drains our reservoir of goodwill but we can keep it full by making sure that our content is up to date and that we're making sure that we have a content operations model that allows us to make sure everything is up to date and that it answers user needs. Again, not content for the sake of content that it actually focuses on the main stories of what brings people to your website. We also want to ensure this dial-in tone are appropriate and consistent. Appropriate means knowing our audience inside and out and speaking to them in a language, vernacular and style that is acceptable for the web and also individualized them in some way. And we also want to make sure that that structure is intuitive and consistent because if it looks one way on one page and one on another, I'm going to confuse a user by looking at the same type of content. What we can do to moderate this is to make a content style guide. So a content style guide is an organized set of rules for writing for your organization. These rules uphold your organization's voice, style, and message. I want to say a content style guide is not going to fix everything. It does sit in that big portion of the quad. It is an editorial thing, but if you've got no content strategy at all and you're in a position where you're not likely to upheave the entire organizational workflow, it's something you can do tangibly as an individual and anybody can do this as long as you've been through high school completion. So it's just sort of like one thing to start with and to run through a consistency through your site. So, but here's the thing. Sexy, right? You get to look at colors and fonts and everybody wants to be in the meeting where you decide on the website's design. Content style guides are kind of like homework. I'm not going to lie to you, okay? We're looking at consistency in writing style. We get to talk about things like punctuation, talk about things like formatting, title case versus sentence case. Sentence case, it's not sexy. I'm not going to lie to you, but it's going to make that reservoir of goodwill stay full or longer just on a subconscious level. So you're thinking, okay, you've sold me a little bit. Maybe I'll put together a content style guide. Here's the secret. You don't even necessarily have to. There's a lot of great public-facing content style guides. You can kind of beg for your own steel crown. So the big one that most people know is Canada LCA. Their style guide is completely public-facing. It's very robust. So it might be a little bit too much for your organization, but if you are an organization that asks for 70 large amounts of information, somebody else has figured this out for you. And I know it's not perfect, right? But it's there as a resource too. I'll explain later. Okay. It's not perfect, but it is a starting point, and it has a lot of great examples of just ways that you can stand guides or content. So this is a lot though. So what I recommend is if you are going to jump into this and making a content style guide, there's a great one from the University of Dundee. There is this like wave of content strategy going through the UK right now that I'm so envious of. Content strategists have like taken hold of the web in Britain, and it's awesome. And things are getting to be really clear and concise. And what I love about the University of Dundee's style guide is that it's super short, it's effective, and it broke it down into four areas that you can sort of replicate really easily. So we'll go to the next slide. These are their four areas, and I really like them. So you have your content principles, which is sort of an overview of how your organization writes. This is, I don't want to call it a mission statement because mission statements are fluffy. They're if you had to like, after you're done writing the entire style guide, you come back and say, I had to have 773 short sentences. What would they be? I'll go through some examples afterwards. Voice and tone, I'll distinguish what those are because I know we don't all remember great time English class but they have a different. The writing guidelines are the best practices we use when we're creating copy. And then a reference guide, which basically becomes a sort of mini encyclopedia of formatting. So first are content principles. Content principles, that's okay. We define our audience. Who are we speaking to specifically? So for example, right now we're working on a project in higher education, and we've segmented out the site in a user-focused way. So the style guide for the way we write to prospective students who are coming out of high school versus the way that we're gonna speak to clients who are coming in from professional development services that it's going to be very, very different. So we define that audience first in content principles. From there, we sort of have those three short statements that talk about, that's okay. The three overarching content statements that sort of lead us. So if your content authors aren't gonna go into your style guide, they can just have these sort of three mantras, if you will, about how to write content. So it may be things that keep it simple, but don't patronize. Show as well as tell. They're really high level, and this is short, okay? I'm actually petitioning you for like a four page content style guide. That's it, it shouldn't be tiny. So voice and tone, this one gets confusing for people. Voice is your fixed personality as an organization, and the tone is how it changes depending on the specific interaction or situation, and it's rooted in your voice, but it adapts. The same way each of us do, our voice is our personality, you are who you are. But the tone you take when you're speaking to your grandmother versus when you're presenting a conference, you're gonna be very, very different. So to establish your voice, a really simple and easy trick of your organization doesn't already sort of have this in their marketing objectives is to make blank but not blank statements, okay? So you might say that we're resourceful, but not boring. We're playful, but not immature, and that'll sort of help people qualify the voice that they should be using as their writing. So once you establish voice, you can jump into tone. And this is actually sort of a five point scale that if you don't even wanna think through other adjectives, if you pick one of two in all of these, you can establish your tone for any given specific piece of content. So you might look at a Facebook post for your organization and say, this is probably personal as opposed to professional. It should probably be accessible as opposed to exclusive. This is probably enthusiastic as you're probably trying to work people in, maybe a little bit funny for this one, and then conversational. Whereas if your organization is writing the actual document on the site that's answering the user need, perhaps it has a more professional, accessible matter of fact. Serious, formal tone, if you will. And when you build out your style line, you really wanna look at all the different content tapes that you have and attribute an intended readership for all of them, the tone that you are expecting, and then a small example of a copy, a couple little sentences to help you out. The next section is the writing guidelines, and I swear I'm gonna get back to Drupal very shortly. Is to sort of create guidelines about all of those things that we're not sure about when we start writing. So something as simple as active and passive voice. Generally we write in the active tense and that's gonna make it more actionable, but should we be writing in the second, third, or first person? Is this an I situation? A you situation that I'm engaging in bringing you in, or a third person or move situation so that it's quite formal? We'll also talk about header guidelines or what sort of capitalization we're gonna use, your paragraph and guidelines, and examples of well-written copy of each. And the last one is sort of formatting expectations. This is the really dry part, I'm not gonna lie, but it's literally like we want dates in this format. Is it gonna be like Monday, comma, September 14th, comma, 2019? Or is it gonna be 09, 15, 2019? Things like that would be in this section. You took a couple days, you made this beautiful four page document or site, whatever it is, site would be better, it's public facing, and you have it in your section. High school English teacher's proud. Your high school English teacher's proud, can't even see a high school English teacher, no, it's not. But they do my style guide, things are still a mess, I don't know what's going on, you're just great document and nobody cares. But the answer, my friends, is that you have to put it into this, you know. The content style guide has a document for itself, it doesn't need to exist. Realistically, if the content authors are going to draw from it, as a resource to standardize and make consistent their content, it needs to be right there in line when they're editing that note, okay? Only the keeners like me are gonna load your four page document and look at it, and I'm a rare breed, okay? So you really need it right there. No doubt. No doubt. No doubt. Well done, Dave. So I'm gonna confess that this presentation was born. I was at the office one morning and I'm at my desk and we were gathering content, which Todd actually brought up for us, and there's a really great presentation tomorrow that's also gonna talk about gathered content that I'm excited to see. And with your gathered content, and I'm like, yo, Dave, have you seen this awesome tool? And it's this content operations hub, and it just has all this neat functionality that really gets you thinking of content first, and you're like, ah, I wish we could use this more. And I was going through, the things that do really well is collaborative authoring, maintaining consistent content, and custom creation and publication workflows. And I think a lot of this can be done in different ways, but the maintaining consistent content is really achieving gather content by having these templates with text right below the field that outlines the X-ray expectations, the content style guide, if you will. So this one, for example, is a headline, and I blew it up in blue font for you at the bottom, in case you can't read those, scribbly black, but it says, make this an H1, capitalize initials, and it gives an example, keep it short and sweet, and use adjectives to look excited. Your high school English teacher was screaming in her ear, that's crazy, that's fantastic. Okay, there's another example in the next one, but we can sort of power through that. The secret sauce is help text. Drill, how to help text. Which is what Dave turned to me, he's like Danielle, we can do this, nobody does. I think she was a little disappointed that I wasn't as impressed with gathered content as she was. Dave was like, I can make most of this in Drupal. No, we're not talking gathered content that has other use cases, but if you're in a position where your organization has an existing CMS, things aren't changing, you're not doing your redevelopment, or you're gonna decouple, if you're already here, okay, you can just fix your help text and integrate your content style guide. The power struggle here is that most of the content authors or the communications individuals who care about these kind of things might not necessarily have the admin rights to go in and change that help text. So we wanna think about empowering them to do that, or prompting them to do that while we're in the development process or working with them. So really, I know it seems simple, but I'm here, me and Dave are here today to talk about help text. As a simple way to support content authors and create a better user experience. So I'm gonna ask Dave to pick it up, pick it up from here, and he's gonna take over from an implementation side. All right. So we'll talk about how this kind of taking these sort of principles and bringing them to Drupal and how that works. And we sort of started, we built an example Drupal site out of this. And we wanted to keep things, or at least I wanted to keep things, is bare minimum is possible so that we could, so it could really show that you can do that with really almost just Drupal core. So the theme is barkdick. So, because if you can do it in barkdick, you can do it anywhere else. It's just barkdick with a little bit of styles. So like we said, like one thing I observed is that Drupal already has almost everything we needed to make a really, a much better sort of content authoring experience and really bringing the content style guide into the content editing. But that's generally not how we configure it. And I can prove that probably you'd have never configured this with a bit of a quiz. Can you put help text on Node Titles? Has anyone put help text on Node Titles? See one hand. You have? I think it was an add on what they said. That's right, because Drupal core does not let you put help text on Node Titles, which was shocked, which shocked me. I looked around for help text build for it. And then finally I Googled it and the module Node Title help text came up. So our first step in bringing the content style guide into Drupal is to start at the data model. And this really goes back into our keynote. We're taught talked about this, but we can bring the content style guide into the actual data model for the Node Types and create fields and content types that reflect the way that we want the content to be written and you sort of guide your views into writing good content. And this means avoiding the generic fields that offer little or no guidance to users. So here's sort of an example of a bad node type that we've all created and used very heavily in Drupal versus a better one that actually helps you or helps the person writing a large article write the article. So this is essentially a basic node. You have a title and then a box called body and everything goes in body and it's great. You have a busy week editor. There's nothing technically stopping you from writing articles this way. But when you sit down to write an article this way, you're really, you're on your own. There's lots and lots of great resources to how to write an article out there, but they are not present. If we just sort of modify the data model for this kind of article, so our content type here is called narrative. We have another content type called good narrative and it's going to just a body field. We have multiple long text fields that explain what we expect the author to write in them. It becomes a lot easier to write article content. And this is a very truly change that Drupal usually does. Once we do this, we can create help texts that's actually helpful. Most of the time we don't fill out the help texts and descriptions in Drupal. I know on a lot of sites that I see that other people have written, on a lot of sites that aren't written, there's a severe lack of help text. And we just sort of, well, the client asked for this content type with these sort of fields on it, so obviously they know what should go there. But if we organize things to line up with the content style guide, we can actually change help text to make it helpful and guide users through the authoring process to make it less like opening word and sitting down and having to write and get a writer block and make it more like filling in a form to let you more quickly write much better content that's in line with the kind of content that the site's expecting that you write and publish. Yeah, so I have an example on the page instead of the body, this is what appears on the page. You could have this sort of inciting incident and this is the moment where something goes wrong in the story. The tagness of the story goes on a type of journey to write that wrong. That second one bit of help text really gives you a lot more context to what should go in that box in the first one. The next thing that really helps you leverage your content style guide is paragraphs. The concept of what paragraphs are has been around in Drupal for a while. We've had field collections which essentially do something very similar in inline entity form for doing that with entities but all these things sort of let us wrap fields together to make sort of sub pieces of content or content blocks from the story. But what we can do with paragraph paragraphs is we can actually leverage this to make them sort of wizards for filling in specific types of things that need to get added onto the site. So we can create smaller structures that get embedded into larger pieces of content. So as an example, we can have, we can ask, we have a certain article type where users can fill out facts about what the subject of the article is but that could either just be a text box or we could make them do it in the body field or we could use a paragraph called fact and we could have every fact not only has to have the fact but it also has to have a reference and require a URL with it. So we can package it together to so that it may say in our content style that its facts need to be referenced but now we can force it by creating this structure as a paragraph. So we implemented a bit of a SCA site and I guess you wanna show them around? Oh, sure. So I think the whole subject of this presentation was to get me to implement the site that I think teenage Danielle always wanted. Yeah, it existed. But yeah, so this is our Google website called Why Can't We Be Friends. It's a very small SCA repository right now having to deal with some of my favorite bands from high school that would sort of give you a really quick overview, yeah, for sure. Here we are. That'll work. Let's go with the Aquabats for Todd because I know he was excited about them. Thank you. You're welcome. We have this really sort of quick, this is a need to be Wikipedia, Wikipedia exists. So we have a quick photo, a link to Wikipedia in case you're really into Aquabats and you wanna know their entire life history but otherwise I'm just trying to get you on board with my musical excitement. Here's three quick facts about them and then we just link to the YouTube videos but we're making sure and Dave's gonna sort of demo it later that the writing expectations for these bullet points are right there as the author is editing and this goes from everything into the capitalization expectations and the way that we're referencing sources, right? Additionally, what was really interesting for me is I did write one article for the site Why Can't We Be Friends in Defenses Scot because I know everyone likes to make fun of Scots, it's a little bit weird but I initially wrote, at one point we had a content model that was just like an exposition, conflict, resolution, right? So I wrote the first article with that sort of model and then Dave changed the content type of it and I was like, I'll go move things around and the article got so much better it became so much more robust and I'm like, I'm actually weirdly proud of this piece of writing because that content model really helped me develop it in a way that made it clear about every single thing that is necessary to make a good narrative and while I'm writing it I also know that if I'm gonna use a song title I have to be using quotation marks. If I'm gonna mention an album title it should be italicized and it creates this nice standardization that's gonna keep the reservoir of goodwill high and make you seem like a credible source. Yeah, all right. So let's take a look at the, this is the end result of things. So it sort of looks a little funny because that's just, we're using Bartik. There's Bartik plus maybe 50 lines of CSS to do all this. So we just have standard node edit and then we've sort of themed this page to really, really bring out the help text and my joke is that I called this Bartik content. Or did I call it? They go like gather Bartik. There we go. There we go. So really all we do, this is just some CSS that grabs the help text and floats it left on us. So that as we write it here we have introduction and it tells us what is expected in the introduction so we can add different paragraphs to write it, the incident, crisis, climax, and then the resolution. And all these things are important in building the narratives on our articles. And sure we could do all this with just a body field and it would be the editor. But now we have a guide built into the editing interface to walk people through creating the content. And it's really not, wasn't difficult to implement it. All we just had to implement it. And one of the things I often hear from clients is that they're really scared to disseminate content creation across the organization, right? There becomes this fear of like not everybody's gonna write the same way. And that's true. It is a hurdle that needs to be considered. But if you can create these sort of user roles where you have this user role that this is kind of all that they're getting and they can't even necessarily publish it. They can just draft it at this level of thing and they have the content style guide right there that dissemination of content is gonna be a lot cleaner and potentially meet the content style guide if it's right there for everyone. As opposed to there being two people in the comms department who are allowed to write anything because they're the only ones who know the content style guide because it's in this two page PDF that nobody looks at except for these two people who are grammar nerds, right? It makes that dissemination of content creation a little more feasible and a lot less scary. The really funny thing about this is on the bus today Matt handed Danielle His other boss, yeah. His laptop to write a quick article post for the Drupal Camp Ottawa site. October 25th, 2019 in Ottawa. Which was of course just the title and the body. And I was like, that's awful. How are you supposed to write an article in that? And it's sort of that moment where likely I will probably be the only one publishing the Drupal Camp Ottawa site October 25th, 2019. But if I were to share that responsibility with someone because we do have a committee, right? And we wanted somebody else to write announcements. We could create a better content type so that when I make an announcement or Dave makes an announcement or Katherine makes an announcement that we're all doing it the same style and tone. And it feels like the organization as opposed to somebody wrote that one and somebody wrote that one and you guys seem to be some little organization who don't have their stuff together, right? It creates that reservoir of goodwill on a subquantus level for our users. You think that's going to demo? No, I mean, I can show you more things about Scob. I've less drawn that than I thought I would. Sure. All right, yeah. And so I wanted to, I kept a slide while we were writing the slides to keep a list of the contrib modules that I used to make the demo site. It didn't get as long as I thought it would because you really, Drupal comes with everything you need. It's all about just rethinking the content authoring experience and breaking that down into the types of content. And even while putting this together, I sort of, I have other things in, I think I've been thinking about other things for other sites that sort of specific types of writing. There if you're writing something very targeted, break it down and break the components down into smaller sort of structured paragraph components and just sort of how easy that would be to sort of write something really complex with that. And I think there's just often a disconnect between the developers or the site builders who are making the site and the comms people in the organization. We don't get them in a room often enough. And all of these things probably exist. We just have to put them together and empower content authors. And I like, it's almost stupidly simple. That's it. Thank you very much. I now work in a comms department kind of an older website. And one thing I've always found useful when I'm making websites for the end users is instead of just putting in an image field or a paragraph type, I would put in some kind of health test text. So for image fields, I always put the size as they know it that is preferred for that field. And it takes like minutes to figure out, okay, the optimum image in that space is 1280 by 420. So just put that in the image upload field as health test. And then you never have to answer that question again. And I think image is one that does, I think image does actually happen a lot. I think people do write image health text. I'm challenging you to write body health text, right? And it'll just shift things. And that's for our new site, actually we've got a lot of paragraphs and we put that in like, how do you use each paragraph type? And that's helped a lot in letting people create their own stuff. Jason? Yeah. That was good. I was wondering if you could give one minute to show us what the paragraph button and fact button looks like when you have to use it. Yeah, yeah, yeah. Sure, totally. We want to make sure to get time to questions just to skip through. So, this is my preferred, paragraphs is like all kinds of interfaces for how to use it. I like the buttons, but you can use another one. So if we want to add a focus quote, it'll just bring in sort of this, all the fields for this. But I don't know why it's rendering so tiny, probably because my theming is bad. There we are, this one would look better. So, a more interesting use of paragraphs is actually on the bands, on this site, the band profiles. So, if we go in here for fun facts, so we require one fun fact, so we have a fact and the reference for it and we can add facts. And then we have songs, where are the links for the songs? Tentenberg. Tentenberg, all right, that's fine. So, yeah, here we go, we can add another fact. And there we are. So you can add many and you can reorder them, but at least you're getting this structure each time. Yeah, and the thing too is, I've kind of mangled barked it for this theme to bring out the help text. So, the rendering is a little bit off, but I mean, it's more I just wanted to show that if we could do this like in barked it without touching anything, then you can definitely do it in your things. I'll let you pick a day. Thank you. So, I'm on the developer side of my genre of do-it-yourself text. Oh, that's cool. And it annoys me when people don't. Yeah. The biggest issue I've encountered is that people creating the content don't read it. Yeah, so that's the one thing that, that's the thing that, like the thing that gathered content really, or looking at gathered content in their content interface, that really was like, oh, like, Dupal doesn't do that. Is that gathered content in your writing content makes the help text like the thing you see first. You don't get a box to type in. Like, that's not the focus of what you see. The box to type in is there, but it is, it is, gives you the instructions and then the box. And so that's a serve of what I tried to reproduce. And I think like that is really sort of a helpful thing. And I never really thought to theme it that way, even though it's like kind of children. I mean, I literally didn't think about any of that, but we did it for a while in that section, it was small. Yeah, yeah, I didn't even come up with that idea. It's sort of, it's sort of how, like really, really like funny how easy this was to implement and like how much easier the sort of site gets to write content for it. And when you're logging as an admin user, you do have that adbd help text that people are probably gonna ignore. I'm not gonna lie, right? So you do have to spend a little bit of time doing what Dave did here to put it in people's faces. And it especially becomes important in that content dissemination model, where you have lots of people writing different content. If it's just like, you know, free people in the comms team, they might actually pay attention to help text in the admin login. But by themeing it out the way that Dave did, which he said was couple of lines of CSS code, or like. Yeah, no, it's really like, well, I mean, I wouldn't advise using barkdick. Just to prove a point. Show good. So, oh yeah, now let's get out of content. Yeah. Yeah, everyone knows the site password name. What is it? That's okay. So yeah, so just to remind you, this is sort of what it looks like in seven. The interface that everyone's gonna be more familiar with. And you're right, it's tiny, it's like gray, it's easily easy to read. Yeah, and then if we start adding stuff here, like it is gone. Yeah. Like Drupal by itself doesn't really like, think that much of health tax. Don't think the best example is that, like the title field, probably the most important field on the node, doesn't even give you a place for it. Whereas like, just a little bit of themeing and you can sort of make that part of the workflow in terms of writing the content. And I think as we end up in a more decoupled world, you know, you're gonna have places that are gonna do this. But if you're stuck on Drupal Core, right, and you still wanna make this happen in your organization, this is a simple thing. Yeah. Sure, hey. Yeah, I guess there's two of you stacked right in a row, so yeah. Fight it out. Yeah. I just wondered why you didn't choose the 70s. Usually when we wanted to write a kind of a feature, we figured seven would be the job. So why would you choose one? Cause Bart did this way out of there. Yeah. Initially I was pushing Dave, I was like, let's theme this and make it pretty. And Dave was like, no, street cred? Bart did. He's like, I'm paraphrasing. Yeah, it's not about street cred, it's more about lowest common denominator. Like, let's say you have users that can log in and put in comments, they're generally, they're not gonna be able to see, they're not gonna be able to see Bart did. Or they're not gonna be able to see seven, they're gonna theme, but you can still get it in this interface. Because you can see, you can do it to Bart did. And if you can do it to Bart did, I may think you can do it to any other thing. So that is why I chose it. Run to the back end, Bart, and don't do it. No, no, no, no, sorry. The admin side is all set. It's all really super zinelegible, like 800 and this off. And did you have any challenges with this and seven? I can show you the CSS, I remember. It is like the world's most naive CSS survivor. Like I grab onto like the field classes and just like float this side, like left, float the field side, right, and then give them fit and give them percentage width. Like it was, it is trivial. Like trust me, the CSS that makes that, this page is laughably trivial. You would never implement this. But because I have just experimented to see like how easy would this be? And you can, you can definitely do it with seven. As well. I just wanted to do it with FartTex. What it's point of making is that it's a very simple thing to do, but it's a huge difference. Yeah, exactly. Exactly. I thought FartTex would hit that one. Sorry, right above your ears. When the health test is hard to implement on big sites, for many reasons. For example, the University of Ottawa where I work, it's gonna be super hard to implement the health test for various reasons, between different faculties, like the lifestyle guides to this process involving probably 30 people with approvals to implement this across site-wide. If we can view this, we're talking about having it as a PDF or as pages on the side, how do you let your content editors review this as part of, as part of like the routine thing? It is not in front of them all the time. You're talking that you're one of the rare people who would open that style on the side and compare it, but for a normal person, normal content editor, a staff, a normal staff at a company, how do you, quote unquote, force them to use that staff? Culture, right? And it's perfect. You just hit at the bottom part of the content strategy quad, right? It's about the people as opposed to technology. So my answer is one word, but it's very complex and your situation is extremely complex. I don't know that this is the answer for you. But if you have none of this right now, even if you can, I know all those content style guides are competing 100%, but if you can sort of pull out their basic components, like sentence case versus title case, right? And you can just clean that up for your users, that'll help. I know that's like a really vague answer, but that's another talk. I had a client recently where I was pitching them basically integrating the style guide, because they must have, they just don't have much public review of how to style guide. And I was pitching them, let's get the style guide into the kind of management system, because they had a lot of people writing for the site and they were basically like, oh, we used to have a style guide. In reality, every article we're writing is totally subjective and we don't even follow it. So we don't have one. And it's like, all right, well, I feel that it is that. I mean, because we can't enforce anything because you don't want to. But there's only so much you can do. You need to have people on board. So it really is a cultural thing. If everyone is on board on making their lives significantly easier, then you can do it. But otherwise, there's some things you can't change, but that's the plan. That's our time, so we're gonna cut it. We don't have a question yet. How are we gonna do it? We're 15 minutes. Are we good for time on the schedule? It's the right time. Yeah, well, we'll answer the question. Okay, feel free to write. We're very accurate there. That's strategy. So I'm coming from the designer side of things. The site where we're doing it right now is the content is mostly supposed to be contributed by the community. But there's a leadership section and there should probably be some consistency in how those leaders are set up. So the content strategy, then if we have user personas and user scenarios, should those be used to also build the content strategy or are those supposed to be everything? How varied are your user profiles? Like are they sort of super niche? Do you sort of have three different versions of mostly the same person or do you have very different user personas? Okay, come chat with me. I have a different answer for both of those two situations. Hi, I'm Bexler and then we'll laugh. Oh, sir. So right now there's an admin UI redo for Drupal? Yeah. I don't know if they're necessarily looking at this type of thing. So, yeah. What would you say to that team after you looked at gathered content and... So the thing is, and why it's sort of a bit more subjective than that, is Drupal gets used for lots and lots of very, very things. And not all of them are going to necessarily, I don't know if we can handle all of this, but the things that are, we can leverage what we have in Drupal to make much better content management systems for in those cases. So, it's that kind of thing, may or may not be a hard sell, but like a UX redesign, that isn't specifically for authoring content like that. But I mean, definitely there's some good ideas that we should steal from... I mean, Drupal is turning into a content type, especially with APE. So, would you say, in a lot of the admin UI, has a lot of inertia from previous versions of Drupal? So, maybe it's something to think about. Well, I'm an old Drupal dog, so I'd like to say that belongs in contrived. But I think that's not the current mentality, so I don't know. Thanks for your time, everyone. Thanks a lot.