 All right. Hello everyone. How are we all? I'll just check the discussion sounds working. Yep. Yep. Cool. All right. Cool. So welcome. My name is Kristi. I work at Salsa. I'm a community manager and I'm also the track chair for this year's Drupal Gov and I'll be moderating the panel today. And today we're going to be talking about content creation management and the overlap with user experience. I think about this in a couple of ways. It's the understanding of the right content for a site build and how that is best structured, how to then upload that content into a site with useful workflows and a great UX. But this is an open panel. So if you've got any things to share or any questions or tips that people in our field are doing, please do let us know in the discussion forum. We'll hopefully be able to do some Q&A but 20 minutes goes pretty quick. So we'll see how we go. I'll ask that only one person speaks at a time and I'll just round Robin and ask you questions as we go. Cool. So with me we've got Matt Fenwick. So Matt is the content lead at Oxide Interactive and specializes in grounding content for both user needs and business requirements. We've got Angus and he's the lead content strategist at Weave and is also the organizer of the Canberra Content Strategy Meetup and an official trainer of Content Design London. And then we've got Eddie who works at Sparks Interactive and is interested in accessibility, usability and auditing tools for content. So thank you all three for joining this and thanks to everyone for attending. I thought we could discuss a few things today. Content strategy, creating great content structures, content governance, the UX for uploading well designed content in the backend and how we can help clients at each of these stages. So Angus, I'd like to start with you please. Would you like to talk about content strategy as an early step in the process of a site refresh or site build? Sure. So at it's simplest, I guess most people have heard of content strategy and it encompasses a lot of different things. But at it's simplest it's really about as an organization reaching a shared understanding of what your content is for, like why do you even have content. And one of the most common problems we see when we go into organizations is you know there's too much content. It's a mess. Nobody can find it. Content just gets published kind of when somebody requests it without any particular sort of governance over that. And what that really comes down to is the organizations don't have that really strong shared understanding of first of all who their users are, who they're writing content for and what are the problems that they're trying to solve for those users. So reaching that shared understanding early in a project really then means that you can create kind of content structures whether that's an information architecture or a content model that are focused on answering user needs rather than just wrangling the kind of the content that the organization already has. Angus, what methods do you use in the early stages of the project to get that from clients? We always start with research. So it depends on the budget of the project, how much research we can do and what forms. We'll certainly run sort of internal workshops with stakeholders or we'll do individual interviews with stakeholders. Some of the time we look at existing things like analytics and that kind of thing to see what's been working and what hasn't been working on the current site. But I think most importantly we'll make every effort to talk to real users and to delve into what are the kind of problems that they're having, what are the kinds of needs that they have that this study organization should be solving. So I'm just checking the discussion form if there's any questions. It doesn't seem to be able to just check the live to me. Matt, I know you wanted to talk about educating clients about content modeling. Do you want to elaborate on that? Yeah, cool. So following on from what Angus was saying, once you've got the basic content in tent defined, then it's about translating that into the, I guess, the guts of the content. What we tend to see, I'm certainly working a lot with government and working with or seeing work coming out of some digital agencies, is that there tends to be a bit of heavy focus on the visual design and not as much emphasis on the structure of the content. And so you've got the information architecture, which governs the site map. But a lot of the time people will stop there. And then the content itself, what happens when you get to the page is just this vast, undifferentiated blob. So we talk about container projects where agencies get paid to deliver containers. So things that the client can fill with sort of whatever content they like. And that presents problems for their user experience because it's at the level of content that people are actually going to be able to get something done, you know, complete a task, apply for a benefit. So content modeling is essentially the practice of working out what content do we have, what do we need, and how should that content be structured? And if you've got an analytical brain, then you'll love content modeling because it's very much about pulling content apart and putting it back together again in a structure that's, I think the key thing is consistency here. So you can define a content type and then like say a biopage, and then you're really iterating on that type every time you create a new instance of that type. And I think it does curtail clients creative impulses where they want to go rogue and write whatever. But I think one way of selling them on this is by showing them examples from other organizations where the content's clearly inconsistent and then just saying, you know, how does that affect you when you see that? So, you know, getting them to think beyond just, I want to be random to, you know, how can or what's the actual impact on the user? I'm happy to talk more about some techniques if there's time. I think this is to question the live Q&A. I'm sorry, I can't see it. Are you mind reading it? Yes. So there was a question here from Max. How important is hierarchy? How hierarchy? Well, I can't even say that word. I'm so sorry. Document outline hierarchy. So make me say something. We're just going to move right after that. So document hierarchy. So, I mean, content modeling is all about defining the relationships between the parts. But hierarchy is only one relationship. So, you know, you could think about hierarchy as like, you know, you've got your heading and then your subheadings and so on. That's a hierarchical relationship. But it's also helpful to think about associative relationships. So as an example, anytime you read a book on content modeling, they always talk about like music or albums for some reason. So an album is an album is going to have an artist and an album is also going to have tracks. So each of those things could be discrete content components that are going to have a relationship. So it's saying to the question, depends what you're trying to do, and if a hierarchy matches the user's mental model, but generally be encouraging people to think about associative relationships or navigation as well. Like what's the thing that people are likely to want to read next after they've read this? Cool. So Eddie, you raised a number of topics in our notes about how can we design building block content types for common functionality, including form displays, view modes and taxonomy is also the importance of common terminology and approaches across sites. Do you want to talk about that? Yeah. Hi, everyone. I could talk for a few hours on that, but we'll keep it short. There's a lot of things in that. And I think talking on what the other speakers here have talked about, it's just about defining some of those formats and structures of your content really early on. And what we do with sector with our distribution, across all of our sites, we have sort of common content types, one that's always for newsletter, one that's always for resources, one that's for events, et cetera. And showing, as someone said, before showing examples of how their content might fit into an existing well-tested structure that works for other clients is really a good way to get them on board. And Alexander here was talking about, in the questions talking about content, I think is really good. There's lots of ways of doing that and showing examples of where it's working is important. With those structured content types also becomes the underlying structure. Talked about the detail, you know, a lot of this comes down to the detail of looking at what are the types of content they're putting in there, if it's dates and times, those sorts of ones. And what we've been really keen on is trying to make those consistent so that even between websites that are all based upon our distribution, an event type is very similar from one website to another. It will have its differences for each requirement, but having those same field names and same view modes for like a preview or a teaser and for the default page or for a social media share or something like that really helps to have that consistency and that confidence in what you're presenting to someone works. So thinking about what's been done before and why it's been done, always that why question is good. Those sorts of approaches that common stuff means that people even within your development team can have a consistent language and that that can be conveyed to your audience or to your clients in a way you can reuse documentation, you can reuse testing scripts, all those sorts of things. So don't think about it in the short term, think about it in the long term and also in the exportability or the maintainability of your site and your client's content. It's great for exporting down the track if you've always got something called last underscore updated for your updated date, you know, it's not date changed or something like that. So just really thinking about what are the basic fields and structure that your data goes into and you can show the client and when you've got someone working for one or two clients, it's probably going to work for the third, fourth and fifth clients as well because it's tested through. So, you know, lessons learned and work on where you've gone from, don't reinvent the wheel every time. I've got a question here as well. Do you think as Drupal professionals, we lack a standard way of implementing bread and butter IA and what might happen to prevent endless bad sites? Who wants to answer this one? You're all too very keen. One of the issues with, so one of the great things about Drupal is its flexibility and the fact that you do have this fantastic toolkit to go in and build, you know, content types and menus and you can sort of put together your site however you like. That's always been one of the real strengths of Drupal and it was, I think, you know, probably, it's probably still the mark later in terms of CMSs in terms of what you can do in content modeling, at least within the UI, but that does run the risk that, what that means is that every Drupal site in the real world ends up looking completely different. So, you have a thousand kind of unicorn sites instead of, you know, WordPress sites all look pretty much the same because WordPress has this very opinionated about how you should structure your site. So, I think, you know, I think what Eddie's been saying about trying to introduce consistency, whether that's through a distribution or just through developing some sort of community conventions around this kind of stuff is I think a really important thing for Drupal to sort of take forward because certainly what we see when we go into Drupal sites that have been built years ago is that all the good intentions about content modeling, how the content model is supposed to work, have often just been left by the wayside because new people have come into the organization, there's no documentation, nobody really understands what Eddie of this was actually set up to do. Use your more files, you know, once you print it once, it's Drupalite, now it's exportable. That was harder back in the day, so use those approaches to make things consistent and write documentation once, not 30 times. Just to follow on from that, I think it's really important to consider governance as well, who gets to make the decision if someone wants to do some random new content type, so yeah, we need the governance and then the governance itself needs to be a living document, so what structures are we going to put in place to maintain that and there's a ton of great stuff on this. I think it's Lisa Welchman managing chaos, digital governance by design, something like that. Hit me up if you need the details, but that's a really good book on overall digital governance. There's also an interesting comment here from Max, I'm interested in how much awareness UX pros have in the accessibility requirements regarding content structure. Eddie, do you want to elaborate on answer that one? Yeah, I've been involved with the WCAG auditing groups here in New Zealand. There's a lot to be done. It is an education, just like all this stuff we're talking about, writing plain English. Excessibility requirements are interpretive. There is some hard and fast rules, but yeah, there's some really great, if you look at the DQ who makes X testing, the web aims stuff, there's some good posters at DQ make which are nice visual diagrams which you can give to your designer or to give to the client early on. There's some really good steps that go through. Have you considered, if you're doing a pop-up model, what are the questions? This sort of stuff too. You want it to work, you want to think wider. The sooner you can get those in front of your client and you're designed to end better. It's accessibility by design, not by putting on at the end of the review. For content authors, the new DTA or the new Australian Government Style Manual is a really good resource because it's been written with accessibility in mind from the ground up. Some of the playbooks by the US as well and these sorts of things of looking at component-based front-end design. I think everyone's got a flavour with some of theirs and some of Australians, I think. Use what people have done before that's working and twisted. This is a slightly random question, but what is your opinion on pop-ups in 2020? What did the evidence tell you? It would be my short answer. I've never done a user test where users have said, oh, that pop-up's great, I love it. When do they hate at least? I guess I'm curious, because people clearly want pop-ups, otherwise they wouldn't exist. Where is that coming from? Who's saying pop-ups are great and we should do that? And how could we, as UX and content experts, tell them, well, you should look at other ways of, let it, less invasive ways of doing that. I think it's marketing. It's coming from marketing. Yeah, it's the conflict between business needs, spell shit, and user needs. Get shit done. Cool. And then there's also a question here. I think it was partly answered. Do you know of a tool that reads pages and gives rankings based on optimum, predefined structures? Well, you should probably just start looking at the heading structures that probably, I'm not sure exactly what that person means, but start with the heading structures, see if the sort of accessibility go to that point. But content modeling and on-screen modeling is really important to quantify each of those steps. I don't know if anyone else wants to add something. I'm not sure whether the person's talking about things like readability, but there are definitely tools that can assess that and give you a score on things like the reading level of text. And the only thing is I'd take those automated tools with a grain of salt, because the algorithms are actually not that sophisticated. And the human eye is always going to be a better test. I'm wondering if, so just following up from what Angus was saying, visible threat and readable are two good tools you can use to do those audits, but I agree totally with Angus Therapy. They have their place, but they're not that insightful always. I'm also wondering some SEO audit tools might give you some sense of how well the site is structured. But yeah, probably need to think more about that one. Yeah. I mean, the Lighthouse tool and the Chrome developer is a starting point, but depends what you're looking at. As all these things, any automated tool is not going to see things as a human sees things. So you've got a really accessibility, usability, any other stuff. Totally contrast. Cool. I think we're out of time. Does anyone have any closing comments that I want to ask? Thank you. I think all the questions were answered. Thank you so much. I actually wish we had longer to talk about this, but maybe there'll be a version two at some point in the future. Yeah. So I want to thank you all for being part of the panel and thanks to all the questions that have come through as well. Pleasure. Thank you. Thanks so much. Thanks.