 I think we're gonna go ahead and get started. Welcome to Content Strategy for Drupal.org. I'm Courtney Clark. I work for Forum One and I was a partner in crime with my fellow friend Tatiana as we embarked on this content strategy journey. So I'll turn it over to her to get started. Hi everyone, I'm Tatiana. I work for Drupal Association. And so essentially, Drupal is kind of my full-time job, which is very exciting. And today we're talking about content strategy for Drupal.org. I want to start from a little bit of background to kind of explain to people why we're even doing this thing. So some of you might not realize, but Drupal.org is actually over 13 years old. And obviously it's visual look evolved over the years and you can see some of the steps on this journey here thanks to internet archive, which kind of saves everything. So the current design is based on the work done by Mark Bolton and Lizza Reykild back in 2008, which was a great job. It also happened more than five years ago. So time went by and the website kept growing. And at some point it became obvious that changes needed. Now Drupal.org is not a typical website. It is one of the largest and oldest continuously operating websites, Drupal websites in the world. And until recently it was primarily maintained by volunteers. There was no full-time stuff to do it. And so it just kept growing organically. The amount of content we have by now is huge. There is more than 1.2 million pieces of content, about 20, 9,000 projects, over 800,000 issues on the site. The amount of audiences we have is also pretty impressive and very diverse. All the way from project managers to writers, to designers, developers, and this list goes on and on. We have marketers, trainers, evaluators, system admins, et cetera. And all of these people also range in their skill level all the way from newcomers to masters. Now in addition to all of that, we also have lots of tools. The website is not just text on pages. And the tools we provide are quite complex and very diverse as well. In one way or another, Drupal.org provides functionality similar to that of Stack Exchange for support, GitHub and Jira for code and issue tracking systems. We can be there for kind of, we can like book pages we have on the site. Mozilla, just in terms of being a face of a huge open source project. Drupal showcase for case studies, et cetera. And all of that in one single website. So when Drupal Association stuff and Drupal.org content making group started talking about possible redesign, we kind of felt like just a simple visual refresh wouldn't do, let's change a couple of colors here and there and done that won't really work. And so what we really wanted to do, and this was the word George came up with, we wanted to reinvent the website and we wanted to reinvent it to support the following kind of objectives. We wanted it to be the home of Drupal community. We wanted it to provide learnable and efficient tools to our users. And we wanted to encourage people to develop themselves their Drupal proficiency, their carriers. So where do you start doing something huge like that? We decided to start with user research. We decided to develop content strategy next and then work on creating a visual design system which would be based on all the data we accumulate on the previous steps. So our user research happened last summer and was performed by Drupal Association staff and few community volunteers with the help of. Whitney Hess, user experience coach who is by the way and giving a keynote presentation tomorrow and you all are welcome to come. I'm sure it will look awesome. So as a result of that project, we are developed user personas for Drupal.org and I won't be talking a lot about them today but they are published if you follow that URL on the slide, you can read all information about those. So our next step after user research was content strategy which is the topic of today's presentation. For this part of the project, we partnered up with Forum One company and Courtney was leading the team from their side. Since she's here today, we can ask her the main question. What is content strategy anyway? Yeah, let's just post the notes, that's it. Good question. So content strategy as defined by Christina Halverson in this book, Content Strategy for the Web, she defines it as planning for the creation, the publication and the governance of useful and usable content. Now that's just one sentence but it's actually a really huge definition of what the head content strategy is. So for this project specifically, we sought out to uncover the content problems that Drupal.org was spacing and develop a plan of attack to uncover those and then start to solve for them and create some recommendations so that they could move forward. So we started off with an awesome kickoff in Portland at their offices, complete with voodoo donuts, thank you Holly, crowns and Google Hangouts and it made for a really great two days and we did a lot of brainstorming and a lot of chatting about again the current issues they're facing and what our next steps would look like in this project to outline them more thoroughly. So out of that, we did a couple of things that are listed here. First, we created a vision brief and that was just so our whole team could get our heads around what the heck we were trying to do on the project itself, make sure we all agreed on that. Started talking about a content audit. This wasn't completed but we were getting our heads around what that step looks like. Well, we plan to talk about content types, understanding what content types exist now and then where there are holes and gaps because the Drupal Association and others are creating a lot of great content that didn't always have a place to live and then as Tatiana will talk about later, there's some weird usage and overlap in how content types are used. Governance recommendations and governance for the web is generally like who owns what and who can edit what and because as you know, Drupal.org has grown organically over a time, it's a very complicated web or maybe too simple of a web as far as who can edit and then lastly, a site map. So figuring out what a new structure might look like to accommodate all of these new ideas that we were talking about. So this was just the framework to organize our thinking on the project. The really juicy part is what we actually learned and so Tatiana will talk about that. So what did we learn? First, we took a look at the existing content types on the site and how they've been used. We took all of them and we mapped them against kind of high level user tasks which cover everything people are trying to do on the website. And you can see this whole thing here and the first thing to notice some of the content types are used like all over the place. One of them would be book pages which are heavily used across lots of different areas. Same for forum posts, similar we can say about user groups. At the same time for some areas, you can see that there are either no adequate tools or content types at all such as like if you look on the project management, those tools aren't really project management tools. Search and discovery, for example, has nothing at all to enable people to discover content. If you look deeply into some of those overused content types, for example, books, they have been used for very different things. For general documentation, for example, understanding Drupal, installation guide, et cetera. For project specific docs, so like how to use this particular module, how to configure it, et cetera. Tutorials, so kind of step-by-step guides right now, they're mostly in tutorials and set recipes book. Community instructions, by which are mostly mean contents in getting involved guide, which are not really documentation but kind of instructions how to get involved, how to start doing something. Book pages are also used just for general information about Drupal and Drupal.org. They're used for marketing content that little bit of marketing content we have. Sometimes they're even used for managing initiatives and people try to organize work and communicate status of something using book pages, which is not really convenient at all. If you look at forum pages, again, they're used for very, very different things. Obviously, they're heavily used for support, asking questions and getting answers. But they're also used for official news and announcements which go on the front page on the side for various community posts and announcements. Not many people realize about security advisers, you can see, they're actually forum posts, which kind of makes little sense. Apart from that, there are also case studies and forums, events, discussions, general group discussions, Drupal services. There's a place where people look for vendors and help with their websites. And those last four use cases, there are actually many much better sections on the side for those things right now. So there is just duplication of content going on. If you look at user groups, there are also very, very different types. Some of them are used for announcements. So those are kind of very weird announcement only groups which you can't even join. You can just see announcements there. For example, core or governance. There are project-based groups, so groups which are used to organize work around some contributed projects or distribution where people maybe discuss roadmap, some upcoming features and things like that. Working groups and initiatives. So those are groups for official or maybe non-official Drupal-8 initiatives such as mobile, multilingual, whiskey, et cetera. Obviously one of the most popular group types are local user groups. So this is just groups of people based on location such as Portland, Italy, Spain, et cetera. The last type would be interest groups. Those are groups of people around software or non-software interests, such as usability, behead, VOPs, women and Drupal, and knitting. I hope, Holly, you are in one of those. So what we see overall is that a single content type on Drupal.org is often used for many different use cases. And those use cases actually require different field structure, different layout, different permissions and different access restrictions for those things. At the very same time, we see that a single use case is often met by multiple different content types which makes it very, very unclear, especially for newcomers and learners. So which content type is actually the right thing to use for specific use case. In addition to all of that, there are also some user needs which we uncovered during user research which currently aren't met completely by any of the content types we have right now. For example, we heard that people would like to have browsable archives of videos from Drupal events, which is nice thing to have, functional topic and taxonomy pages to just be able to find related content to something they're interested in. Browsable listings of training opportunities. Right now our training session section is just a listing of companies which provide training services, which kind of is helpful but not very helpful. Another thing would be having an actual archive of Drupal Planet posts on Drupal.org which you can actually search and filter and find something interesting for you. So when we saw all of that, our team got very, very excited obviously and we started brainstorming all the wonderful content types we can create. And the number was growing really, really fast. Now you don't actually need to have like 200 or 300 content types on your website to be able to meet different use cases for different audiences you have. And so next we looked at how our content on the site is actually organized and structured and if there is any sort of room for improvement and spoiler alert that there definitely is. And now Courtney will say more about that part. So there are a couple of big highlights. First of all, we saw that content on the site is largely organized by content type, not the persona, the newcomer, learner, master and so on or by the actual task that people want to complete. So right now for issues you need to go here. For book pages you go over here. For forums they're here and so on. But as you know people don't always think about it based on the content type. Instead they might think I wanna know what the status is of this Drupal core initiative. Well the answer might be in a meta issue, it could be in a group on groups.drupal.org, it could be on a book page or even on a custom external site. There are many content types that support that question. So what this all means is that it's super hard for people to find what they're looking for. Especially people who are new, right? Newcomers and learners. It's hard for them to know the quote right place to look for this stuff. The next problem is that a piece of content is generally only displayed in one single section on the site. So that means that we're not contextually displaying it in other places. So when you're looking for something you'll see that piece of content but you don't see anything that relates to it. Anything that's contextual that goes along with it. And as you can imagine this really hurts discoverability. It creates dead ends. It doesn't continue people's journey on the site. So it's hard for people to naturally discover other things they might not think to look up but is still very much related. It also creates a unique habit for Drupal.org users when you look for a page and Eureka you finally find it. What do you do? Well, you might memorize the URL. You might bookmark it. You might Drupal con it. And so people have these long lists of the URLs just so they can find that page again. So huge pain point. Another thing, so the primary ways of structuring content on Drupal.org are through the book hierarchy or through custom coded horizontal menus. So this has its limitations. A big portion of the content on the site is grouped into just a few top level books. And oftentimes they have a very deep hierarchy or yeah hierarchy beneath them. So we have two issues here, right? When you're structuring the content or the navigation on a page. First of all, you've got the horizontal menu along the top. Excellent. So the main problem with these horizontal menus is that they're custom coded. So that means that they tend to be inflexible and take more time to be updated. They're harder to update. The second thing is that with the book hierarchy, you get books to have so many pages that navigating within them is not particularly usable. Like as you see, I didn't even show the whole page. This is cut off. There's a lot more there. So in this example, so many pages, hard to navigate between. This is also problematic because in some cases like the getting involved guide, there's different types of content aimed at many different audiences and it's just all in one book. So there could be stuff for new learners and then there could be stuff for people who are masters of Drupal as well and it's all mixed together and the expectation is that the person has to come in and figure out what's appropriate for them. So not ideal. The last thing is that permissions, the permission structure tends to be pretty flat. So because there's no organization structure between the behind, sorry, beside the content type, the permission system is flat. So either everyone can create an edit within that content type or a group of people based on their role can do that. And so it makes it difficult if you want to assign a group like maintainers and have them be able to create and edit and then create different permissions for everyone else. It's very limited and right now, sometimes that's handled through the full HTML input filter so that you can quote, lock certain book pages from editing from every user on the site. So the big thing here is that it's a little bit of everyone or no one can edit this content type and what we saw is some of that nuance was missing. So what is this all mean? So I'm sure a lot of you found these things we just said familiar if you at least used the website for just a little bit. And so this summary of our findings can actually be boiled down to two main things. The first one is that we really need to separate content from structure. We need to use content types to create content and we need to use different means to bring structure to this content. And the second thing is that we need to actually structure content around user tasks. So instead of having five different places about the same thing or topic, each using different content type in different place on the site, you would actually have one place about this topic which has five different content types inside of it depending on what is the type of content you want to create or find. And so the following is our recommendation how to actually try and achieve this on Drupal.org. So separating content from structure. We can do this by having a set of generic content types which are very specifically used case for each one. They will be reused across the site in various sections. So you can see here proposed new content model for Drupal.org. The green boxes are the new content types which currently don't exist at all. The yellow boxes are the content types which you currently have but we might want to change them a little bit. Maybe change fields, maybe change just name of the content type. And the gray boxes are content types which you currently have and we don't even plan to touch them. They're like fine. So on the left side you can see basic content types. Those are the generic ones which will be used for actual content creation and the idea is that it's pretty clear if you want to create static content you use page. If you want to create something dynamic and have a discussion or comments you use post. If you want to publish an event you use event obviously, it's own. Now if you look to the right you will see group content types. Those content types won't be used to create new content but they will be used to actually bring structure. So you see all different kinds of groups. Some of them already exist. So for example, local user groups obviously some of them are new or they might exist now but they aren't actually groups. So the first example of that would be projects as groups. And this is not a new idea. It has been discussed in the issue queues for five years or so but turning projects into groups actually gives maintainers much better tools to organize work around their projects. So they will be able to create different types of content inside of the project such as posts or documentation which is specific to this project. They might be able to announce events if you have a sprint around this project specifically. And another advantage here is that other people will be able to either join or follow the group and they will actually receive notifications when something new is created which is kind of sounds awesome, isn't it? Another example of existing content type which we actually want to turn into a group is organization. Right now those are just static pages of text and if we turn them into organization we'll give companies much better tools to manage their presence on the site. Again, they potentially will be able to create the following content types inside of organization so post, case study, page, maybe video. What this also helps with is they will be actually able to control who lists themselves as staff members of this company because right now essentially anyone can say they work in any company or group of the talk and there's nothing you can do about it. So here we'll have a set of permissions where the list of staff members is actually up to date and those are the people who really work in the company. The next example of potential group content type is initiative and this is something completely new. We don't have anything like this on the site right now and the idea behind this content type is to provide project management tools for people on the site. Enable them to manage big initiatives and big projects. Sometimes they span across multiple country projects or maybe it's a big initiative for Drupal core. So you can see here some of the potential content types which will be available inside of the initiative so post, page, event, video. But the interesting part is that you will be able to relate things like projects and issues to the initiative and the relationship will go both ways. So you can say this initiative is related to multiple projects or single project can be related to multiple initiatives such as Drupal core. They have lots of initiatives going on and what this would allow you to do is actually pull out this project and pull out issues and then use various displays to show here's the actual work around this initiative. Here are the issues which are currently in work. Here are the issues which are priority and should be worked on next because right now the only thing you could do is like use issue tags and then it's a list of issues which doesn't really help you much to communicate this type of thing around your initiative. So those were some examples of new generic and group content types. Now our second recommendation was to structure all content on the site around user activity and again we'll switch and Courtney will talk more about this. So looking at this, we wanted to organize the content on Drupal.org into sections around high level user tasks. So combining a list of the major areas of user activity that we've mentioned earlier and the current Drupal.org site map and various other parts of the site that exists now that gives us the following potential sections. So each section will have a purpose and an audience defined. So each section has a primary owner or maybe multiple owners and a series of roles for the users whether they can create and edit content within that section. Sometimes it will be that all users can create and edit content within that section. So these sections will make up the top level of Drupal.org, the site map itself. They'll obviously have subsections below them and a hierarchy within that but we're anticipating this would accommodate all the content and the activity happening. So essentially every piece of content on the site will live in one of these sections. The only thing that's not shown here are things like terms of service, privacy policy, your like standard footer links. So I'll talk through a couple of these just to give you a sense of what's inside. So this first one, why Drupal is a good starting place for those who are trying to figure out if Drupal's right for them as the title implies. So this will house those technical marketing materials. It don't have a really great home right now. High quality case studies will live there. The official Drupal blog will be in there. Right now there's not a good place for Drupal.org marketing content. There's one place where there's, but it's using book pages so it's not necessarily beautiful or engaging. And if there's a place to be beautiful engaging, it's in why Drupal. So the vision of this is for it to be more well crafted than it currently is right now. Another example is news and events. So there's a huge need right now on Drupal.org to have a central place for happenings. A single place where people can go to understand what the latest is. So the goal of this section is to have that place and have that unified voice. So right now news on different topics may be in many different places. And if you don't know about that place you might miss the latest news. So this section will have an aggregate of news content all over the site. So if there's a blog on why Drupal or a blog about governance or a blog on community pages it'll aggregate up here. So it's that place you know you can always count on. One other example is community. So it is exactly what it sounds like. It's a central place for people to find and talk to others within the Drupal community. So the list of all the users will be there. The list of organizations will be there. It's important to note that within community this will include local and user groups which are currently over on groups.drupal.org. So this is a central place for conversation and community. Okay, one more example is contribute. So this highlights the ways obviously someone can contribute. It should be an easy starting place. Initiatives that Tatiana just spoke about will live here. Currently parts of this are living in the getting involved guide. And so the idea here is taking that content and displaying it in a much more engaging way, right? This is a call to action. We want people to figure out how to contribute easily and to get excited about that. Also it should be easy for people with different skill levels to know how it's appropriate for them to contribute or what's the best way. So I'll hand it back to Tatiana to talk about how this may be implemented. So behind the scenes, this might sound scary to some people but those sections actually could be organic groups. And this will enable all those structure and permissions around the content. It's worth noting that they will not look exactly like groups on group.drupal.org right now. So don't be scared. In most cases for end users they won't even realize that some part of the site is actually a group unless we want them to and we want to display, be joined button and make people join the group. Building these sections as groups actually gives us a lot of kind of exciting possibilities. First of all, obviously we'll be able to create various different types of content inside of a group versus like right now if you use book hierarchy, you can only use book pages inside of it. Built in permission system will actually enable the concept of maintainers. So each section would have a maintainer or maintainers and a set of user roles for different types of users who can create content or edit content inside of the group. And this doesn't mean we won't, we will lock everything out. If we want, you know, for documentation we want it to be open and any user should be able to edit it, we can do it using organic groups as easily. But another advantage is that once we have maintainers we actually can have notifications when someone changed something in your section you will actually know about it and you can go and check it out and maybe correct it if needed, which is kind of helpful. And another possibility is that it will be actually easy to add single page of content into different sections. Right now it's very hard to do in book hierarchy, kind of very tricky. But here, for example, if you have official Drupal block in wide Drupal section which is about look new Drupal 8 came out and it's so cool, you only need to create this piece of content in this one section and it will automatically take it and display it in news and events, for example, in that central place of all news. This type of thing, kind of easy to do with groups, at least much easier than the current setup. So, obviously, all of those things we talked about today is a huge change for the site. It's a lot of work and it can't be just done in two weeks. Just flip a switch and it's ready. So, we can do it. Now we have stuff team which can actually do it but it will take some time and we'll have to do it step by step. So, what are some of our next steps? First of all, everything we talked about today is already published on Drupal.org. This URL here is the main top level meta issue and all of the things we talked about today are child issues below it. So, if you wanna read about this some more and maybe comment and give us your feedback, you can go to child issues of this one and do it. So, for the next few weeks, we'll be just kind of collecting feedback and seeing what community members even think about this whole idea. Our next step would be to create next set of issues, kind of more detailed, an issue per section or an issue per new content type so we could discuss things like, so what actual fields will this new content type have? What actual content will be inside this section? And the next step would be to select a section and actually start building it and testing to see if our ideas will actually work for people. Most likely we will start with contribute section because initiatives are something people really wanted to have for a long time to be able to manage the work we do. Potentially, we could also do something a little bit easier such as why Drupal and I only say easier because that section won't have projects and fancy gate tools. It will be mostly marketing content which needs to be pretty but not too complicated technically. So there is that possibility. We haven't made a selection yet so let us know in your feedback where do you think we should start. Now, if anyone still remembers the beginning of the session, the content strategy was step two of this larger project of Reinventing Drupal.org. So for that bigger project, our next step is visual design system and RFP for it will be out in next two to three weeks probably so you should make sure to watch Drupal's association blog or Twitter account. It will be announced once it's out. If you know really great design agencies which you want to help us redesign website, please let them know about this thing and suggest them to apply for it. Now I want to take a quick moment and just give thanks to a few people who kind of help us along this journey which is already about one year. Going first of all this Drupal.org content working group members who all of them are here today which is kind of awesome. There is George, there is Jeff and there is Roy over here. They were real, real big help especially right in those RFPs and kind of doing strategic planning of how we can actually do this whole big thing. Of course our staff people, especially Markham team none of them is here now but they were really, really helping us especially and Liz who spent hours taking notes during user research interviews which was like a lot of typing and kind of what fun. And also I want to say thanks to all other working groups and staff members and community members who already saw parts of this in different forms and gave us early feedback. That was really helpful. What we have next is just various links and resources for people who want to know more about this. Lastly, thank you. Now we would love to answer some questions. Okay, so the governance plan, yeah we did some work on it and essentially we have a huge list of problems we need to fix. We're just kind of not excited like you need to make this more clear and that more clear. A little bit later we came up with this idea for sections. So essentially our new governance plan is that governance will be built around section of the site which makes it kind of easier but we didn't really do any work around this because this needs to be discussed with particular community members who will be using or maintaining specific sections so we didn't want to make any decisions for them but the idea is that the governance will be based not around content types like right now but around sections on the site. We also have a mic there. Well, first of all, thank you. It was actually, yeah, I really like it. It's a really nice proposal. It seems to be a much more kind of contained information architecture which is really nice. Yeah, we have a lot of problems around that. I'm wondering kind of the ideas around kind of how you intend to kind of test or validate basically what you're creating here actually aligns with what users are thinking in terms of getting to the content that they're looking for. Because if I see the plans right now you have kind of the proposed new structure but usually when you're thinking about task success the actual navigation and then the structure they kind of go hand in hand. So how do you expect to kind of validate what people get to the content that they're looking for and that there's still room to change the sections in case that doesn't align? I really want to get to the point where we do actual user testing while building things. So building quick prototypes and showing them to users and seeing if that's actually working or not and some of the things you and I talked about yesterday we can actually write down some of the ideal scenarios of people doing specific thing and getting to specific information and then essentially like measuring before and after. Is it faster or is it not really helping much? I think we also can do some just quantitative stuff. Look at numbers we have in Google Analytics and see for example how deep people go inside of the site. Right now a lot of them just land on the one page and they don't even go on like other pages deeper they don't explore so if that will get better obviously we're doing something great if bounce rates will be smaller we're doing a good thing. I also feel like our user research probably won't be the last one it's not like once done and forget about it we'll repeat it after some time and I hope we'll hear that people can actually find things and the things we hear will be different from what we heard before. So that's kind of hope that answers the one. Yeah the only thing that I would add is that before we began we were very thorough at reviewing the personas that are built on a lot of really great interviews that were done and so a lot of questions came out of that characteristics of the different user types and so along the way it was helpful to have that in hand and check in with the personas to make sure it still felt right. So when I was talking through the new proposed sections Tatiana actually has a whole nother slide deck that talks about each of those sections and who exactly it addresses. So we're trying to be diligent about remembering not only the existing audiences but the new audiences that we're trying to draw and get engaged. So I think it helps to continue to do that as well. Good question though. Yeah along those lines I think one of the things that we haven't had a chance on the content working group to really dig into much yet but is sort of on the agenda. I believe we still have an optimal workshop account that we can use for large scale user testing of things like here's a tree of items. Where would you look to find X? And just do very simple quantitative tests of a sample group of 200D.O users when given four different pieces of information that people commonly look for on Drupal.org how many of them were able to find it without taking wrong paths down there. There's a couple of those tools that we do have at our disposal but I think as a couple of the next steps in actually fleshing out the hierarchy get to the we know where things would be now let's test them in bulk. I think that's a couple of the things that are sort of a little bit down the line but we definitely wanna make sure some of that stuff happens too. So I'm increasingly convinced that Jeff and I are actually the same person because I was just about to mention tree testing. So aside from that one of the things that I ended up taking on at the extended sprints was that getting involved guide and the community section which is sad a little bit and makes me cry. And so one of the things I think I'm hearing is that we want to essentially split the getting involved guide by sort of task and essentially take some of that content and move it into community and some of it into contribute. Is that, am I correct in that? Am I okay? All right, I just wanna make sure. Definitely displayed in a better way so it's not just giant list of book pages which I am not convinced anyone actually read that stuff or if there was any person who actually read like all of it, like page by page I don't think those people exist. Yeah, well, I mean I actually did that but not because I wanted to just to see what's there. There's also a huge opportunity in prioritizing the content better. So right now it's just so much. So like you said, you read through it but because you had to. And so if we're trying to attract newcomers we have to remember that we need to pull up and highlight the key things they need to know first off and hope that they're dedicated enough to even get through those top three ones. I just wanted to say real quick how much work Tatiana has put into this project. She didn't put herself on the slides but she's been a huge, huge winch pin to the entire project over its entire lifespan. So everybody who loves Drupal.org give her a big hand. If no more questions, thank you so much. I hope it was interesting.