 Hello everyone, so before we get started I have been asked to inform you that if you have questions for us, go to the microphones because we're recording this and we want to capture your souls on tape forever. Cool, welcome to content strategy deliverables. My name is Sam Richard, I am the UI architect for IBM's Watson Group and snuggled generally on Twitter, GitHub and the interwebs. Hello, hi I'm Sam Boyer, two Sam's on stage, it's yeah, I'm, we used to go to meetings as front end Sam and back end Sam. We both used to work at NBC, I still work at NBC, I'm a manager enterprise architecture there and I'm SD Boyer on Twitter and GitHub and generally the internets. And you are here to learn about content strategy deliverables. Now before we get started, because I know people like to follow along at home, the slides are available online at that URL. It is case sensitive because GitHub is case sensitive because GitHub doesn't know how the internet works. So make sure you type it in exactly like that. You don't catch this URL now, we'll get it to you at the end of the presentation. Let's get started shall we? And we're going to start content strategy with standards. Who here has heard of North? The ten people who have been at all my other things today, fantastic. So North is a set of standards and best practices that I came up with all at NBC and we open sourced and it's grown into this semi-large standards and best practices structure document I should say. It's the URL is pointnorth.io and amongst other things it describes some content strategy, how to go through content strategy. And a lot of what we're talking about today, the written form is in North, the long form written form is in North. So when you like to go back and reference this, while you can certainly reference the slides, the longer expanded version of this is in North. It's a living document so as best practices change, these slides might not get updated but North most certainly will. So we'll start with how North defines content strategy. Content strategy is the process by which content is analyzed, sorted, constructed and placed. Users come to a site for its content first and foremost. So it is the most important part of the site. Not your design, not your interactions, not that spiffy animation. Your content is the most important thing so our design process starts at our content. Before any discussion of design or development, an understanding of the product owner, that's the client you're working with, an understanding of their content is imperative in order to produce not only an effective website, but lay an effective foundation for any future endeavors, from apps to ads to printed material. You'll find that as you go through the content strategy process you'll suss out the core content of who of the brand you're working with or of the client you're working with. And what the work that you do here for the web will reverberate across everything else that they do. So you can charge more for it, which is fantastic. The entirety of a finished product is determined by this initial step, from what content is actually put onto a page, to what components get built, to what the final site looks like. Your content and your content's value on a page are a design constraint. They are a visual design constraint. The best way to produce your content and to have your content viewed on a site, that is a constraint of your content. You cannot make design decisions effectively, you cannot make user experience decisions effectively, you cannot make technology decisions effectively, without understanding the content you're working with first. If you don't, everything else is a guess. You cannot know what the most valuable piece of a website is, what you should actually be building, what you should actually be investing your client's time and money into, or your time and money into, unless you know your content in and out. This is the most important thing you can do for your site. Questions? Awesome. Content strategy has a couple different pillars. The first one is project vision. Second, our user personas, followed by content inventory, content audit, content modeling, and finally, information architecture. All of these are wrapped up in a nifty little web tool for you to use Intake Center, HTTP, intake.center, yes, .center is a real top level domain. I don't know why, but it exists, so I got a URL for it. Intake Center is a free and open source, AngularJS-based web app, for going through a good majority of this content strategy and intake process. It includes everything from defining roles and responsibilities to actually modeling content based on schema.org schema, which is a Microsoft, Yahoo, and Google-approved way of talking about content. So if you model your content through schema.org schema, you instantly, you essentially instantly get SEO boost from having your content reflect how they are expecting content, how search engines are expecting content to look, assuming you do the legwork in the actual CMS to apply the correct properties that you've already determined. So awesome, very good things. First up, project vision. Who is this site for? A project vision is the grounding point of a project. It is the single sentence source of truth for which all other decisions about a project are made. This is very important. This is the first and most often referenced piece of your content strategy. Why are you building this? What is the point of this? What does it all mean? A project vision answers a couple questions. What is the product owner's goals for the site? Who is the site built for? What do we want our audience to learn? Who is maintaining the site? What do they need to be able to maintain it? And what are factors critical for success? All of these need to be summed up into one sentence. Now, the reason we want this to be a single sentence is it forces us to focus. It forces us to really think long and hard about what we're trying to accomplish for this project. And by focusing it on a single sentence, it allows us to easily reference it and easily make quick decisions about it. So for an example, made up news organization, a project vision may look something like this. In order to provide for a well informed electorate who want to stay up to date and relate to high quality, relevant worldwide news and information on an ever growing array of platforms, our editorial team will utilize an easy to use platform that can be accessed from any device from across the world to quickly and effortlessly update and create new stories. Yes, it sounds like a giant run on sentence. Yes, it looks like a giant run on sentence, but it's a single sentence. And it's a single sentence that we're able to reference as a whole that encompasses all of these ideas. If you've ever worked in the United Nations or looked at any United Nations proclamations, those are 40 page long single sentences. So be thankful we're not writing those, but we do want to keep it as concise of a run on single sentence as possible. Second step is user personas. Who uses this site? A user persona is a character chair of a type of user that will be accessing the site. It starts off as a hypothesis of types of users that are already using the site. If you have analytics available, gather your hypothesis from these. You then should refine your hypotheses through user interviews, through actually talking with users, both current users and potential users, about what they like, what they don't like about a site. And update your user personas through those interviews. User personas are best when they are not something like 18 to 25 year old white male. But rather something like television show fanatic, or drama fanatic, or celebrity fanatic, or analytical researcher. Something that describes how they actually interact with the site. The goal of the persona is to group people by how they interact, not by what their demographic is. A user persona generally contains a name, either real or a character chair. I personally prefer a character chair of a name to a real name. I know many designers prefer a real name because they find it easier to empathize with that person. Although I can empathize with an idea as well as I can empathize with a name. It should include their motivators for using the product, primary, secondary, and tertiary. Their typical use of the product and pain points they may have. Pain points are especially important because it shows you where you have problems on your site. This isn't just, when you go to interview people, it shouldn't just be for your site either. If you have a current site, fantastic. Walk people through your user interviews for that site, for the site that you currently have. But also walk them through competitor sites. By walking them through competitors, you're able to see where you stack up and how you can improve upon the people you're going to be directly competing with. A user persona looks something like this in Intake Center. They've got a name, they've got a picture, and they've got some typical uses and typical motivators and pain points. So political junkie for this news organization, regularly comes to the site during breakfast, lunch, and dinner, and obsesses over breaking news. They want to stay up to date with world affairs, make informed decisions during election cycles, and are interested in the events of the world. But they really don't care about human interest pieces or fluff stories. So when you start to use these user personas later on, they're going to start to assign value for your content based on your user personas. Breaking news, high value for this user persona. Human interest piece doesn't give a crap. They don't care. It's going to be very low value, if any value at all. Your user personas become a grounding point for your value that you're producing for your site. When we're building websites, we're not producing pages, or ideally we shouldn't just be producing pages for a given deadline. We should be building as much value as we can for our clients or for our brands or for ourselves in the given amount of time that we have. The way that we do that is by making sure that things are valuable to our users. When we talk about users, users are not just the people who come to visit our site for our content. They're also the people who actually maintain the site. So you'll have editorial users. You can even have product owner type users, lawyer type users. I know a couple people who I've talked with this week. They work for medical device companies, and they have a ton of legalese that they need to put on their site that is pretty much unvaluable to anyone except for their lawyers. So they would have a user persona for their lawyers, and those lawyers would get value for legalese. So you're going to have multiple different types of user personas as you go and build these projects. So as you can tell by the change in background color, it's my turn now. I'm here basically as kind of a meta footnote to this. Sam has already started talking about this interview procedure when you're defining the different aspects of your content strategy, the user personas, and before he moves into the next step where he's going to talk about content inventory, audits, modeling, I wanted to step back and talk a little bit about domain modeling, which is a general approach to software development, which has been around for a while. I think it's helpful. Do I press the buttony thing or the outer thing? You press the right thing. The right thing. Oh, it works. You've used this before. I have. I don't remember things. I rely on you to tell me, you know how this works. A domain model is a conceptual model of all topics related to a specific problem. It describes the various entities, their attributes, their roles, and relationships, plus the constraints that govern the problem domain. So this is worth talking about because there's a... when it actually comes to building out a project, building a site, there's a lot of modeling that has to be done in order to figure out what all the entities in the system are. I mean, Sam was just talking about breaking news versus human interest stories. How do we characterize the importance of these two contrasting elements inside of a relatively formal model? They're important parts of the system that's being designed, of the content that needs to be conveyed. And the general practice of domain modeling is really oriented towards figuring out what the parts of your domain are. In this case, in the example case, the domain is a news website. But domain modeling is this rigorous approach to software development. In many ways, it's a similar to content strategy, but it is broader in scope. It's been around for some time. It started in the Java community, largely in the Java community, probably 10, 15 even years ago. But its modeling techniques are still useful, generally speaking, in content strategy, especially if there's no existing site to work from if you are starting from scratch. In a nutshell though, and for y'all's purposes here because I assume we don't have tons of Java engineers sitting here and we're not talking about back end architecture and infrastructure planning, this is enough. Basically, the domain modeling process is an awful lot of domain experts or the clients, assuming an agency model here that you're operating in. The clients are going to provide a big, raw picture of the domain that they actually have. What does our news site need? What are the parts of it? What are the different pieces of information? They have this big picture in their head of the way that they actually want it to work. And your job is the people actually implementing it. Putting together this model is to refine that raw knowledge into a tight and concise model. And in the process, you'll gain domain expertise as to how their domain actually works, what's important in it. Actually, doing the modeling, I picture a content strategist and like a domain modeler in a room with the folks who are the experts, who are the clients, whatever when it comes to actually nailing the stuff out because you need a lot of the same information to do it, but it is suddenly different tasks. So proper domain modeling really should happen in tandem with content strategies at the same time in your planning process that you should be doing domain modeling as when you're doing your content strategy. But you start with these big broad strokes, the big brainstorm, outline all of the big ideas, the concepts in the domain. You chase the rabbit holes down at least a little ways. You figure out what the pieces are of the domain, the things in it, the interactions, the behaviors, the rules, the constraints, these kinds of things. And then you iterate on that. You refine. You figure out, well, I don't actually need to disambiguate between, I don't know, a news story for lower Manhattan versus all of New York. I don't know, whatever's relevant to the particular model that you're working in. But you get things down to their essential kernel of what really, really matters, the defining characteristics of the content that's trying to be conveyed. You refine and you reduce new experiment with prototypes. Does this actually meet the needs that we think that we have? And you return for more input over time from the clients or experts when things stop making sense. This is done throughout the project. I mean, realistically, like, software projects are hard. We learn things as we go. We're always changing and updating. So it's an iterative process. But the key artifacts, this is what really matters, I think, here. So there's going to be a lot of diagrams, which are generally produced in the proper domain modeling process. And they're going to have lots of names of things, like entities and value objects and services. And that's very much oriented towards the implementation of a real functioning, well-structured software project. But when it comes to the overlap with content strategy, what really matters is the idea of ubiquitous language. That's the artifact that domain modeling will produce, which will be really valuable in content strategy. So the ubiquitous language is kind of a self-explanatory term. It is a set of terminology which is used by everyone involved in the project. That is everyone from, you know, the developers all the way up to the, ideally, the users. Like, same concepts should apply and should hold. It is unambiguous. It is clear. It is precise. And it makes sense to those who came to the model before, again, assuming you're an agency that has, you know, a client who wants to build a news site. The ubiquitous language that you come up with should be familiar to and work with the terminology that the folks you're building the site for are already using. It doesn't have to be exactly the same, but it should feel comfortable. It should feel close. It should be intuitive. And it should be precise. And it describes everything that you need in the model. What are your content? What are the interactions between the content? How are the, what do we call these different types of interactions from users? What are the rules on how content moves through the system, especially for publishers? And if you're focused on content, a lot of this ends up being, a lot of this can end up being related to the workflow that you used to actually produce content. But this ubiquitous language is, again, from content strategies perspective, the most important thing that will be produced by a more domain modeling type process. It will hold your group together. Without ubiquitous language, everybody is going to be talking past each other at least some percentage of the time. It's a huge waste of time. It's a huge frustration. It's how you get wasted effort, wasted work. And poor outcomes. So, with that, we're going to move on to content inventory. What's on the current site? This will apply, like I said, if you have a current site. If not, domain modeling will help you with this process. Content inventory is an objective, broad strokes approach, looking at the current content available. It's not just the pages or the screens, but the attributes and pieces that make up the larger pieces on the screen, the larger chunks on the screen. It should contain both intrinsic, title, owner, last updated, and analytical, like page views, ranks, and notes data. So, you want kind of a holistic understanding of how everything is constructed from its little Lego type pieces to get to a page through this information, sorry, content inventory. It'll look something like this. This is loaded hard to see, easier to see inside of the North document. But basically what we have here is the blue bar is a page at a URL that you can get to. And then each green piece is a widget on that page. Some of the widgets are content that we're creating, that we provide. And those are the line items underneath each green widget. The green widgets that don't have line items underneath them are pure widgets on the page, like the social share bar. We don't really provide any content for it. It's just a thing that exists that picks up metadata. Percentage of Total Uniques, which is the last thing in this spreadsheet before you get to the yellow notes, is part of the analytics data that we chose to put in here. It's analytics about how many page views you have for that type of content, not that page specifically, but that type of content. And then notes because notes are useful. After you've done your inventory or after you've done your initial domain modeling, you then go into a content audit. Does my current content make sense? Basically what you're looking for inside of your content audit is, like I said, you make sure your content makes sense. Is it too long? Is it too short? Is it just right? Can you make it more concise? Is the copy, is the actual wording used in the content too much? Is it not wordy enough? Do you not get your point across quickly? Are pages and blobs actually chunked? Are they small little pieces that you can use and reuse? If there are, what are those? If they're not, should we make them? Is there a way to expand something that's one large artifact into multiple smaller artifacts and have that still make sense? Is the content even relevant and important anymore? If you're creating a new site and migrating in content, is content made three years ago still worthwhile to put the time and energy in to migrate it over? Is the content relevant? It's not just, is it too old, but is it literally out of date? Is it literally something that is no longer relevant to your product? Why keep that around? Part of this, what you're going to wind up doing with all these types of questions is you're going to do a gap analysis, which are four different things you can do with your content. You can either keep as is. You can revise and edit to make it better. You can delete it because it's not relevant. Or you can create new content. You may find that current business goals don't match up to the content that you have, and you need to create new content to fill that gap. You may find that through your user interviews, your users want something that you don't provide, so you need to create new content to fill that gap. One important thing here that when we're talking about content is in the Drupal world, we think of content as node content types. Content in terms of content modeling, and this goes back to ubiquitous language, the content we're talking about is anything a user may want from you. So an image is a type of content. So a user profile is a type of content. A poll could be a type of content with different attributes on all of that. So what you're looking to do with this content modeling is not just think about nodes. You want to think about everything, basically anything that could be considered an entity in Drupal. This includes taxonomy. Taxonomy is fieldable. Those are all types of content. After that, yeah. Sam has something he'd like to say. Just don't think about what Drupal makes it first. Think about what it is first, and then think about how you map that into Drupal. Yes, that is important. Once you have an idea of what content you have, then you can say, okay, well, let's figure out what makes up my content. You model your content. A model is an overview of the type of contents available. Content modeling, if you've ever done it before, you probably just went straight into Drupal to do it. Actually, one of the things that we're very fortunate to have in Drupal is Drupal, as Sam Boyer once said and I really enjoyed, is optimized for the use case if you don't know what you want to build yet. Which is very good for content modeling. We're very great at breaking everything out into individual content types and then fielding each one of those. That's fantastic, but that doesn't provide a full story of a type of content. You also need to know if and how that content is valuable. So each content model you create, each content type you create, again, this is not Drupal's node content type, this is any entity, needs to have value with user personas. If content isn't valuable to at least one user, don't use it. It's not important. I don't care what a product owner has to say, it's not important. Good bottles include both visible and structural attributes, things that tie different pieces of content together, as well as the actual content that they have in themselves. Attributes should be determined by the inventory, audit, and model, and they should be presentation independent. When I say presentation independent, what that means is don't have something like mobile title. That is bullshit. Death to bullshit, as Brad Frost likes to say. If you haven't seen Brad Frost's Death to Bullshit talk, go watch that after this or tonight. We are designing content. We are not designing presentations. As Josh Clark likes to say, and I like to quote him saying, presentations deprecate. Content is forever. A great example of this is TV Guide. TV Guide a couple years ago, or TV Guide back in their heyday, they realized very quickly that what they were doing was all of the content, all of the different show listings, they were dividing into very small, minute pieces. Who was in them? Who all those people were? Who all the art directors were? Everything, everyone. And they stored all that information separately, available in a database that they then happened to print as a magazine. Fast forward to a couple years ago. Back then they split, when they decided this, they split into the magazine and the actual content. Fast forward to a couple years ago, the entire magazine division for TV Guide, the entire magazine division of TV Guide, sold for a dollar. You could buy all of TV Guide magazine for less than the cost of a TV Guide magazine. But they didn't sell their content. Their content was still valuable. It still is valuable. It's still up on their website. Their content was forever. The magazine was a passing trend as it turned out. Do not mix presentation with content modeling. Your content will outlast any presentation you hope to build. Like I said, content needs to be valuable to at least one user. I jumped the gun a little bit on there. Sorry. TV Guide, so I made up for it though, I think. This is generally what a content model will look after you've finished it inside of Intake Center. It'll have a name. It'll link to the schema.org description of that type of content. And it will have a description. It'll then show you each user persona that has benefited from or would benefit from this type of content along with their benefit statement. A benefit statement describes how this user persona or why this user persona wants this type of content finds it valuable. So for the political junkie for article, as a political junkie I want the most up-to-date information about the state of the world so that I can stay an informed citizen. It's very valuable to them. It's a 13. When we're doing value, we're working on the Fibonacci scale. Same way that we do sizing for agile user stories. Intake Center will show you the total value for a content model as well as how many personas out of all of your personas it's valuable to. So this article piece of content happens to have a total value of 21 and it's valuable to 3 out of 3 personas. Which means that when you start to go create your final implementation, whether it be in Drupal or whether you use this content model to feed a native app or to feed digital advertising which you can do because you understand the content now you'll understand what types of content are most valuable and what features and functionality you should push for first or you should encourage your partners or the people who you work for or with to push for first because you understand how many people it's valuable to and how much value it is to those people. It'll then have all of its different attributes including how many different types of a certain attribute you have if it's required different types of input something to be aware of when working at Intake Center is Intake Center One thing we have in Drupal is we have entity references in Drupal Entity references are fantastic for internal use but they mean nothing for external use outside of Drupal's database. The way that we reference things on the web are URLs. So if you want to reference a URL if you want to reference let's say an image from an article that reference would not be in content modeling land a entity reference type it would be a URL. When you go to translate that into Drupal you could make it an entity reference but in content modeling land that's a URL because that's how we that is the domain language for linking two different types of content. Finally we have information architecture what pieces of what content go where when you're building an information architecture essentially what you're doing is you are creating the HTML outline of the document for those of you unfamiliar HTML source order literally is an outline it is literally an outline of the content you have on your page what you are building when you're doing information architecture is you are building an outline so what you build can directly and should directly translate into your HTML source order. When building an information architecture you should keep a couple things in mind first the most valuable content should be most prominent should come first this is pretty easy to figure out when doing an outline but pretty hard to determine if all you get is a Photoshop comp from a designer this content strategy content modeling process should happen before anyone touches any visual design and if you've read any of my stuff or heard me speak before I really don't like Photoshop to begin with so no one really should be designing in Photoshop anyway but it needs to happen before all that because you can't glean this backwards from Photoshop you need to use your value and use your content strategy as a design constraint when designing your final site this is also really fantastic for SEO and accessibility because if what you're doing is you're saying this is the order that my content should appear and then building visual on top of it what a Google search engine will or what a search engine will do when it comes to your site or what a keyboard or an accessibility user will do when it comes to your site is they will get your most valuable content first it'll just be there magically you're accessible not entirely out of the box but a good way along because you're building off of schema.org you're using the actual attributes that schema.org is expecting so you can then build in using tools to put the correct attributes in the correct order on the correct portion of the page and you can boost your SEO sky-high for all of you or for everyone who hires an SEO expert out there I'm gonna give you a hint fire them literally the only thing that will boot there are two things in this world that will boost your SEO ranking content and well-marked-up content well-marked-up content includes schema metadata that you're determining through either this tool or through just generally using schema.org if you use intake center or you follow these steps then you just kind of get that you just need to implement it everything else is guesswork at best your content needs to be consistent and predictable across pages if you're building outlines you'll quickly see that oh look the way that I present content on this page in this outline and the way that I present the same type of content in this outline differs and that's gonna be bad for user experience so you can glean a lot about your user experience simply by creating an outline and you also want to reduce clutter and complication sometimes when we start with pictures the amount of content actually on a page kind of gets lost behind the pretty but if what we're doing is we're just building big outlines you'll see that outlines start to grow and grow and grow and grow and grow and grow and you'll understand immediately you have too much shit on that page and you should reduce that when building your information architecture you'll also probably wind up revising your content model a little bit some general things that I found happen when you revise your content model or you'll find that truncation is not a content strat content that is truncated is never meant to be red truncated so it's always going to do you a disservice in SEO in actual user friendliness everything if you need content that is shorter write content that is shorter it's that simple if you've ever been to the New York Times homepage and really taken a deep look at how they deal with promoting something to their homepage they'll have a short little paragraph that is that gets across exactly the gist of the article and usually is mostly what the first paragraph is in the article you click into it but not exactly why is that? they wrote that short article that short description, that short paragraph specifically to be read in that short form and that's what you should be doing too the best way to go about doing this is to build systems of content so when I say systems I don't mean mobile and desktop title what I mean is short and long title and then the presentation can choose whether you want a short or a long title but you can do something above and beyond that you can also make you might also want SEO friendly and human readable titles if we combine those two things we can have short and long SEO friendly and human readable titles that's four different types of titles we have to choose from that sounds like a lot and a lot to ask an editor to do it probably is but giving them those options and having them understand if you want your content to show up and look and work well within our system start to fill these out they'll start to understand that it's beneficial for them to be as precise as they want with content or as they can be with content one of the things I found about moving my designers into actual code instead of working in Photoshop they then get direct control over the design decisions made in the actual implementation as opposed to leaving those translation decisions to a front-end developer by giving control of your content to your content editors how that short and long form content appears or not appears but is written as opposed to just programmatic translation or truncation with much more direct control and make them happier content editors content needs to be easy to navigate don't paginate your content unnecessarily don't chunk content unnecessarily having different pieces of content in different forms in different fields that's good that allows for lots of reusability and lots of mixing and matching but having a three paragraph article split over three actual pages that's terrible for the user and don't do that and you need to make all your content available always users are the same regardless of what device they choose to come to your website on don't make assumptions about your user based on device, device detection is and always will be bad Josh Clark another one of my favorite quotes anytime you say someone won't want to do that on mobile you're wrong so don't, don't make that assumption let the user choose what they want how they want to view your website what device they want to choose to view your website and give them all of your content information architecture really super brief one kind of sort of looks like this I've got a site header with some branding the dashes are where I'm grabbing content from the others are groupings of content so I have the brand content type with the logo field at a size that I wanted at I have a site name which is the brand content type with the title field navigation I've got sections which come from the taxonomy titles and I'm filtering by the section taxonomy content area main content it's an article with the title an article with its body and an article with its author and there's one of them and then site footer copyright brand copyright I see pretty much immediately what the groupings of my pages on my pages are going to look like and what content I need in what order and if you squint really hard or not so hard you can see how this can directly translate to source code HTML for your developer to just start working with that is content strategy deliverables thank you very much we have all of your links right here and if you have any questions do we have time for questions we have not really two minutes or something and then we'll run over we have two ish minutes for questions come find a microphone if you want to ask a question which is right there no questions one question so with a lot of this happening before you get to the visual design stage a lot of the pushback you hear is that clients have a hard time visualizing content is going to look like especially across all these different devices until they can see it represented so how do you have these conversations or how do you steer these conversations with clients so that they can understand their content in a more abstract form you steer them away from thinking about it as how it's going to be viewed across multiple devices and think about what it is your content is the same across any device it doesn't want to be viewed you need to know the intrinsic underlying content which is the entire purpose of the content strategy and domain modeling process what it is is what really matters it's still hard to steer them away often enough so the best thing I could say is just reading something this morning about how are the math thing the language that lets you do graphing and stuff like that has an XKCD function to make all of your graphs wiggly because what they found was that for people who are doing approximations you can put all of the stuff in there that you want that says this is just an approximation or some sort of experimental numbers it doesn't matter people don't read but if you make the graphs wiggly people understand that it's not for real so in a similar vein if you must absolutely do something then write it on pencil and paper or something like that keep it out of the medium in which it's finally going to be do not get them over committed to anything like that and then I'll show them back to the question of what it is thank you I was just wondering if you could speak to any specific concerns or issues surrounding if your content is photography if people just come to your site to look at the photos is there anything different about content strategy there? no it's the same process it's just different actual content your images are content and attributes on those images are attributes on your content it's the same process it's just your modeling media instead of modeling articles you can look at if you have particular metadata attached to specific images very useful to combine with your analytics to say hey these particular types of images that are tagged this way are getting a lot of traffic you have to do a little bit more maybe abstract thinking about it because google isn't analyzing images and necessarily pairing that they do an okay job of it but I cannot touch my head in this hat that's super disconcerting I'll touch your head in this hat there it is he's awesome but yeah so keep in mind keep a close eye on your analytics I think actually in some ways analytics are easier when you have much more discrete items like photographs than longer form content thanks is there a way to keep the content edit page from being messy with like having four title fields and four of other fields field groups it's tricky though if you have this thing where you're talking about the New York Times here's the lead that you write if and only if this thing is going to make it out of the front page does that always have to be written for every article or is it just for ones later in your editorial process where it needs to be filled in it's not an easy question Drupal doesn't make it super easy to do this well but like you can organize the things better on the page but often what's complex about that problem is that you actually have a bunch of different people who need to be looking at that one form at different times in a process and if you can if you really want to invest the effort then splitting it out so that you've got different people focusing on just the things they need to fill out at the time that they need to be filling them out that's one way to do it but you can't get that for free that is not easy to do yeah additionally tomorrow at five o'clock it's kind of this awesome power hour that's happening that makes it really terrible to actually go and see any one speaker so Sam is speaking on simple versus easy in here which is going to be a fantastic talk but so is Chris Ruble's talk on frontend performance testing and Eaton's talk on content strategy and then someone else is speaking as well Morton's talking on Drupal 8 theming they're all fantastic talks and it's kind of silly that they're all at the same time but Eaton's talk is going to go into detail about I believe because I believe it's based off of his a list of part article about how to make the blobby body area still chunky but with it looking like you're writing long form text in word so not entirely sure that's what it's doing but you should go hear him speak if you're really super interested about that and catch the other ones on video or vice versa come here one of the other people speak and catch the other ones on video so I have a question about domain models I've seen a domain model that was delivered to my team content strategy done by another team another company and they had modeled the entire basically business model for that group so it was you know here's every single person who works there he's every single thing that they do and it was massive massive document and so I wonder when you're talking about domain modeling you're talking about the experience of this website if you can't tell by Sam laughing you did it wrong that was my assumption and the client wasn't super happy with that there's took like a long time yeah there's cost a lot of money actually I knew that they did it wrong with like your first sentence because what you said was they delivered us a domain model domain models are never done they're never done by one group and then handed to a different group if you do that you're doing it wrong like they have to be a living thing you have to have the architect who was working on them in the same group that is developing in the same group like that it's it's your sort of backbone conceptual document type set of materials that describes everything that's happening if they're going into that much specificity they're also wrong and actually it's like so wait they had like the people who were working right so pro tip people is never part of a domain never ever like people are part of a domain or a role is part of a domain but never like individual people it sounds like they did a monstrously terrible job of too much that sounds like business modeling and not domain modeling yeah yeah yeah that actually does sound an awful lot more like business modeling business modeling is no good to anyone except for the manager domain modeling is good to everyone because they understand and explains how things work not how the business operates yep yep how often is it appropriate to redefine your personas and then to kind of do the re-ranking thing with your content according to them that's a pretty good question generally we we look at a persona initially when we start a project and we build our personas initially when we start a project and when we find analytics to suggest that there are different behaviors on our site we re-look and re-go re-do our personas so part of this content strategy business is much like domain modeling it's never truly done you'll get it to a point for you to actually produce a product or produce a website but then it needs to be followed up upon with additional analytics additional modeling keep going with that system and you will find that oh look there starts to be new behavioral patterns let's start looking at our users again any time you go to roll out a new feature you should be doing user testing on that feature and user testing inevitably is part of user interviews and you'll get more insight into your user personas that way and if your user personas change or you find new user personas maybe at that point you start to look at all of your user personas if you see that a couple of them have started to change or you started to add a couple in general a rule of thumb is you try to get them so starting from nothing you don't have an existing site you get absolutely as far as intuition and discussion can get you and then you try not to change until you have real concrete data that it for questions awesome thank you guys very much