 I feel a little bit silly giving a formal presentation to a group of this size, so what I'll do is I'll just run through the slides. Please feel free to interrupt me with questions as we go, and we'll also be taking questions at the end. You'll see there's two people's names on the title there. I'm Angus Gordon. This is Ricky Boko. This is very much a collaborative presentation in terms of what it comes out of. It comes out of our work together, but Ricky isn't so much into the public speaking stuff, so I'm basically going to be doing the presentation, but Ricky will be available to take questions at the end. So just a little bit about us. We both work for Weave Web Communications in Melbourne. Weave is a small web agency in Melbourne. There's basically five of us, and we do a lot of typical things that web agencies do in terms of designing and developing websites, but we've also always had a very strong emphasis on content. That probably started out more as content writing or copywriting, so that was just a service that we used to offer to our clients. If you need a website, then we can write the content for you as well. But I guess as our clients got bigger and we started dealing with larger, more complex organisations, we started to realise that just offering to write content for them wasn't really enough, and that what they really needed was help producing better, more effective web content themselves, and that's really where content strategy came into things. So content strategy, which as I'm sure you all know, has been a bit of a buzzword in the web industry for the last few years, has really become an important part of what we do. Our clients range from pretty small clients, a lot of e-commerce kind of startups, to fairly large, not-for-profit organisations, and about 90% of the websites we build are in Drupal, so we're very much a Drupal-based business. My role in the agency, I now call myself a content strategist, but my background is in writing and editing and the humanities. I'm not a techie at all. I'm not going to be, if you have techie sort of development questions, Ricky's going to be the person to answer them. Ricky is our developer. Ricky actually comes from a visual design background, but over the years she has more or less taught herself Drupal, so she's now our Drupal guru. So this talk is about how content strategists can work together with developers to create better websites. So it really comes out of, I guess, what's changed in content over the last few years, what's changed in the web over the last few years. When, you know, content, you might not think that content and development have a lot to do with each other, but when we start talking about things like structured content, things like reusing content or building content APIs, then content people and development people really need to start talking to each other because they are going to have a really fundamental impact on each other's jobs and on the ability of websites to really do what we want them to do. Just a bit of a caveat about those terms, content strategists and developers. When I'm talking about content strategists, I don't necessarily mean people who have the job title of content strategist because there aren't really that many of them yet. I'm really talking about people who work with content as part of their jobs and who think about web content from a strategic point of view and their job title could be copywriter, could be technical writer, web editor, there could be internal people within organisations who have responsibility for web content. So really anybody who spends a lot of their life working with content, a lot of what I say from a content strategy point of view will hopefully apply to them. Similarly with developers, I'm not necessarily talking about hardcore programmers. I'm talking about people who make websites. So in the case of Drupal, it's people who know their way around a Drupal installation and can add modules and configure things and that kind of thing. So you might call them, in your organisation they might be called an architect or a site builder or an integrator or something like that but that's what I'm talking about when I talk about developers. So can I just get a bit of a sense in the room, how many people here have dealing with web content as a really important part of their jobs? Right, half of this and how many people, and you can put up your hand twice, how many people would consider themselves to be developers or people who are involved in the technical aspects of making web content? No, Jeff. And Jeff's our perfect case here of somebody who does both. So he might be able to give us some insight about how the two parts of his brain communicate with each other. Great. So it's over about half and half which is interesting. So the perspective this comes from is obviously from people who work together in a small agency but the points I'm going to make are fairly general. Really going to be talking about principles, more than concrete suggestions. So hopefully at least some of what I say will give you some ideas. Okay. Now I am going to just briefly at the start give a bit of an introduction to content strategy. I realize a lot of you will already know this stuff backwards. So I will be brief but just for those of you who aren't really familiar with the field of content strategy, probably the most famous definition of what content strategy is comes from Christina Halvison. This was from a book called Content Strategy for the Web which has kind of become more or less the bible of content strategy. And Christina writes that content strategy plans for the creation, publication and governance of useful, usable content. So I'm just going to go through that definition and pick out some of the important words. So content strategy plans, really what content strategy is fundamentally about is saying content is as important to a successful website as design or functionality. Therefore we should be as careful and as rigorous about planning for content as we are about planning for those other things. Content shouldn't just be something that we ask the client for at the last minute. It plans for the creation of content. So it's about how content gets from people's heads to some kind of readable form. It plans for the publication of content. So how does content get from its whatever form it's written in sort of onto the website. And it plans for the governance of content. So governance is really about who makes decisions within an organization about content and what happens to content once it's on the website. When does it get reviewed? When does it get deleted? Or does it just stay there forever? Okay, so creation, publication and governance. And we're talking about useful and usable content. So I guess if content strategy has a philosophy it's that content should always serve a purpose. And most fundamentally it should serve a purpose for the user. It should be helping the user to complete a task or giving the user some information that they need. And then finally this word content. It's easy to assume that when we're talking about web content we're talking about words. And because a lot of content strategies come from a sort of an editorial background or a writing background in real life that's often the case. But really we should be thinking about content as everything on a website that carries informational meaning. So that obviously can be words but it can also be pictures. It can be video. It can be audio. Okay, now when we give that definition of content strategy it just sounds really kind of pythalutent and really impressive where we're just sitting around planning for how to just create awesome web content. And it's called content strategy which sounds like something that's very sort of high level. In practice what content strategists do day to day, at least if I'm anything to go by, isn't as glamorous as all that. We tend to spend a lot of time sifting through massive spreadsheets doing things like content audits and essentially sort of wrangling content, working out who owns which piece of content, what needs to be changed, what needs to be deleted, chasing up content that's late, all that kind of thing. So don't be mislead by the word strategy. Content strategy is as much about really content tactics as it is about strategy in the sort of pythalutent sense of the word. Okay, so I just want to talk about some of the problems that content strategy can solve. So why would somebody either engage a content strategist or embark on a content strategy process for their website? And this is from a website owner's point of view. Okay, our old website content is a mess. We don't want that to happen again. Content strategy really commonly comes out of a bad experience in the past with web content. Look, I'm actually not sure. I just found the picture. I believe it is though, yeah. So people, yeah, people, yeah, especially big organizations and you've all seen them, they end up with these websites that are just a hodgepodge of content. You can't find anything, half of the content's out of date. You know, their tone voice is completely inconsistent. You end up having to ring them because you can't find what you need on the website. So that's a really common kind of problem that people recognize, you know, organizations aren't stupid. They recognize they have these problems and it's one of the drivers for them to start on a content strategy process. Another one that's becoming increasingly common, we need to create one piece of content that works in several different places. So this is, you know, I'm not going to talk too much about this because Jeff Eaton's already covered it pretty thoroughly in his talk today, but one of the main drivers for content strategy is the recognition that our old legacy website content doesn't adapt well to a multi-device world where we've got desktop sites, we've got iPad apps, mobile websites, you know, services like Instapaper, and then we've got, you know, the future with content appearing in our cars and on our fridges and on our TVs and all the rest of it. So when organizations realize they need to get their content out to different places, that can be a really common driver for the starting on content strategy. Another really big one, we need our content to be smart and this is one that's very relevant to developers as well. If an organization wants to build something that uses their content in an intelligent way, like a comparison tool or a calculator or anything that really treats content as data, they need to have that content in a form that, you know, allows them to do that in a sort of machine readable, intelligent, consistent format. And so content strategy process can be about getting content from a big blob of undifferentiated text into an intelligent kind of structure that can then be manipulated in smart ways. Okay. Another really common one, we hate our CMS, okay. This is one called the Ectron CMS 300. I don't know if anyone's ever used that. But, you know, we, it's obviously a horrible looking interface, but we recognize that, and we've already talked today about how Drupal's not exempt from this either. And yeah, yeah. I'm just, yeah, I'm just looking at that brilliant tool bar. And of course, anybody, anybody who uses this CMS would have been instructed that they're not allowed to use at least two thirds of the buttons on that tool, especially the one for changing your font. No, never touch this. So, yeah, so bad, you know, a bad author experience is a really common reason why websites have bad, end up with bad content or with content that never gets updated. And one of the things, you know, we've heard about some of the improvements that are going to come in Drupal 8. And if you're at one of the talks this morning, you know, some of those improvements are already available via modules in Drupal 7, which is fantastic. But, you know, content strategy also has a role to play in improving the author experience because you can't really improve the author experience until you really understand the problems that authors have. So a content strategist can be or less liaison between the authors and the developers, somebody who learns a lot about what the day-to-day life of a CMS author is like. And you can then ensure that the developers are solving real problems rather than solving problems that may not actually exist. Okay. And then finally, I've got a big list of things. So, and just to remind you, we're going through reasons why content strategy or sort of problems that content strategy can solve for organizations. So we need content that reads like it was written by a human being for human beings. But it also has to reflect our brand and convince people to buy our stuff and help them use our website and be accessible to people using assistive devices and be optimized for search engines. So organizations tend to have a huge big list of conflicting priorities for their content. And one of the roles of a content strategist is to sort of sift very calmly through those priorities and work out how to balance them rather than letting the marketing department, you know, just make the decision that everything's got to be about SEO and that we're going to, or that we're going to just plaster huge pop-ups over everything and so on and so forth. So it's about recognizing content has to serve a number of different roles and working out the best way to balance those roles. Okay. And then some common problems that content strategy can solve for people who make websites. So there are actually problems that developers come across that content strategy can help with as well. We hate copying and pasting from Word documents. Okay. There's absolutely no reason why we should still be in this day and age have a content creation workflow where people create content in the least web-friendly format possible. So one of the things content strategy does is work on workflow, how content gets created, what form it gets kind of handed over and migrated in. We could do much more with this content if it was better structured. So if you have an ambition to create the awesome dashboard of amazingness, but you need better structured sort of content and data to do that, a content strategist can help to actually extract that from your content authors. There's a big one, content delays are holding up our projects. Put your hand up if this is a problem you've ever encountered. Yeah. So most, pretty much everybody who's ever built a website will have this problem where you've got this beautiful website all ready to launch. The only problem is it's all filled with loremitsum text and you're waiting on the client to deliver the content. So by thinking about content right from the beginning, content strategy really, really helps you to avoid that problem. And then finally, we want to be able to show this site off, not just now, but in six months time. So we, you know, you hear a lot in this industry. You often hear the sentence, you know, this client ruined our website. We can't enter this for an award because the client just stuck up all this horrible content in the wrong places and it just looks like shit. Well, you know, that's not necessarily the client's fault. The problem is we design websites almost as a static sort of object that is launched on a specific day and we don't think about what's going to happen the day after. We don't think about how the content is going to need to change and grow and how some of it's going to need to be deleted as the client business changes. So that's one of the things that's really important that, you know, content strategy really, really can help you. It's just an example of a site that we built about four years ago that's still kind of, looks okay if I say so myself. Okay. So that's my sort of whistle stop tour of content strategy. I now want to talk about some examples where you can really see a fruitful collaboration between content strategists and developers or people who build websites. The first two are going to be big kind of famous examples. The third one is going to be a smaller, a more small scale example. So the first website I want to talk about is gov.uk. Are people familiar with this website? Yeah, yeah, a few nods. Yeah. Gov.uk, I think this is probably the second most amazing website in the world after Wikipedia, just from a content point of view. If you don't know, if you haven't looked at the site, what it basically is is a site that within the UK replaces every single public facing government website. So if you want to get any kind of government related information in the UK, there's now one website for you to go to, unlike, you know, for example Australia where if you want tax information, you go to the ATO. If you want benefits information, you go to Centrelink and so on and so forth. Everything's on one website. Now it's a very impressive website from a sort of design and development point of view. It's very minimal because it's about information. It is very text-centric but it's very beautifully laid out. There's a very clear information hierarchy so you can really see that thought about user needs because on virtually any page you land on you'll see that the most prominent information is the information that somebody's most likely to want. It's responsive obviously and we've heard about this sort of from Jeff, the mobile only users. So it's important the government website these days needs to work on mobile devices. It's very fast loading, you know, obviously handles a very vast amount of data but it does it without, you know, behind the scenes very sort of quietly and from the user's point of view it just works. But sort of at least as impressive as the design and development of the site is the content on the site. What GOV.UK has done is basically taken every piece of information from every other government website and rewritten it in plain English in a consistent sort of voice and tone and in a well-structured kind of way so that, you know, things like related pieces of content can be displayed. So it's just a massive, you know, this is why I say it's one of the most amazing websites in the world because if you've ever worked on a government project you can just imagine the endless meetings that must have happened, the endless approval processes that must have happened to get all this content through. But imagine if they'd rolled out this very impressive design and they decided it's too hard to change all this content, we're just going to roll it out with legacy content from the existing government websites. To illustrate what I mean, here's a comparison between a very similar page from GOV.UK and one from the Australian Tax Office. They're both pages about taxes on company cars and you can see that essentially, you know, you would have had to cut out, find ways of cutting out a lot of content from that ATO page to get it onto the GOV.UK site. But really the point I want to make about these pages is that, you know, people often, people often talk as if that's an easy process that, you know, you should cut your content by half and then cut it by half again as if that's an easy thing to do. And it's true that sometimes there's kind of bureaucratic language and throat clearing and all those kinds of things that you can cut out. But sometimes it's actually about making hard decisions about information you're going to leave out. So for instance, on that ATO page, there's one section that talks about the definition of a car. So, you know, obviously this is very important if you know you're driving something with four wheels home from work but you're not sure if it's a car. Maybe, you know, maybe it's for people who drive ice cream vans, I don't know. And then there's another section that's about a special rule for emergency service cars. Okay, so people who drive their fire engines or their police cars home from work. Now that information isn't totally, it's relevant to somebody. You know, you could easily construct a user-first owner of the person who drives an ice cream truck home from work and needs to know the definition of a car. But in creating that the gov.uk content, somebody's actually made the decision. No, look, these are really edge cases. We don't, having this much content on the site, useful as it may be to somebody is distracting from the overall, you know, it's so irrelevant to the majority of users that, you know, we can pretty much assume that most of our users know if what they're driving is a car or not. So those are sort of hard decisions and content strategy, a content strategy process or content strategists can really help to make those decisions. Okay, so that's gov.uk. Go and check it out if you haven't already. The second side I want to talk about might be a bit of a surprise and that's Facebook. I want to talk about Facebook because I was surprised myself when I learned that Facebook actually has a team of content strategists. I think they have about eight of them at last count. And when I heard that I thought, well, that's, you know, what do they actually do? Because Facebook is all about user-generated content and nobody's giving me a strategy for my status updates. So what exactly would a content strategist do at Facebook? It turns out that what they do is that they actually work on the content that frames the user-generated content on Facebook. So I've just got an excerpt from an interview with one of the Facebook content strategists, a lady called Tiffany Jones Brown. I'll just read that out because it might be a bit hard for you to see. So for example, whenever we create a new feature like music, we spend a lot of time perfecting the stories that are produced when you use it. We have to ask ourselves things like this. When someone opts into your music product and listens to a song, do we publish a story about it? If so, what kind? And how is the story written? Is it Tiffany Jones Brown listened to an album? Tiffany Jones Brown listened to the Earth on an audio? Tiffany Jones Brown listened to Bess Petain by the Earth on audio? Which of these pieces of data are linked? Where do the links go? Where does this story appear? What happens when somebody likes the story? Can they comment on it? Can they share it? Do I get notified about that? If I'm listening on RDO and my friend doesn't have RDO, how can they listen to? And these are all content strategy questions about framing and dealing with user-generated content. And just to, I mean, that might sound like a lot of fairly trivial decisions about, you know, just about words, but in fact, words matter very, very deeply on Facebook, on the kinds of interactions that people have on Facebook. So just to give you an example, you probably remember a few years ago when these sort of business pages were first introduced on Facebook, the action that a user could take to indicate that they liked the page was actually to become a fan. If you want to remember that, you used to be a fan of American Express or whoever, you know, Julie Gillard or whoever. And for various reasons, a couple of years into these pages existing, Facebook made the decision, and that was a content strategy decision, to change that phrasing to just the word like. So now you don't become a fan of a page, you just like the page. And in fact, we did some work recently for an organisation that is a partner of Facebook. And as part of that, we were given very strict instructions by Facebook that we're not even allowed to use the word fan anymore. You'd say, it's a voting word at Facebook. Everything has to be about like. And one of the things that allows Facebook to do is to actually make state, you know, when you like something, when you like a page, it actually gives Facebook the power to publish the fact that you like that page. And like is such an innocuous little verb that there's actually a kind of a slippage that takes place where Facebook just makes these statements that you like something. And it almost basically becomes an implied endorsement of that product or that company. So just an example here is one of my friends who has liked the American Express page. I now see an ad on Facebook saying this person likes American Express Australia. It's almost as if they're voluntarily endorsing that page. Now I personally think this is completely evil. But nobody ever said content strategy couldn't be used for evil. So it's just an example of how words, you know, these little changes in words actually allow Facebook to roll out this kind of, you know, nefarious but very clever functionality. Okay. The final example I want to give is just our own website. And I'm just giving this example because it's a very small site. In a lot of ways, a very modest site. We don't have an app. We don't have a, you know, we don't have an API or anything like that. But the content strategy still played into the process of us building this site when we sort of redesigned our site a couple of years ago. What we did was we sat down and we thought about the various types of content that we need to produce as a web agency. So things like descriptions of services, case studies, portfolio pieces and so on and so forth. And we really did a bit of a content modeling exercise where we thought about the structure of each of those pieces, how they, and how we could actually make the process of creating new content easier. So that because, you know, one of the challenges that we had that I'm sure lots of you are familiar with is keeping the site up to date, you know, all our portfolio pieces of the process we did two years ago, that kind of thing. So how do we make this easier? And what we did was we basically came up with a structure using content types in Drupal that basically just said, here's some very simple elements that we need for every portfolio piece. Here's a checkbox that you can, a series of checkboxes that you can tick to say which projects are sort of related to this one. Here's a bit of a taxonomy about services. Bang, we can publish the piece. It's all very simple. And because we've written some rules about how it's kind of structured, it's very consistent in terms of the way it appears on the site and the way it's, so it makes life easier for the designers as well. So that's just a very small example, but I just wanted to give a smaller example because it can often seem like the only example that people give of content strategy is these massive websites, but some level content strategy is definitely applicable to any size of the site. Okay, so this talks about collaboration. So I guess that for the final section of the talk, I just want to go through some of the things that content strategists would like from my point of view from developers and then some of the things that developers would like from content strategists or content people. So here are some of the things that I believe content strategists would like to say to developers. And we're talking about Drupal developers specifically. So talk to us about how Drupal can help us create well structured reusable content. Now, there are certainly some people in the content strategy community who are very, very up on CMSs and who already know all this stuff backwards. But people like me who've come out more from a sort of humanity background and a writing and editing background. Often what just won't be aware of what's available in the CMS. So one of the things that you can do if you're working with content people is just sit down with them and talk about, look, in Drupal we have these things called content types. We can create whatever fields we like. So you know, you don't have to, your content doesn't have to conform to a certain structure. We can create new structures for your content. Or we have these things called taxonomies which allow us to classify content. Et cetera, et cetera. And then obviously you can talk about all the modules, all the kinds of things we've heard about today about how we can make content authors lives here. So my first piece of, my first sort of request to developers is to, if you're working with content people, talk to them about the capabilities of Drupal as a CMS. The second thing I want to say is to understand that one of our roles as content people is to be an advocate for users. And that includes both end users and CMS admins. So I often feel as if I'm just constantly bringing up usability problems with Ricky. And poor Ricky probably feels like she's playing whack-a-mole with me. But, and I guess the thing that's important for developers to understand is that we're not doing that to be annoying. We're doing that because we really do try to see everything from the user's point of view. Third thing I want to say is if you can see an easier or cheaper way of doing something, say so. So I know that I tend to hand over to Ricky these enormously complex diagrams and Ricky will come back to me and say, look, you've got four content types here, they could actually all be combined into one and it would be much simpler. So don't assume that because we make, you know, we hand something over to you, you can't improve on what we've suggested. And then finally tell us where we're dreaming. So if you've been to not only Jeff's talk today, but almost any talk about content strategy within the last year or so, you will have heard reference made to this model, which is the National Public Radio cope system, which is the content API that's essentially been built by National Public Radio in the US. It's called cope, which is short for create once published everywhere. And the reason this keeps coming up in content strategy talks is because it's an absolutely awesome example of how structured content can allow an organization to be incredibly flexible in the way it publishes its content. So this is a system that allows one piece of content to be sort of sliced and diced and reused across a vast array of websites, apps, platforms and so on and so forth. So if you're a developer and you work with content people, you're likely at some stage to hear your content person say, I want one of those. Build me an API. And it's really, I think one of your roles as a developer is to say calm down. This is a $10,000 project for a local florist. They don't necessarily need this. On the other hand, there are some tools in Drupal that we can use to do, I guess, less complex versions of this. One of the things that I guess is Ricky's role in our repeat is one of Ricky's roles in our organization is to work out what's actually possible within the budgetary constraints of a project. Whereas as a content person, I tend to just dream up really big ideas and just expect them to happen. So that's one thing that developers, I guess, need to be prepared to do when you have wide-eyed content people coming to you with a request. Okay. And then finally for developers, I've got a bit of homework. A couple of books to read. They're both published by a book apart and they're actually both available as a set and they're very short, so you can probably read them both in a day. The first one's Erin Cassane's The Elements of Content Strategy, which is just a very good primer on what content strategy is and what content strategists do. And the second one is Karen McGrane's Content Strategy for Mobile, which is a really good read for all kinds of situations and it's not just relevant to mobile. It's really about how the mobile revolution has changed the way we think about content. Second thing I'm going to suggest, and not just because Jeff is here, is to subscribe to Jeff Eaton's podcast, Insert Content Here. I actually think it's sort of the best content strategy podcast that's out there and obviously for the Drupal people, it's particularly relevant because it's coming from someone from within the Drupal community and you could also give our blog a look from time to time and yeah, more people read it. We might be inspired to actually update it a bit more often. So yeah, that's what I'd suggest for developers who want to know a bit more about content strategy. Okay, so now I'm going to put the shoe on the other foot and talk about what developers would like from content people or from content strategists. Obviously, I'm not a developer, so I'm relying a lot on what Ricky's sort of said to me over the years and those of you who are developers will probably have things to add as well. But here are a few suggestions. So give us clear, well-labeled and consistent documentation. So if you want us to build something, you need to be pretty specific about what you want. One of the things that was a bit of a breakthrough for me with documentation was that it has to be clear, but it doesn't necessarily have to be written in developer ease or in highly technical language. It's absolutely fine to hand over a piece of documentation that just states in plain language what you want a system to do or a website to do. It doesn't have to be written in some of the streus kind of developer friendly language and it's probably better if you're not an expert in that kind of language. So just a couple of examples. That's a bit of a content model sketch and a wireframe and I guess the point with those is that the labelling is sort of very consistent throughout and I've made sure that everything's very sort of clear. Okay, embracing enforced constraints. This is really one of my favourite pieces of advice for writers and for content people in general. There's nothing wrong with giving writers constraints. Shakespeare managed to write about 150 odd sonnets, each of which was exactly 14 lines, along with 10 syllables per line, with a stress on every second syllable. So constraints aren't bad for writers. They can actually help produce better writing. One of my favourite examples for the web is to make your page summaries or your teasers 155 characters. I find that 155 characters is almost the perfect link for writing a single sentence summary of a page that conveys the main idea of the page without any fluff or unnecessary content. The other thing that's great about 155 characters is that you can then reuse that summary as a meta description and you'll find that Google will publish it without locating it. So yeah, 155 characters. Obviously, if you wanted to use it as a tweet as well, you could make that 140. But yeah, those kinds of constraints, I don't think we should be scared to really enforce them with our content authors. So yeah, constraints and obviously constraints avoid the horrors of truncated content. So if I have one mission in life, it's to rid the web of dot dot dot at the end of a piece of content. This is just a site that we're actually redesigning for a client. But the designer of this has decided, okay, we're going to have this little space for testimonials. We're going to ask the client for testimonials. The client provides testimonials that are about, you know, 500 words long each. Oh, okay, well, they're not going to fit in that space. So we're just going to truncate them. It's an absolutely horrible solution. So by enforcing constraints, by saying, by all means, have your long testimony on a separate page, but we also need a version that's this long to fit in this space, you avoid that problem. Okay, fine. And just to remind, we're talking about things that developers would like to tell content people. Understand that your big ideas aren't as easy for us to implement as they are for you to dream up. Just because we say we want the magic dashboard of awesomeness doesn't necessarily mean it's going to happen overnight. Ideas take time to implement. And finally, help the client supply content in an HTML friendly format. And Microsoft Word is not an HTML friendly format. Now, there are a number of tools out there that are helping people to do this. Has anybody else used gather content? Yeah, we really like it. It's a relatively new, it's a web app, or a software as a service kind of system, similar to something like Basecamp, but it's actually for collecting web content. It's relatively new. So they're still lining out some bugs, but we found it really useful. It allows you to obviously structure, it's almost like a mini, mini little CMS that allows you to structure a project as the website will be structured. And what's really great about it is it also allows you to structure individual pieces of content. So individual pages. So you don't have to, you're not asking for just, you're not just giving people a big blank box where they put the body of the content you're actually asking, you can ask them for each individual component that you want for each page. And the other thing that's great about it is that it produces, if you hit the source button, it will spit out really nice, well-marked HTML. They're also working apparently on an integration with Drupal, which will allow you to migrate directly from the other content to Drupal. So I'd recommend that you check that one out. But yeah, the most important thing is to encourage your content, your content people to try to introduce workflow where content doesn't arrive in Microsoft Word, because that's just nasty. And there's no reason why we should be still be doing that. Okay, and a bit of homework for content people. Learn HTML. I think if you're writing content for the web, and these days that pretty much means if you're writing content, you really should be learning at least the basics of HTML. I'm probably preaching to the choir here, but it's amazing how many content authors are still scared to hit that new source button in the CMS. And really with HTML being the way that, or the principles of HTML and the principles of markup, are really the way that all content is going to be structured, even the EPUB format for eBooks is based on HTML. And the more, so the reason why I say this is that a content, somebody who's updating the content on a website, should at least be able to go in and fix a display, a problem with a link or something like that that can't be fixed in the WYSIWYG editor. They should at least be able to look at a piece of markup and understand what it means. And they should understand the relationship between things like headings as a tag and what a heading means, sort of semantically, but then what a heading, how a heading sort of appears on a page. So I would, if I had my way, I would force all writers to learn HTML. To me, it's as fundamental as knowing how to type. And then once you've done that, I think a bit of basic CSS helps as well. That just helps, and I'm not saying writers should be constructing vast complex style sheets, but you should at least know how CSS works, and you should be able to understand how a style sheet changes the way that elements that are marked up in a certain way will appear on a page. And I've just listed Code Academy there. That's just a site where in a fairly fun way, you can do sort of free tutorials on things like HTML and CSS and more advanced kinds of coding as well. So if you have any content authors in your life who would like to learn HTML, and you don't want to teach them yourself, just direct them to Code Academy. And the second thing that I think, sorry, the last thing that I think content people should be doing is learning more about their CMSs. I mean, obviously, this is something that we're all already doing by being at this conference, but we're moving into a world where content and technology are sort of moving closer together. And the more we understand about what each other does, the better the results are going to be. So just to finish with, these might be kind of motherhood statements, but I've just got a few sort of keys, things that we've sort of found a key to working together successfully. Start talking to each other early in the project. That's a really, really important one. Obviously, that's going to depend on how the project's actually set up in the first place. But if you possibly can, get the content person and the developer sort of talking to at least have a conversation early in the project about what kinds of things you might want to do with content on the site so that you can actually plan with more sort of knowledge. Learn about each other's jobs and obviously educate each other about your jobs. That's pretty obvious and we've already talked about that. Don't be territorial. So I think content modelling is a good example of this. When developers hear about content modelling, I think it would be easier for developers to think, well, that's something I already do. I already do all this configuration of content types in Drupal. So why do I need a content person to come in and do my job for me? Really the point about content modelling is that it isn't who does it, it's that it gets done at all. And if the content person can actually help you to understand how the user is going to be sort of using the content on the website, then it's ultimately going to help you when you come to do that sort of configuration. So try not to take things personally when people do things that you might see as sort of part of your job. And then finally be evangelists for each other. So I think especially when you're working within an agency it's really important to understand enough about what each other does that you don't undermine each other's point of view when you're talking to clients. So yeah, so that's pretty much what I've got for today. So thank you very much for coming. Small crowd but a good crowd. And yeah, Ricky, we're actually going to switch mics so that Ricky can take questions as well. So we'd like to hear if you have any questions but also hear about collaboration and anything that you've found has worked for you. It's a very good question. It is something, sorry, I'll repeat the question. As an agency do our clients come to us already with the idea that they need help with their content or is it something that we have to sell them on? It's a bit of both. There are certainly people who approach us because of our expertise with content. We pretty much won't write a proposal for a client that doesn't include at least some work on content even if it's just working on a positioning statement or working on key messages for the site or something like that. And really I guess we have a workflow where content is a key part, part of it whether it's us that's working on the content or the client. So we don't start designed without at least some sort of content in place. And I guess clients will often realize when you have that kind of process in place, clients will often realize that they need help with content even if they didn't initially think they did. But it's, I won't lie, it's a struggle for us to sell content services as much as it is for anyone else I think. That depends. Ideally, yes, we would have an ongoing, sorry, I will repeat the question. Once we've launched the site do we then leave it to the client to keep it updated and to make changes or do we I guess proactively remind them or review the site. We certainly, I guess like most web agencies we always try to sell clients on an ongoing support package and if we've done content work with them that would always include that kind of content review. Realistically we have sites where clients just don't want to make that ongoing commitment and they, we're not perfect, we have as many sites as anyone else where the clients just left the site to sort of lie fallow. But we definitely make an effort to encourage the client to think of content as an ongoing process. Absolutely. Ashley, can I give you the mic so you can repeat that? So it's a comment rather than a question. Just talking about content strategy and the way that the subtleties of these things can happen. If you click on the link that says in a relationship between two people on Facebook it will take you to a page that is automatically created by Facebook for every piece of content that those two people have written about each other or tagged each other in or written to each other on each other's walls. So that somewhere along the line someone you know and I think it's somewhere in the last year that became a link instead of just a word and that's the kind of thing that a content strategist at Facebook would have been working on of saying how can we improve that? I also find that kind of creepy and stalkerish but you know. Yeah I almost I almost feel like we need to call what Facebook does black hat content strategy or something because a lot of it is pretty pretty pretty creepy but anyone got a question for Ricky? I want to make Ricky answer a question. I haven't looked at any of them no. Sorry the question was do I rate any of the content audit modules and no I haven't because Angus does the content audit. I don't do that. We've worked together for four years started yeah well I can say that since I've learned more about content strategy through Angus I've been able to make certain decisions in a build on my own and they've sort of sped up my process and met Angus's approval as well so it helps yeah. So the question was what busy we get it would we recommend for someone that likes using Microsoft Word. We use CK editor and we find that pasting in I mean I always tell them to paste it in select it all and hit the eraser just in case and then that seems to work fine for people pasting in from Word yeah. We probably I guess we probably haven't worked with projects that have such a massive amount of content migration from Word that it would be I might start that sentence again. Most of our projects are small to medium sized enough that it's actually realistic to tell a client that if you if you had to write your content in Word just paste it in as plain text and do the formatting in the CMS. So we probably don't have a good answer to that about you know if there's a way of actually automating the process but as I said I'd much rather encourage people to write you know to use something other than Word to write their content in the first place. That's a very interesting question no we don't we don't have a luxury of doing one you know it'd be great if we had the luxury of doing one project at a time. We're always doing multiple projects at a time and I guess we you know we've got one content strategy we've also only got one developer so if anything it's even more of a I guess that's something where yeah yeah I guess that's something where we're still we're still growing as a business and we we manage as best we can but we can certainly see a time in the not too distant future where we're going to need to do a lot more bringing in about side resources. Yeah yeah sorry for the person at the back the question was about you probably gathered the question was about how we managed to do lots of things at once yeah further recording sorry okay well um yeah thanks I had fun um so thanks thanks very much for coming and I'd love to catch up with you all down the track okay.