 Good afternoon everyone. I'm Dori Kellner from Slide of Hands Studios. We are a Drupal agency in Fairfax, Virginia. We specialize in non-profit and government websites. I have been involved in data for my entire career. I started doing survey data collection work and then moved into data warehousing. And the thing that really made me understand that I got what structured data was all about was when I started studying food and wine. So when you work in the food and wine industry, there's a common vocabulary everybody uses. So if you're talking about wines and Bordeaux, there's a certain set of categories that surround that. There are certain grape variety and chateaus and rules on how vines can be structured. When I took a class in wine education, I was trying to figure out why the other people in the room who are all in the industry couldn't pass any of the tests. And I had no problem. So every time we had a test and you did really well, they gave you a really nice bottle of wine. It was a really great incentive to actually study and pass the test. But I didn't have that much trouble and I was trying to figure out for the life of me why am I not having trouble with this and everyone else is. And I came down to understanding that I knew what structured content was. I knew what taxonomies were. I knew how to classify things. And so as we were learning all this information, it was just kind of going in with me and it was like made perfect sense. I had no problem with it. And so that's why I decided that food and wine were going to be my go-to topics when I was going to discuss structured content with a group like yourselves. It's a really easy concept to understand, you know, like a recipe. Very simple to help people engage in what structured content is all about. And I figured since it was easy for me to learn this stuff that way, maybe it'd be easy for everyone else to learn it as well. So recipes are my go-to. And today we're going to build the My French Recipe website. So you can start to think about what structures are here that allow us to create a home page that looks like this. So very basic. We seem to have some featured chef at the top with a recipe. We seem to have categories of recipes below it, each of which has some sort of an image. It has a title. And gee, it also has a cooking time. So why might that be important to somebody coming to a recipe website? Well, how much time do you have at the end of the day to actually make a meal? You know, is it Saturday and you're having guests? Is it, you know, Thursday night and the kids are running around like mad? So this is the website we're going to keep coming back to today to show the examples of structured content. It's very easy when you're dealing with recipes to think that it just looks like this. It's just one big, great blob of content. And if you read the Maths IT session about an hour ago, they were talking about how they had to change the mindset of the content creators to get away from just putting in a blob of content into structuring it and how valuable that was for them in reuse of content. When content is unstructured like this, you can't share it. You can't reuse it. You can't tag it. You can't have relationships with it. The web just sees that that's just one piece of content. It doesn't know how to parse it out into information. Okay? When you move into structured content, you're giving the content the opportunity to free itself, to be reused not just on your website, but in other ways that are organized and logical and classifiable with metadata. So whether you're working in blogs and the social space, email, whether you want Google to start picking up your content, structuring it gives you that opportunity. Structuring gives you the chance for somebody to come in and understand what your content is. And by someone, we don't mean a person, because obviously a person can read that same page no matter how we've structured it. But we're talking about other applications being able to come in and find the content on your website and actually use it. Okay? And that's what makes this so important. We want to turn this content into information that is not only readable by humans, but is also readable by machines. So reusable chunks that are scalable, that basically divorce how the information is being displayed on any particular device. So we don't care if it's being displayed on a watch or it's being displayed on a monitor. We want that information to be free to be displayed whatever way it's best suited for the device. Okay? So in that way, our content has now become data, and that data can be classified, reused, and understood by other machines. Brad Frost is kind of a leader in this industry, as far as saying content is going to go anywhere. So you have to start separating the content from the presentation, and whether it's going to be awareable, your refrigerator telling you what you're out of, that you don't have enough eggs for that recipe, whether it's the Tesla whose display is actually powered by Drupal. No matter how your data is going to be displayed, you shouldn't have to worry about it. You should be worrying about how your content is structured so that it can be picked up and displayed in many different ways. When you give up that control, you freed the data. A simpler example that might be very relevant to everyone in the room is simply change it in one place and repurpose it in multiple places on your website. This is the simplest reuse example we can have. So I go in as a content editor, I change the date on this particular event, and then my home page changes, my resource page changes, my topic area page changes, everything changes, because I haven't trapped that date field into a body tag. What I've done is put the date field in its own field where it belongs and let that go throughout the website. So what this talk is really all about is who's responsible for doing this and how do we work together to make this happen? Because we're not all working in silos for ourselves. We're working for a project, we're working for an organization, we're working for an institution. So I want to take one minute max, maybe 30 seconds, because this is a lightning talk, 30 seconds, turn to the person next to you in front of you, behind you, and tell them who you are in terms of are you project manager, are you content strategist, are you designer, are you UX, are you developer, what is your role when it comes to building websites? And it gives you 30 seconds to do that. Many people were sitting next to somebody who does a completely different job than they do. It's sitting next to someone who does a completely different job, has a different role. Hands again. Look around. Every hand went up, almost every hand went up. So the question is why do we work like this? Why are we sitting in cubicles? The reason that I am so passionate about this topic is because somebody once handed me a wireframe and said this was the spec for the website. It had to be pixel perfect according to the spec and it did not have a single bit of information about the content, not where it was coming from, not what was expected of anyone, and they basically proverbially threw it over the wall and said build this. Anyone have that same experience? Anyone here think that that could work at all? Was that a good project? I've never worked with that person again, ever. So let's just start breaking apart what it is that are the components of building structured content and who's responsible for them. And you can see exactly why this happens all the time because it looks like it's a linear process. So you start in one place and people start thinking about what the content should look like and people start designing what the content should look like and you kind of feel like, well, the thinking person hands the paper to the designing person who hands the paper to the developer person and off we go. And that's exactly where it breaks down. By understanding what each of those roles does and what each person is responsible for, we start building empathy between our teams and we become one single team. So that is the goal this talk is to get you to feel like you are part of the content creation team. So to begin with, we have three activities that pretty much run one after another, creating a domain model, creating a content model and building content types. And generally we think of the content strategist as the person who handles that. It might be an analyst, it might be your project manager. None of these are in stone as to who does it because I know, for instance, where I am, a lot of times I'm going to be doing everything on this chart. But imagine having the hat on at the time. The outputs of these three processes end up going into some sort of content creation process. We need to build the content based on the content model and the wire frames. And so we have the authors, the content creators, the UX designers involved at this point. That stuff always moves on to visual design, show me some comps if we're still doing comps, which we can't talk our clients out of doing. And we have some graphic designer involved in that. And then all of that stuff kind of moves on to the end and kind of gets dumped on the developers and told, hey, build this. And of course, the developers never really spoke to the content people and the content people might have made assumptions that the developers know how to build a recipe content. How could they not know what a recipe is, right? Why would it possibly be a developer's responsibility to build out that content type without any guidance? And then again, could the developer provide additional forethought to the content strategist so that maybe they can do a better job? Because our developers kind of know stuff that some content strategist don't know either. So it goes both ways. So to begin with, the first process here is a domain model. A lot of organizations don't do this. A lot of times this is really part of discovery where you're just kind of figuring out what are the pieces and parts? What are the relationships between things on this website? So if I'm building this website that is my French recipes magazine website, a recipe on that site is going to have different characteristics than a recipe on a restaurant website or in somebody else's magazine. There's context around that. You can't just say, well, a recipe is this and that's all that's going to matter. You have to look at the whole environment in which that website is going to be used. So here we have a domain model that shows there are going to be contributors, there's going to be ratings, there's going to be ingredients, there's going to be stores that sell the ingredients. So we're just kind of plotting out what it is that this domain looks like and coming up with all the entities and kind of how they're related to each other. So a recipe consists of processes and has categories and people submit the recipes and so this is a very high level understanding of what's going on. Then, of course, we're going to build a content model out of that. So for those of you who really are, have never been involved in the front end and wondered where were the content types ever defined in the first place, this is kind of where that's happening. Kind of on paper, not really part of Drupal unless you're wearing the same hat all the way through the project and you're probably skipping right to building content types. But this gives us an opportunity to look at all the attributes that are in every entity, determine whether these entities are nodes, are they content types, are they taxonomy, are there going to be entity relationships between them. So this is our content modeling activity. And then we have the content types themselves. And again, if you have somebody responsible for defining all of this, let's get the attributes down before a developer has to worry about building them. What widgets are we going to use for the date? How many different ingredients are there? Is it going to be one field with ingredient and text? Are we going to have some reusable things like a quantity field that can be teaspoons, tablespoons, cups? Are we going to have fields that are actual ingredients where we can reuse the ingredients over and over again, tomato paste, onions, beef? So this is the point in time when all of this stuff needs to be evaluated. We don't want to get to a point where it's built and somebody made a decision about content types, and then we go, but what about? And I have to type in the word tomato every single time I use this field, and this is starting to drive me crazy. We don't want to get to that point. We want to be here. This is why it's so valuable for developers and content strategists to be together here. Because a content strategist, and in fact one who maybe has never worked in Drupal, might not understand the power of what we can do in a content type. So let's start bringing some of that knowledge to the front of the game and start building those content types with the knowledge that Drupal has the most amazing ability to do structured content. And then we're moving on, building our wireframes, and we start to see where relationships and these entities start coming into play that I'm going to have a featured chef, and somehow somebody's going to have to be able to say who that featured chef is at any given time. Is that something that's going to get triggered? Is it something that somebody's going to put a flag on? Are they going to throw it in a node queue? How exactly are we going to indicate this? This is when we start thinking about requirements coming into play, the same time we're doing wireframes, the same time we're validating that our content model is actually going to work for us. So we have, in this example, we can see that we've decided that different types of recipes are going to have different displays on the page. So those types of recipes, obviously, are indicating there's a taxonomy classification. So in order for this page to work, way back when we did the content model, we needed to know there was going to be some taxonomy involved. And then, of course, the different elements, we know we're going to have a title, we're going to have a short description. You need a short description in here. You don't want to just suck out the first 400 characters of the description of the recipe. That'll be ridiculous. Who's going to control for that? People stick in block quotes and images and all sorts of junk in a big open body field. So give people a field in which they can put a short description and say that short description is going to be used on these landing pages. And, in fact, get away from the Laura Mipsum altogether. Start having your content folks writing content based on that content model while all of this other stuff's going on. If we have sample content, we can start seeing if it's going to work way back at wireframing. We don't have to wait until there's a prototype up. We don't have to wait until the site starts getting built and then, okay, we're close enough for the content people to start using it and putting things in. That is way too late to make those decisions. So this is a great point in which we start bringing in more and more people. We start bringing in designers. Designers are going to maybe be using, you know, atomic design principles, patterns, whatever. They need to know what's available. Are they going to have prep time, cook time, and servings available to them in the data? That gives them a whole different view of what can be displayed out to the audience and how to display it. So you end up with way more dynamic, way more interesting sites by breaking things out into structured content. On the development side, a lot of you have seen and done this. So you've built the content types. So we want to make sure that developers are not responsible for determining what the fields are here and what the relationships are that they do this in concert with all the other roles. They bring their expertise to bear on building them and are able to say, well, hey, did you want a pop-up menu? Did you want drop-down elements? Content strategists might not even realize that they have those options. So let's have our developers play a much larger role in finishing the content model and having at least a base to work from, from somebody like a content strategist. And so, of course, we have our normal entity references. We have term references. We're able to relate things to each other. We're able to categorize the data. That's something that Drupal does really, really well, and we should be using structured content as much as possible in our Drupal applications. Additionally, if you're at a session this morning about displaying content in Drupal 8, something very similar to this was discussed, where there are so many different ways to structure and display the pages. Well, you can't structure and display the pages in any way, shape, or form if that content's trapped in a body field. Once you start breaking it out into fields and you can start telling those fields where to go on the page, then you start really seeing the value of structured content and the developers can really start working to create a site that's extremely dynamic and flexible. At the same time, our content creators don't have to worry about remembering what goes in the body field. So it's like, oh, gee, I forgot to put in how many servings, or I forgot to put the calorie count in. They shouldn't have to forget anything because they shouldn't have to remember in the first place. All the fields should be predefined, predetermined, proper dropdowns, proper select widgets. However it is that you're going to structure this, you make it easier for them. At first, there could be a lot of pushback. They can say, but I want to just put in what I want to put in. I actually still had a client the other day tell me, but that line has to be blue. It's really hard to get them away from that whole feeling like they know how it looks best on the screen. They should be collaborating at the wireframe level, at the design level, the comp level to figure out how it looks on the screen, but we need to make it easier for them to maintain standards. Standard presentation, standard information, really by creating structured content really being able to say, this is the format for this particular field and this is what's going to work for us. A really good way to get people to understand this is if you have just a little bit of understanding of schema.org. Schema.org is a collaborative Google, Yahoo game that basically classifies everything in the world. If you go and you look for recipe in schema.org, you actually get this back. This is what they're considering a reasonable classification, a reasonable set of parameters for recipe. If you were to go in and look for music, you could find songs and song lengths and artists and how they're all related to each other. Just about any industry that you look for, you can go to schema.org and start getting a good sense of what information should I be including in my content model for the subject matter that I'm dealing with. You can go in here and see that they have durations for prep time and cook time and there's nutritional information, there's cuisine, there's ingredients, there's instructions, there's total time. There's all this wonderful information and it tells you what kind of information they expect it to, what format they expect it to be in. This is really, really valuable stuff and so you can be working with your subject matter experts at determining what is it that is appropriate for us. What can we take away from this? What can we add to it? Is it all needed? How can we work the world's view of what a recipe is into our domain of how we want our recipes to work for our audience? There's even this really cool little tool that Google provides, which is a structured data testing tool. I'm not going to go into technically how do you get your microdata into your code, but once you've got it there, you can run this tool and it will remap what it finds in your code back into the schema.org mappings and tell you what it's using, which is really, really valuable. Now we're starting to get into why are we doing this in the first place? You had your content strategist and you have your designers and your content creators and your developers and your UX folks and as I said, G, you should all be working together with the reason we all need to work together is because we have one single mission and that is whoever hired us, whether it's a client, whether it's your employer, whether it's a religious group, whether it's a university, whoever you are working for, you're working as a team to do something for them. You're achieving a goal for them. Their web presence or whatever else they're doing media, marketing, whatever, your job is to make sure that that data, that information is usable to them and achieves their business goals. So when we work together and we do things like put in micro data or we put in metadata, we start to come up better in search engines because the search engines can find our information. So we don't just have titles and descriptions, but we have the image coming up, we have the ratings coming up, we have the calories coming up. This is what will make it a much better opportunity for our end-users to find us and for the mission of the website as a whole. You can't see your job in a vacuum. You can't just say, well, I'm just the designer. You're a part of a bigger team and that team has a responsibility. So when you start using structured content to meet the business requirements that your website needs to meet, you start really helping your end-users and your business unit to do better. Social sharing is the same thing. When you start tagging your content, which you can now do because you all know you're going to put your image in a field, it's not going to be in the body, you can say to Facebook, hey, use this image. You can use Open Graph and say, use this image when somebody shares out this page. Here's the field that that image is in and you can specifically say that page by page, content type by content type and tell Facebook I want to use this particular image, I want to use this particular description. So you might have like five paragraphs on that page, but you might also have a field that's holding a short summary and you can tell it that that's the summary I want Facebook to share out. So there's a lot of value that can be added when you can start tagging all these fields for Facebook, for Google, for Twitter, for any other social purpose. For your emails, for any other micro sites, any sites that are doing sharing, anyone who can come in, if you expose your data, anybody can come in and start scraping it and picking it up. And no, specifically what it's for. So we've built a common model now, we've shared the language and we've collaborated and by doing that, we're now creating content that can be reused, that has enormous business value, has become a huge business asset. And that is really the goal. The content is an asset and it's often one of the most valuable assets that any organization has. And so to be able to free it up and allow it to be used and reused, structured content is the way to go with that and as a team, we can all contribute to that tremendously. So any questions? Thank you. There will be a bof tomorrow at five since we only had 30 minutes, less than 30 minutes today. So I'll be doing a bof at five o'clock tomorrow. So if there are questions, you can come to that. But we still have a minute, if anybody has anything they'd like to ask. Come up to the mic. Schema.org, how are the schemas integrated into Drupal? How do you make your terms in Drupal align with what's in Schema.org? There are modules for microdata. There's a few different ways to do it through JSON and other things. So if you look on d.o. and look for microdata, you should be able to find some answers to that. Yes? Quick question on the ingredients and why you didn't separate out the amount from the actual ingredient? Right, that's what I was saying as I was doing it. Yes, that you would probably want to do that. So that was just an example of showing you could throw it all into a single field but yes, I would recommend that the amount and the type of ingredient and the preparation for it, chopped, sliced, whatever would all be separated out. Any other questions? Great, well thank you for coming and again the bof is tomorrow at five if anyone wants to talk about their experience with structured content, I will be there.