 Okay, how's everyone going? We're on the home stretch. So, yeah, I'm gonna make a start. We might get a few stragglers coming in, but I do have a reasonable amount to get through. So I'll make a start. So my name's Angus and I work for an agency called Weave. For those of you who don't know me and don't know Weave, we're an agency based in Melbourne and really our specialty is content strategy. So we're content strategy people and we work on a lot of projects with other agencies, especially development firms, but we also do a bit of Drupal work ourselves. So I sort of come, I have a bit of a foot in both camps, but I'm much more of a content strategist than I am a sort of a hardcore Drupalist. So, yeah, talk today is about content modeling. And I really got four main things that I wanna cover. The first is just to talk about what a content model is and why we need one. I'm gonna talk about some basic principles of effective content modeling. I'd originally planned to talk a bit more about actual sort of processes and techniques and that kind of thing, but I realized I was just gonna go way over time if I tried to do that in too much detail. But I actually think with content modeling, the most important thing is to have a sense of what the principles are and what you're trying to achieve. And the actual process isn't that difficult, it pretty much works itself out once you've got the principles in mind. So that'll be the second part of the talk. I'm then gonna be talking about what content modelers need to know about Drupal. So if you're a person who is working on content for a Drupal site and you're not actually familiar with Drupal, what are the really big picture things that you need to know about Drupal as a platform in order to really take advantage of what it can do? And then finally I'm gonna talk about some of the common issues with content modeling in Drupal. So what are some of the sort of tricky little things that come up when you try to actually implement a content model on a Drupal site? Can everyone hear me okay? Is the mic working all right? Yep, cool. Okay, so I wanna start with a question. I deliberately, I listed this talk as a beginner talk and I have tried to make it accessible to people who don't really know anything much about Drupal. So can I just get a bit of a show of hands? Can you put your hand up if at some point you have created a content type in a Drupal site? Okay, so it is the majority. So I'm not gonna leave the newbies behind. I will be going through some fairly basic Drupal stuff. So the rest of you will have to bear with me while I might go through a few concepts that you'll already be familiar with. Hopefully you'll get maybe a sense of how to talk about this stuff with people who are less familiar with Drupal. Just one, just a couple of caveats before I start. I'm a relative newbie in the Drupal site building world myself, so I've worked on Drupal sites for several years as a sort of content author and somebody who trains content authors, but it wasn't until relatively recently that I actually built my first Drupal site. So hopefully that's an interesting kind of perspective for you to get. I'm not so over familiar with Drupal that none of its quirks seem quirky to me anymore, but at the same time, I might make some mistakes that some sort of newbie mistakes. So if anybody, if I make any egregious errors about Drupal, feel free to point them out in the Q&A, I won't be offended. And yeah, the other caveat I wanna say is that when I get onto the Drupal specific part of the talk, I'm really mainly talking about Drupal 7. So as people who work with Drupal would know, there's a lot you can do with content in Drupal 7 that you couldn't do with Drupal 6. There'll be even more you can do with content in Drupal 8, but I'm not terribly qualified to talk about Drupal 8 yet. So a lot of the specific stuff is Drupal 7, but in a sense, everything I say will only get better in Drupal 8. But if you're on, if you're still on Drupal 6, you can't do quite as much, sorry. Okay, so let's get started just by talking about what a content model is. So content model is essentially, I like to think of it as just a specification of the structure of content in your CMS. So in Drupal terms, we can think about a content model as essentially documenting the content types that are gonna be available within our Drupal implementation and the fields or chunks that these content types are gonna consist of. And as you know, if you've built a Drupal site, what defines a content type is that it's something that has its own set of fields. So that's what a content model is. It's what are your content types, what are the fields within those content types and also what are the relationships between different content types. But why do we need a content model? And this bit's gonna be very, very familiar to Drupal people and in fact, this might seem really obvious. It's not so obvious to people who might be coming from other platforms. So let's think about an author on a website entering some information about a very common type of content, which is an event. Okay, and let's imagine first of all that we have a completely generic kind of out of the box implementation of our CMS. So our author enters an event by essentially copying and pasting a whole lot of information into one big body field. And this is something that you still see in websites all the time, including Drupal sites, incidentally. So there'll be a big body field. It'll do the job of actually, the content will be published and it will be available, but there's not a lot you can really do with that content. Then compare that approach to a more structured approach where instead of the author saying, I'm just gonna create a page, they actually say, I wanna create an event. And the CMS then presents them with a range of different components for that event, which they sort of fill in individually. So for a typical event that might be something like a title, a teaser, a longer description of the event, a photo, a location, which might be some sort of geographical coordinates, a date and time and some information about how to make a booking for the event. So once we've actually got our information in our CMS in this kind of structured way, the reason why we do that is that it allows us to do a lot more with that content. So as soon as we have events sitting in our system as structured data in this kind of way, we can start doing things like automatically adding our events to a calendar. We can then decide that we don't actually like the calendar and we just wanna replace it with a simple listing of events. This is something that happens all the time in websites where people think a calendar sounds great, but then they only have one event per month. So they decide, now let's just have a list of events. That's no problem if you've got properly structured data because it's just replacing one view of that data with another. We can do things like automatically archive events when they're finished. So all we need to say is that in our display of events, we only wanna show events that have a date of today or in the future. So therefore events just sort of disappear from view when they're in the past. They're still obviously living in the CMS, but they're not visible to end users. If we've got our location in our event as a field and if it's in a machine readable format like a set of coordinates, a latitude and longitude, we can think about doing things like displaying a map of the location of the event or linking to a map of the location. And finally, and this is, sorry, not finally, second to last, we can start thinking about laying out our information differently on a desktop view versus a mobile view. So, and this is really, this move towards responsive websites where we know we are gonna wanna adapt our layout to a range of different devices. This has really been one of the big drivers behind the content strategy community becoming interested in content modeling as a thing. So what this basically means is if you have your events in these kind of granular chunks, you're giving your designers and your front-end developers a lot more individual bits to target so they can make a lot more, there's a lot more variations in the decisions they can make about how those events are gonna be laid out as compared to one big field where we can do is really shrink it. So none of this is news to any of you, but this is what we're really trying to do when we're modeling content. And finally, we can think about offering a feed of our events to another website. So if we're wanting to export our data in that kind of structured form, like a JSON export or something like that, then we need to have our events, we need to have that content properly sort of structured in the first place. Okay, so that's what content modeling is. Again, it's not really gonna be news to any Drupal people because Drupal is a platform that's set up to be good at doing this kind of thing at sort of storing structured content. But that's not to say that every Drupal site does this well. So what I wanna talk about next is really three basic principles of effective content modeling. And these are the three things that I think are really most important to bear in mind when you're developing a content model. So when you're deciding what your content types are gonna be and how you're gonna break them up. And the first one I think is probably the most important and that is to separate your content model from your presentation model. And then you've probably come across the idea of separating content from presentation. That was a big part of the, I guess, the emphasis behind the development of CSS and the idea that we have HTML elements and CSS can, it's the CSS that tells the website how to display those elements. So this is really an extension of the same idea. It's the idea that we really have two different ways of thinking about content when we're developing a website. So the content model is all about how content is stored in the database. So it's about our fundamental kind of content structures. It's about the content types we have and the fields that we have. And so it's sort of about how our content ends up getting stored in the database. The presentation model is about how that content gets presented to users of our website. So it's about what those end users actually see and how they, the different ways in which they can view that content. So the presentation model is about pages. It's about our information architecture. It's about landing pages that collect content from various different places on the website. The content model is about the basic content that gets served up to those pages. So the two things are obviously very closely related because we can't have a presentation model without also having a content model. But they are different things. And there are several, there are lots of reasons why it's good to think about them as different things. By the way, the term presentation model on sort of borrowing from Jeff Eaton, who's a famous Drupal person that a lot of you have probably come across, also really interested in content strategy. So he's the one who has sort of borrowed this distinction from the content model versus the presentation model. So why do we want to separate our content model from our presentation model? The first reason is that a single content model might end up serving several different presentation models. And in fact, in the case of a modern website, that will almost always be the case. So we can really, we can think, for instance, of the desktop view and the mobile view of a website as being different presentation models. You know, the layouts are different. The order of things might be different. So, and the user experience is different, but it's the same content that's being served. So we've got a single content model, multiple presentation models. We can then think about, you know, other kinds of presentation models, such as screen readers, for example. So a screen reader that is an audio way for, or an audible way for a visually impaired person to access content, that's another kind of presentation model. That's one that's radically different from the visual kind of presentation model that we have on a web browser. We can then think about, you know, other ways in which our content gets sort of served to different services. So there's things like Instapaper, there's social media, you know, in the modern web, our content is going to get chopped and changed and sliced and diced by all these different services. And we can think of them all as different presentation models. They all need to be served by a single content model because all our content is going to live in one place. So another reason for keeping these things different is that ideally your content model is something that isn't going to change very often. Your content itself obviously changes, but the content model, the basic way that you structure content, ideally should be something that you're in for the long haul. And if you've ever actually tried to sort of retrofit a content model onto an existing body of content, you'll sort of know why. So it takes a lot of work. So you really want to be building a robust content model that's going to be around for a long time. The presentation model, on the other hand, might change quite frequently. So you might redesign your website depending on how trendy you want it to be every couple of years. Or you might at least add new design elements. You might want to rebuild your website in the latest kind of front-end whiz-bang technology. So if you've got a really robust content model, you can actually change the way that content's presented without having to go in and make a whole lot of changes to the content itself. Potentially, the content model and the presentation model can even be implemented in different systems. So an example of this is the so-called Headless Drupal project, which according to Jam, we're now supposed to call de-coupled Drupal. De-coupled is a much better word. So this is the idea that Drupal is really good at storing and structuring content. A custom JavaScript thingamie... Sorry, I'm not a front-end developer. A custom JavaScript, whatever. It might be better at actually displaying that content, so we should have the ability to store our content in one place and display it in another place. And obviously, to do that, it's really, really important that we're not including presentational logic in our content model, that our content model is kind of purely about the structure of our content. And finally, the content model is what authors interface with. So when an author creates a node, for instance, in Drupal, they are presented with the fields that are part of our content model. And it's really important for authors to understand that that's what's happening. And when we tie our content too closely to one particular form of presentation, so when we act as if what authors are doing when they create a node is creating a web page that is always to be viewed on desktop. When we sort of encourage them to think that way, they tend to forget about all the other potential presentation models. So they're not going to think about how their page is going to be read by a screen reader. They're not going to think about how this blog post might appear on Facebook and so on. Karen McGrane, who's a really well-known content strategy person, has a saying that the internet is not a laser printer. But what we often do with authors is that we use metaphors that come from print, such as telling them that there we see that their CMS is just like Microsoft Word. So that's the kind of thing we're really trying to get away from as much as possible when we create a content model. Okay, so that's our first principle. We've got a content model, a presentation model, or multiple presentation models, they're different things. The second principle for me is to treat your content model as a pragmatic system, not a complete model of the world, unless you happen to be building a site that is meant to represent the whole world, like the idea, for instance. So what I mean by this is that you really need to make pragmatic decisions about how granular you get with your content, whether something needs to be a separate content type or not, whether something needs to be, whether you need to break a certain section into five different fields or two different fields. And the way that you make those decisions is not by thinking, well, what's the maximum possible level of granularity I could possibly have? Or what would be really cool to do? What's the most complex, kind of complete system I could possibly build? It's very easy to get into that way of thinking when you're actually going through the abstract process of building a content model. So what you really need to do in those situations is to go back to your user stories, your scenarios, your fundamental goals for the site. And if you're getting to a level of granularity that's not actually going to help you achieve any of those goals, then you probably don't need it. So if you can't imagine a situation where you might use a thing, it probably doesn't need to be in your content model. Example of that is I was working with a client who publishes a lot of scholarly papers with lots of bibliographical references. So when I first started working on the site, I sort of thought, wouldn't it be cool if every entry in the bibliography was an entity and we could then structure those entities so that we have all the elements sort of nicely stored and then we could create these wonderful views where you could click on a reference and see every other paper that's referred to the same thing. And I sort of had a conversation with the client. Does this sound like something you might want? And they just sort of said, no. We just need a list. So that's what they got. So it's really important to come back to Earth with these things sometimes. But there's a major caveat to that and that is that within reason, you should be thinking about future needs as well as present needs. So this goes back to the idea that you're not going to be changing your content model very often, so you do want to make it robust enough to deal with at least foreseeable future needs as long as that's not going to create too much extra effort. So here's a really good example of this. The LA Times, the Los Angeles Times, recently had a redesign where they introduced this new section to their website called Neighbourhoods. And these Neighbourhoods pages are essentially landing pages that collect a whole lot of different information about an individual neighbourhood in LA. So they've got a whole range of topics. They've got sort of statistical data. They've got news stories. They've got basically everything to do with a particular neighbourhood. Now, when this section was launched, the journalists at the LA Times had actually been adding geographical locations to their news stories for several years before the website had any use for this at all. So journalists were just told, well, when you write a story about a particular location, look up for the latitude and longitude and stick it in here. They obediently, I guess it was part of their jobs, they just obediently did it. I don't know how they were talked into it, but they did. And so the result was when the section of the website launched, it was already pre-populated with all this content because, you know, hey, Presto, we've already got all this stuff that's existed behind the scenes. And I think geographical, like, location data is a really good example of an element of content that you might want to think about adding two certain content types in anticipation of possibly needing it in the future. So I've actually done this on a couple of sites where we've had article content that's about specific locations, and I've known that this client at some point in the future has plans to have some kind of mapping functionality on their site and part of what they're probably going to want to do is show stories that belong to a particular location or a particular area. So by getting them to start putting that data in their stories right from the beginning, once they're ready to actually launch that functionality, they'll have that all ready to go. Okay, so, yeah, so don't be more granular than you can imagine ever needing to be, but do have a bit of imagination and think about, okay, what might we want to do in two years' time? So, you know, if you're building a site now and you can think of something cool, you can add to the content model that might make it better for the Apple Watch. You know, go ahead and do it. And let me know if you work out what it is. It's probably making your titles, you know, 40 characters or something like that because, I mean, just on the Apple Watch, I mean, can you imagine the horrors of truncation that are going to happen when the Apple Watch is launched? And, you know, you can't even actually flick through to see the full story. It's just going to be a nightmare, anyway. Not our problem. And the third principle really is to start testing your content model with real content as soon as you possibly can. So I'm probably teaching this as a converted here, but why would you want to test a content model with real content as opposed to just making a nice wireframe or testing it with low-remix or, you know, develop generated content or something like that? There's a few different reasons why we want to do this. The first is that it allows us to see our real content in different contexts. So one of the really important things about content modelling is that it involves treating content as data. So, you know, in that sense, it's a very similar process to traditional data modelling, but we always need to keep in mind that content isn't just data. It's also narrative. And actually taking a chunk of content out of context can sort of radically change its meaning. So... That's right. A bit of Google Maps going there. No worries. Yeah, so taking a bit of... So testing with real content lets us spot the places where our content is out of context, so it might not be making sense and we might need to make some adjustments to allow for that. It allows us to identify false assumptions. When we're building a content model, we'll always make certain assumptions about things like character count. So we'll sort of say nobody could ever possibly write a title that's longer than 80 characters or something like that. You know, the sooner we can start testing that with real titles and real articles, the sooner we'll find out that those assumptions aren't true. This is a really big one, identifying edge cases and deciding what to do about them. So content models are neat and real content is messy. There'll always be... There'll always be pieces of content that don't quite fit into your beautifully designed model. And the sooner you start testing again with real content and testing with worst case scenarios as well as best case scenarios, the sooner you're going to figure out what those edge cases are. The sooner you know what to do in response. You can adapt your content model to adapt to the edge cases. You can shoehorn your edge cases into your content model or you can decide to treat your edge cases as something else altogether and just create some kind of custom solution for them. But the sooner you know what they are, the sooner you'll be able to make those decisions. And finally, finding the gaps... Find the gaps... Sorry, testing helps us to find the gaps in our content model. We need to identify those bits where we need some kind of reference field to create a relationship between two bits of content, but we haven't actually put it in anywhere. So how do we go about testing with real content? Well, for me, there's no substitute for doing it on a real Drupal site. So what I've started doing whenever I want to test a content model is to essentially build a prototype Drupal site. At this point, you might be thinking, if you're not a Drupal person, you might be thinking, I can never build a Drupal site and I'm here to tell you that you're wrong and I'll be going on to that in a minute. Okay, so there are my three basic principles. So I now want to talk about what content modelers need to know about Drupal. What I mean by content modelers is just anybody who needs to work out the content structure for a website. So that might be somebody with the official title of content strategist. That might be someone within an organisation who has the responsibility for looking after content. So if you're working with... If you're working at how to structure content for a Drupal site and you don't know very much about Drupal, here are some things that you really need to know. This is one of the bits that we'll be very familiar to all the Drupal people. So I apologize. Drupal is totally agnostic about structure. You decide almost everything for yourself. Honestly, when you first do a Drupal installation, at least if you're using the out-of-the-box version of Drupal, you basically get almost nothing. You get a couple of really basic content types. You get a front page that looks really weird that almost everyone ends up throwing out. And that's very different from the experience of installing something like WordPress for the first time because you basically you install WordPress, you have a website that you can start using. It's a pretty simple website but you've got something that you can start using. So on the one hand that makes Drupal a bad solution for your uncle who runs a phishing tackle business who wants to launch a five-page brochure website, but it makes Drupal a great solution for organizations with complex content that really gives you a blank slate that you can do do whatever you want with. Drupal's site built as a content model is by default. And this is what I meant by the title of the talk today, the Accidental Content Strategist that one of the interesting things about Drupal is that the first thing that you're when you do any kind of training in how to build a Drupal site, one of the first things you're told is well, you need to create some content types. So in order to do that you need to decide what your content types are going to be and then within those content types you need to decide what fields you need. So just the very experience of building a Drupal site forces you into a kind of content modeling mindset. So Drupal people really have a head start in this stuff that I think people using other platforms don't necessarily have. If you're building your first Drupal site, one of the surprises might be that you'll almost certainly need contributed modules to get your content model working. So everyone's had, you know, everyone who's built their first Drupal site has had the experience of I want to put a date field in here and oh, there's no date field and in fact you need to install a module to get a date field. You need to install a module to get an address field. You need to install a module to get an entity reference field, which is one of the most basic things that you could ever want to do in a content model. So that's just part of the story with Drupal is that a lot of the really common functionality at least in Drupal 7 is provided by contributed modules. Drupal 8 things are going to get slightly different. There's a lot more in core in Drupal 8. It is one of the quirks of Drupal that we rely a lot on contributed modules for what might seem like really basic things. And then finally I had this whole spiel about entities that I ended up abandoning because it was just going to take a while. It is important for people working on a Drupal website to know the basics about the entity system. So I'm just going to go through the really top points here. So in Drupal most content lives in entities and an entity is basically a piece of information or a collection of information about a thing or an object. So a blog post would be an entity in Drupal, an event would be an entity but also a user would be an entity. So in Drupal the entity system that includes a whole lot of different kinds of information. So from a content point of view the most important kind of entity is a node. And a node is the type of entity that's sort of designed around storing content. So typically in a Drupal site 90% or more of content will live in nodes. But what's interesting about Drupal from version 7 onwards is that this entity system has been extended to all kinds of other things. So things like taxonomy terms, users, comments and much more. And that has all kinds of implications but what it means for us as content modelers is that if it's an entity you can add fields to it. So one of the crazy things about Drupal is that you can add fields not just to nodes, not just to content types but also to taxonomy terms to users and to all these different things. So that's my spill about entities. If you want to learn more about entities you can read this page on drupal.org which you'll see is a node. So it's an entity. And yeah, obviously my slides will be uploaded to the website so I don't feel like you have to write that down but I definitely encourage you to learn a bit about entities if you're going to be involved in content modeling for Drupal sites. And then the final thing that I really want people to know about Drupal is that you can build a Drupal site yourself. And this is one of the really powerful things about Drupal is that anybody can download Drupal. Anybody, and I'm speaking from experience here, anybody can learn to build a basic Drupal site. Drupal does have a learning curve that's probably steeper than other systems. But once you get over the initial hump with Drupal, it's really amazing how much power you have in your own hands. So I basically sat down last year and did a whole bunch of video training at a site called Drupalize which is run by a really well known Drupal shop in the States called Lullabot. And within a couple of weeks I was doing things like building sites where I had all these really complex views of I played around with mapping a lot and I had maps where things would appear and disappear depending on the times of events and all that kind of thing. And it was just like I'm not a developer, I don't know any PHP I've done all this just in the basic sort of interface of Drupal. So Drupal is a really powerful tool even if you just use it to prototype and test your content model. So I was talking about testing your content model earlier that the single best way to do that is just to spin up a really simple Drupal site and start building some content types sticking in some real content and playing around with it. So that's my evangelist section of the talk. Yeah, so there's options out there for where you don't even have to worry about creating a database and all that kind of thing. I think it's good to have the experience at least the first time of doing it in a local dev environment and creating a database and running the full kind of installation process as it's documented on Drupal.org but it's definitely Drupal Gardens. There's also Acquia Free Cloud basically allows you to sort of create a single click Drupal website so it really sort of speeds up the process. So yeah, there are definitely quicker options out there than sort of running through the full process. Okay so the last part of my talk I just want to talk about some of the common issues that you come across with content modelling in Drupal. So this is where I get sort of more Drupal specific I guess and the first really major issue that you still see on a lot of Drupal sites is mixing content logic with presentation logic. So when I talked at the beginning of the talk about keeping your content model and your presentation model separate, this is kind of where the rubber hits the road with that stuff. Now Drupal is inherently better at separating content from presentation than some other systems. So we do talk about nodes for instance rather than pages so we do have this concept in Drupal that a node is one thing and a page is a different thing which is kind of a good start but it's still easy for presentation logic to creep into a content model in various ways and here are some of the ways that you will often see. I'm calling these worse practices but I'm not trying to blame anybody who's done any of these things, we've done them ourselves but I really think it's important for us especially as we move towards that more sort of decoupled world to really think about making our content model a pure content model. So there's obviously the traditional one big body field approach where we basically said to authors if you want this page to be formatted differently just do it in a table hardly anybody does that anymore but it is still something you see on some sort of legacy Drupal websites. Naming content types after pages is a really common one so I mean Drupal comes with a content type called I think it's basic page or standard page I can kind of live with that because it's not really part of the content model, it's really a sort of it's what we have to deal with everything that doesn't fit into our content model but if you're creating a content type called event for an event for instance call your content type event not event page because it will train authors to think about an event as a piece of content that might exist in several different places in the website rather than as just a page. Similarly naming fields after presentational elements you still see websites with fields that are called things like right side by content so try to use labels that are that don't presuppose a particular presentation model when you're naming fields like this so you could call it something like supplementary content or even break it down into further fields. And then finally there are particular modules that I think are kind of big culprits in sort of sneaking presentational logic into entities and one example of this is modules that allow you to select a view mode from within an individual entity so a view mode is a way of displaying the information in an entity so for instance a teaser you might have a view mode called teaser and another one called full content and you can create custom view modes for all kinds of different situations and there are certain modules that allow you to actually select a view mode when you're entering the entity itself or when you're creating the entity itself and to me this is just a totally wrong headed way of thinking about things it's like you're buying a pair of pants and a t-shirt and you've got the pair of pants sewn onto your t-shirt and you can only ever wear one t-shirt with your pair of pants it's basically saying I'm going to enter my content and choose a presentation style for it at the same time so bad stuff so bean is an example of this you don't actually have to use this option within bean but it is there and there's also a display suite extra that allows you to do this within you can basically tick a box in display suite that says allow authors to select a view mode from with a node or something like that and I love display suite but I would never actually use this particular extra and the kind of even worse version of that is allowing authors to build a custom layout from within an individual entity so something like panellisa and I know people use this module a lot but panellisa is a part of the whole sort of panel system and it allows authors to essentially sort of create a sort of customised layout within an actual entity and you know once again you're really breaking down the whole idea that your content decisions you make about content are different from decisions about presentation so realistically though I know that there are reasons why people use these things and the really major one is that authors need flexibility okay so you get this pushback from clients about over structuring their content and they say oh but we want to be able to we want to be able to just arbitrarily decide what's in the right sidebar of this page or you know not have a right sidebar at all or have a left sidebar stand blah blah blah blah we need to do all these we need to be able to make our own decisions about this stuff because we're in a world where nobody is ever creating a pay or sorry creating an entity for a single presentation model we really need to get clients away from this way of thinking and what I think we need to do is basically give them some flexibility around the way they structure their content without making that flexibility live in in layout so think about ways we can give them more flexibility and not impose you know loosen up our kind of what we impose in terms of structure without imposing a layout so a good example of a module that allows this is paragraph so I don't know if anyone's ever played with paragraphs before I think there's actually another talk going on about paragraphs as we speak so I'll be listening to the recording of that one I won't say anything more about it at this stage but go and listen to that recording because paragraphs is really exciting stuff I'm sort of running out of time I'm just going to briefly touch on entity types so we have the whole because we can add fields to any kind of entity we often feel like okay anything that's about a topic I'm going to add to a taxonomy term or anything that's about a person I'm going to add to a user there's all these things that you get in nodes that you don't actually get in other entity types so there are things like published or unpublished states authors published and modified dates, revisions revisions is a huge one, you only get revisions in nodes granular permission so saying I only want this author to be able to change this content type that's something you only really get in nodes searchability out of the box so Drupal core search out of the box works with nodes it doesn't work with other stuff and also comments at the moment can only be attached to nodes although you'll be able to attach a comment to anything in Drupal 8 which will be great so just be aware if you're tempted to think that all your topical content for instance should go within a taxonomy term then it's probably not it might not be the best idea so my sort of recommendation is to store only your sort of basic unchanging information in taxonomy terms and to actually create a content type for more substantive topical content so if you have anything that you think you might want to revise and be able to revert back to an older version of all that kind of stuff or sort of have a workflow for within the organisation that really still needs to be in content types and then of course you can use a reference field to link the two so you can say this content type relates to this taxonomy term yeah sure so imagine you have a taxonomy imagine you have a vocabulary of places of place names so I say cities and obviously the main thing we use taxonomy terms for is to classify other content but we might also have some sort of static content about the term itself so say I've got a Melbourne taxonomy term which I'm using to tag articles that are about Melbourne but I also have a lot of information about Melbourne itself like its population and you know I might have a little essay about the history of Melbourne and that kind of thing I might be tempted to store that information inside the taxonomy term but because of these restrictions with taxonomy that might not be the best idea yeah does that make sense to everyone so I kind of rushed through that point because I'm running out of time but yeah we have sort of similar issues with users as well and sort of recently struck a case where we really wanted to use the user entity type of people that weren't necessarily users of the system such as authors of articles and that kind of thing really got a lot of pushback from the organisation about that and one of the issues was that when they see the word user they expect that to be somebody who actually uses the website which is probably fair enough but another issue that we hadn't thought of was that within their organisation user accounts were actually controlled by the IT department so they didn't want to have the publishing team have to ask the IT department to create a new user account every time they wanted to add an author to an article so so you can think about you can try and be as pure as you like with these entity types and use the correct ones for the correct things but there are actually intrinsic sort of limitations in Drupal that mean you can't always do that okay so I'm almost completely out of time does anyone have any burning questions yeah yeah presentation model yeah that's a good question I guess it really depends on the project but yeah ideally there is one person on the project who has the responsibility for the content model and if you have a content strategist on the project that's that person if you don't then yeah I think you do need to pick somebody whose job it is to have that kind of supervision of the content model and to be able to work out when decisions that are made about development might actually be breaking the content model or when assumptions have been made about content that don't actually work about the model that don't actually work with real content that kind of thing so I definitely think it's a good idea to have one person who sort of owns the content model on a project yeah I just have one more slide I guess about making your content model author friendly I think it's all pretty straightforward so I'm not going to go through it I'll just leave it up there for those of you who are who are interested because this is another obviously another big issue with content modeling you want your content model to be something that authors can actually use once there once you've got it in place I've used up my 45 minutes so I'll let you go if you want to go if anyone does want to stay around and ask more questions then feel free but thanks everyone I've got some recommended reading as well which will be in my slides which will be on the website