 Okay everybody, it looks like it's time to start. It is 2.15 and this presentation is called Why Drupal is Not a Word Processor. So we'll go through the agenda and the introduction for the presentation. First off, today I will introduce myself and the company that I work for. Then I'm gonna talk about why this topic matters, why it is important to view Drupal as a content management system, rather than a word processor. Then I'm gonna talk about the reasons why we need to approach content entry and editorial work separately. And I'll illustrate this argument through a client that we worked with, SWOG, the Southwest Oncology Group. And finally, we'll go through some takeaways and conclusions because we don't wanna go through a full case study without you guys being able to take some nuggets of wisdom or something like it back to your institutions. So my name is Caroline Roberts. I work for iFactory, where we combine method and imagination. We're from Boston, these guys in front also. Work for iFactory and they are front end, back end Drupal developers and our head of development. We have been serving higher ed in particular since 1992. So we were also involved with the higher ed summit, if any of you guys were in that on Monday. And we work with community colleges, state colleges, and a range of institutions, including nonprofit ones. So we're pretty well versed in dealing with large amounts of content, both database content and editorial and marketing content that institutions often use to convey their message, to encourage students to join or people to donate. And at iFactory, I'm Caroline. I've done 30 plus content inventories, 20 plus content planners slash maps and 15 plus site launches. So I've had a lot of experience with getting content ready for a migration and migration seems to be a pretty hot button issue here at Drupal and I'm hoping that this conversation will at least bring up a discussion about how to make that process a little bit easier. I was wondering how many of you guys here are from the marketing and editorial side? All right, got a few, got a few in the middle. And what about development? All right, excellent. So we're gonna get multiple perspectives here, I hope, by the end of the conversation. So why this topic matters? If you have ever been in the position of trying to put content and write content into Drupal, writing fresh, brand new marketing copy or site copy, you're using a sledgehammer instead of a screwdriver. Drupal is a hardcore, useful, wonderful tool but it is not quite right for editing and writing. It also means that if you are an editor or a writer and you have been asked to start writing content directly into your CMS, whether it's Drupal or WordPress, it means your team might be waiting too long in order to get started with the process. And this means that you're going to be entering content and editing that content at the same time. So say if you've reached the manual migration stage of your site migration, if you've gotten to that point and somebody says, hey, we need to touch up the marketing messages on this page or restructure this content in order to fit the new design and you're doing that at the same time that you're moving content from one CMS to another, you've got a lot on your plate. And I like to call this a health hazard. It's really stressful because you're not just moving content from one CMS to another but you're also rearchitecting it in order for it to fit. How many of you guys have been through that, that type of migration? Yep, it's pretty drastic, right? You feel like an octopus, you've got everything there, everything's spread out on paper, on post-its. It's crazy, right? It's a health hazard. So what we're talking about today is ways to relieve that stress. So what if we admitted that Drupal is not a word processor? Drupal does a lot, but we said it doesn't do that. And what if we split the editorial process from content entry, separate the two or decouple as seems to be the turn of phrase. So why separate editorial from content entry? Reason number one, what they call the copy and paste switcheroo. So you're working for an understaffed school or a nonprofit. And then somebody asks you in the midst of a site migration as you build the shiny new website on Drupal or any other CMS to forklift, as Lullabot has said in an article, or just copy and paste content from your old CMS into your new Drupal CMS. You'd probably freak out, right? Because your sites are huge. And somebody says, just copy and paste these, I don't know, 1,000 pages or 100 pages? That's a lot of work. That's the type of thing that you can't, yeah, you're nodding with you. You can't do that. Somebody said to me once, hey, can't you guys just do that automatically? And I think I made a hissing noise on the conference call just because that's not true. That's not real. You can't do that. And you can't just copy and paste something from one CMS to another, especially if you're overhauling the design. You're gonna have to rewrite things. You're gonna have to tighten things up and move things around so that aligns with the new images that you put in. Anyway, I get very passionate about this subject when anybody says, let's just copy and paste that. So that's reason number one, to separate editorial from content entry. Reason number two, surprises are inside and it's not like the Crackerjack box. So you are working for an understaffed institution, either higher ed or non-profit. You are managing the schedule. You are soothing stakeholders who are concerned about change, fundraisers, faculty members. You are adding and updating the copy and you're also expected to upload images, attach downloads to individual pages, add URL redirects and any metadata that goes with images and downloads. So many of the sessions here are about accessibility, right? So you have to make sure you've got all text. You have to make sure that you've got captions for your images. You have to make sure that your PDFs are accessible. It's way more than just copying and pasting. It's way more than editing and crafting your marketing message so that way the content on your site looks good and is readable and makes users want to come back. And a lot of people just forget that aspect of it in a migration, especially once you reach the manual phase of the migration. So you're dealing with these four things and possibly even more than that once you start getting under the hood and looking at your content. My wifi had a moment, okay. We'll just go with this for now and then when I get my wifi back, I'll go back to the presentation. But reason number three to separate editorial from content entry is training. So if you who are developers, how many of you guys here have trained content editors? Yeah, so when you're training content editors or faculty members or administrators or PR professionals for nonprofits and you're training them, you want them to be focused. You want them to come in with their heads in the game. And if they're thinking about how they're gonna be writing the content and improving the message to encourage people to apply or donate, their heads aren't gonna be in the game. So they'll be more focused if they've been thinking about their editorial ahead of time and if they've done some writing, they can start working with real content that they can migrate into the system. If they're working with real content and if they've already managed to put some time and care into that content, then your training is more likely to stick. I know whenever I've been through a CMS training and I've been the one to write user guides as a content strategist and a manager, I've found that it's way easier to use examples of what they're expecting to put in than anything old. You show the old page and they'll just lose it because they're focused elsewhere and that's not the real content that they're going to be working with. So if you can get them where they're in the mood to have their head in the game, they'll ask you fewer questions and as the trainer, that would be really useful to you because you can focus on the real issues and the development. So I wanna talk about SWOG, the Southwest Oncology Group. This is the case study that I'm bringing in to illustrate how we approached this issue with the client. And I wanna tell you a little bit about SWOG which that's what the name they go by, they actually abbreviated it. So it's very catchy and we're fond of saying it at iFactory. Sometimes we'll say we're getting swaggy or something like that, getting swaggy about things and these guys are really busy. They are the poster children for the type of client that I am talking about. They're saving lives. They run a clinical trial database that connects cancer patients to trials for drugs that will improve their quality of life and possibly even save their lives. So these are really busy people. The people that we were working with include physicians who are working on the trials, clinical research associates, my internet connection is back, advocates who represent current patients and then our main point of contact, the person who was writing all of the messaging around the site to encourage donations, she was managing all of the PR and she freely admitted that she was not a database professional. She was not even an online writer. Her background was more in journalism and public relations. So we were working with people who were not particularly web savvy. And then everybody else on their team had tons of work to do besides writing brand new content and manually migrating content. They were putting together a conference for researchers and writing for the fundraising arm of the group. And then we had iFactory's team. And we're dedicated to the cause. We had a bunch of staff on this because we believed in the project and it was a really exciting one. UX designers, visual designers and producers, developers, these guys right here, working on bringing together all of the complex clinical trial databases. And if any of you guys have seen a clinical trial, you know you're working with tons of really complex data. And then me, I served as a consultant for SWAG's team essentially, helping to train them in terms of improving the content that they were putting on their website and also training them to prepare their content for migration. Basically, a lot of what I did as a strategist was set up the plan ahead of time to try to make their lives as easy as possible because they're saving lives. We wanna give them as much time as we can to do that. So this is SWAG's old site, 12 years. You can only imagine what is under here. Now let me stress, these guys do amazing work. Once you log in and you get access to that data, it's pretty incredible. But they had let this site marinate for 12 years. They started sticking pieces together, different types of databases. My running gag was it was built with tin cans and twine. So when it was time to bring everything together, they picked us and they picked Drupal, though good choice. And now we have this. Yes, he's very peaceful, soothing presence. And so it's far more elegant. Everything is easier to find. This is our redesign. It took a lot of back-end work and content restructuring to go from this to this. We had to revise the storytelling of the site on top of rearchitecting all of the databases and improving the clinical trial interface. So when you come to the site, we wanted to improve the messaging. When you arrived at that homepage, you got this. You're like, I don't even really know what these guys do. They lead cancer research, but there's buttons. There's tons of text. There's tons of logos. It's quite confusing. And now here, it's about the people. It's about the people doing the work and the lives that they're saving. Basically, on top of the migration, on top of the migration, the team had to focus on changing its entire approach to the marketing message and the writing and the content that they needed to create. They had to create all new content from scratch. So we needed them to get started as early as possible. So that way, we could focus in the development phase on getting all of the databases together to improve the clinical trial search results while letting the team do their thing and improve the content that led to the meat of the site, the heart of the site, which was the clinical trial search. So our first step in helping people get their content ready so that way we can avoid using Drupal as a word processor and get going on the editorial ahead of time was to do a content inventory. And you've probably heard a lot about content inventories and content audits, but that's the first step, is evaluating the content that you have so you know how much work you're gonna have to do. Because if anybody says to you, hey, we're just gonna copy and paste the content as is from the old CMS to the new CMS, run, hide, ask questions. You need to dig in, look under the hood and see how much work you're gonna have to do. And with these guys, they'd accumulated content over 12 years. So they had a lot to go through. So what we did was we worked with them on their content inventory. And then we had to determine how to share that information with these people who were not web savvy. In a way that helped them take action and figure out exactly what they needed to do and create a plan for updating all of this content. We guided them through the process of helping them determine what to keep as is, which wasn't much, what to revise and what to archive, and then also what to create. This beautiful slide is an example of the content inventory that we do. And you'll see with that yellow column right there, which the internet is trying to connect, but the yellow column basically assigns responsibility to individuals for each page of content. And then they determine what they wanna do with that content. And you can't see at the moment, but you could see there's a lot of keep, delete, revise, and they could get a rough estimate of how much work they were going to have to do on their content before it was time to migrate. Once the client knew what they wanted to keep, revise, or archive, we had the site map ready. And that was our time to do the content mapping or what we call the content planner. And the content planner gives us the opportunity to take their existing content and map it to the new site map. So that way we knew, Westie Simnotting, we knew where the content was coming from and we were creating a bunch of new, brand new content. So by realigning the site map and talking about what we needed to revise and what we needed to keep, we also exposed gaps for the client. So that way they could say, oh, okay, we need to write these brand new stories, the swag stories that I showed earlier. We need to write brand new content or a landing page for patient advocates. And by doing this content planning ahead of time, they knew they had to write, say, 15 to 20 brand new pages of content. They could start preparing their resources for that. Or they could set up somebody to start editing the content. And that took pressure off the editorial team so they could focus on the site's message. And this is an example of the content planner. So right now what we've got on the left-hand side is the new site map path. And then as you move towards the right, that's how we are aligning the content to the site map. So everything has its right place and then anything here that's marked as new is content that's the client's responsibility to write. We do this ahead of time so you don't have any nasty surprises where as you're moving content into the new CMS, you don't have that freak out moment of where's this content coming from, who's gonna write it, who's gonna bring it to me. So once we go through the content inventory and the content planning process, I like to think of that as looking at the content at the macro level. We've got the broad overview, the bird's eye view, kind of like the site map. And now once we've done that broad overview work, we can approach the content at the page by page level. And this is where we use a tool called gather content. Have any of you guys used this tool? Okay, I've heard mixed reviews of gather content. It's the tool that we use because it lets editors get started on their content before the CMS is built. So a developer can start working on the CMS and the editors can get going with their content planning, particularly for the new and revised content well before they even get near the CMS. Gather content also has a plugin that allows for a CMS integration into Drupal that automates migration, and we've used it here at iFactory. The results, meh, some skeptical faces there, but the results are better than a lot of copying and pasting and the nice thing is that gather content has some really useful workflow features for editors. So editors can set up a workflow in which they can create their own page statuses for draft, revise, approval, and they can adjust it any way they want. We've worked with people who've used gather content and sometimes they'll even use a person's name as a status. We had one client, Rutgers Newark, and they had a status called approval by bill. So bill, every page of the site had to go through bill, but you know what? Gather content allowed them to create that status to make sure that bill put his stamp on those pages and he did. So it's a really nice interface for editors. It may not be perfect in terms of migration into Drupal, but if the editors can get their work done ahead of time, they'll be better prepared to do their work and get the content into Drupal without having to edit it at the same time. And this is really, really effective for the new content that you're working with. I have talked to people actually at this conference about when is it appropriate to use gather content and what type of site content you should use with it. And I think that it all depends on how much content you're moving. There's never one size fits all. Sometimes if you are starting your site from scratch, I'd recommend using gather content for the whole thing, but if you're starting a brand new website, like we didn't put the clinical trial pages in here. That would be crazy. All of that lived in a database. That content was not changing, but anything that was new marketing content like the SWOG stories, any fundraising content, any help information that involves the clinical trials database. All that was new, Gesundheit. So all that was new and all that is the type of stuff that goes into gather content. If you're moving news items or news archives that haven't changed at all and you know they're not gonna change and their templates aren't gonna change, you can leave them out, right? You can migrate that in and I'm not gonna, the words lift and shift I cringe at, but you can migrate them in as is if they're not changing, but anything that's new or revised, that's worthy of gather content. And that is material that you want the editors to have ready before they start working within Drupal. So as part of this, we talk about workflow and I know that developers have a different approach to workflow from editors and writers and we talked about this a little bit within our own group when I did a dress rehearsal for this talk, that there's workflow within Drupal, but editors also have their own workflow and the two aren't necessarily going to align, but since gather content has its own workflow features, we helped our main contact, the woman who worked on PR, determine a workflow and a content plan. So we sat down with her and talked about the steps of who needed to approve what, who was responsible for adding content, when these tasks needed to be completed, the who, what, when, where, why and how, all of that gets baked into the statuses. It's not just, hey, draft, revise, publish, it's actually more complicated than that because you need to determine who's gonna be writing the draft, when is it due, who needs to approve it, who's responsible for the photography, that's something people always forget, or who's responsible for adding the alt tags and the page uploads, we could go through and walk her through that process and then she could use gather content to make those assignments. This slide is not pretty, but keep in mind, we're working with someone in PR, so we sat down with her and created a Google doc that she could use and share with people within her organization to let them know Wendy's gonna do this by July 17th. These guys are gonna do this by July 24th. Wendy's gonna write all the copy by July 31 and I'll be sharing these slides because this is not the ideal view, but that is how it worked and we sat down with her and having that word doc and having her be able to set up the gather content statuses based on the doc really meant a lot and helped ease her mind so she could get her work done. And in the end, she was pretty happy with the process. She said, we cut out clutter, bushwhacking a lot of content, she has a way with words, better ordering the content we have and presenting it in an intuitive way to both members and the public. This is perhaps the genius of the site. It works for everyone. So by giving them the chance to streamline and look at the content from the macro view and then the page level view, they were able to get everything ready to create the best site possible while being able to continue the really important work that they were doing. And I feel like setting up the strategy ahead of time, helped them accomplish that and helped us accomplish that and create a great site. So what are the conclusions and takeaways that you can get out of this case study? What can you bring back to your own institutions? First off, you don't have to use gather content. There are people use various systems, but anything that can separate editorial work from content entry, so you're not treating Drupal like a word processor will help you in the long run. It will speed up your content creation and migration because you know how you're switching from one task to another, if you're switching from one task to another, you're just less efficient. I mean, multitasking, I joke, I can only do three things at the same time and then after that it's a mess and you may not be able to do two things at the same time, but if you can focus on one thing and do it well, you can focus on your editorial, do it well, then you can focus on your content entry and do it well. So when you do your content QA, you don't have a bunch of missing PDFs, you don't have somebody coming back to you from the accessibility department saying, oh, you know, you missed all those alt tags, you can stay focused on those tasks. And then particularly in the case of SWOG, I don't know what clients you work with, but SWOG, they had a core product, if you will, which was the clinical trial database. That's the heart of the site and it helps you balance what's functional, the clinical trial database, what people are really coming for and then what inspires and motivates because you can't just have the, if you build it, they'll come mentality, particularly with cancer clinical trials because people have a hard time finding those and so you want to have something that inspires and motivates so you can encourage people to keep doing that work. And also we work a lot in higher ed. So what is functional is people signing up for classes, people applying, but also you want to inspire them to apply, right? And say choose this institution as opposed to the university down the road. So keeping the two separate, keeping it functional, inspiring and motivating. That will improve the quality of the content on your website. So the better editorial, the better imagery you have, the better design, the better that your new content aligns with the new design, the higher quality it will be. I mean, an iFactory, we believe in high quality content. We can't always get it all the time, it depends on the client, but if you have high quality content, it improves the user experience, thereby improving the outcome of whatever it is you want to do. You're inspiring people to use your product or sign up for your service. And then you can bring writers and editors into the design process earlier, give them access to tools like gather content and do your homework. Gather content might not be the right tool for you. It works for us because of all of the statuses. It's pretty affordable and it's got the Drupal plugin, but you might have other systems that work. And then manage your content so that way people are working on the content before they access the CMS. We like to talk about the 80-20 rule. Usually about 20% of your content will change drastically or it will be completely rewritten. That tends to be the breakdown, whatever your organization is. So get people working on that 20%. If you're scheduling, if you're doing any project management, anything like that, get people ready to work on that 20%. And then finally, and that's why the developers are here, this helps you maintain open channels of communication between editorial and development teams because you need those open channels of communication. Usually it will be development or a trainer or someone who is more technical, training a person who is non-technical. It might be an administrator in an English department. It might be a fundraiser for a cancer fighting institute. You don't know who you're going to be training, but you need to have that dialogue so people can communicate their needs and say, this is what I expect to be doing with the site every day. This is what I need to focus on in my training. Can you help me? Keeping a silo between editorial and development is a recipe for trouble, particularly in maintenance because down the road, you know what happens, you launch your site and then somebody uploads something that doesn't work or they upload images that are too high res and slow the page down and then you get bad analytics results. So the better you can train people, the better off you'll be in maintenance. And I think we've got some time for Q&A. I can also go back to slides because I was reconnecting the whole time. Yes. Yeah. Yes, I can talk specifically. So she had asked what snafus arose when we used the Drupal API? And one thing that I can speak to, and then I'm gonna toss the ball to Larry who is our director of development and who can definitely answer these things, is a lot of the problem is garbage in and garbage out. Like if you've worked with metadata or a library or anything, you sometimes people will take content that they've written in a Word doc and paste it directly into gather content and that creates a bunch of garbage code that doesn't render properly on a page. So in the Q&A phase, you're dealing with like curly cues, things like that and weird HTML characters that might come in from Microsoft Word. I have encountered that. I don't know if you guys would like to answer. Yeah, that's a nice feature. And the gather content templates, they encourage content modeling, which I know has come up in conversation so you can think about that content model ahead of time. And then you can add help text within gather content that can push the editors along, set character limits. It's nice. Oh, did you have a question? Oh boy. Rightly so, I've been there. You can use the paste as text function. People forget that. We've actually talked about this in your system of adding help text and I believe Eileen Webb in her talk yesterday referenced authoring experience and putting help text by text fields. So if you could talk to your developers and possibly implement help text in that field saying do not paste from Word or even putting in a requirement or a help message saying are you sure you didn't paste this from Word? Anything that can eliminate the human factor because people are in a hurry. People have their preferred tools. Some people you will pry word out of their cold dead hands. It's just, but if you can remove the human factor from it, that'll help. There's also a tool that I use and it looks like my internet connection is back. It is called Edit Pad. Oh, come on. But it is basically a link that is called Edit Pad. You type it in editpad.com and all it is is plain text. It's actually this little yellow thing there. It's ugly and if you paste the word into Edit Pad it just cleans it up and then you paste it back into the text or what I used to do before I did Edit Pad was I'd have a text edit or a notepad open so I would take the word content that somebody would give me and I would just paste it in there and that would clean it and then you have to reformat it with the header. So if it's a very complex, this site can't be reached. Oh, okay. So if it's a very complex document you may need to reformat it but it will remove a lot of the garbage. Yes. Yeah. So you're reaching out to another authoritative set of documents. It's not you saying that what they gave you is good for that. It's not personal. You're not saying you did it wrong, bad dog or anything like that. We ran it through the validator so you're not gonna get what you wanted in the time that you expected it. Like I really like that's a great approach because you're educating them at the same time. Yeah, well that's a great, I might take that as a takeaway myself. Yeah. Yes. No, that is a fantastic question and it's a thing that I would like to gather content to improve is the ability to tag because right now they have upload fields where you can attach attachment fields, you can attach an image, you can attach a PDF. Sorry, there's a reminder saying please repeat questions so he asked about taxonomy and tagging within gather content. And gather content doesn't have a tagging feature where you can enter in the tags or a dropdown list. I regularly send them notes of improvements that I would like for them to make and that would be one of them because tagging is so key for dynamic sites and if you were writing a bunch of content ahead of time like student stories or SWOG patient profiles and you wanted to tag them to appear on certain pages that would be ideal. Otherwise, what we do is we use a separate CSV. Yeah. I recommend that they write to where it's going to go. We give the client a func spec. I work closely with UX and information architects. We give them a func spec so that way they have an idea of what the content types are and they can write towards them. And as Larry said, you can set up the templates so that way they know what fields they're going to be working on. And then if there's a duplicate, if there's, because there will be a lag time between say adding a new news item or making it an update to the existing site and then you're working in gather content you don't want to override that. I recommend keeping a change log which is complex but it'll be like, oh, okay, on the homepage we updated this story or we added this particular SWOG story. Keep a change log with that date. And that's an additional burden on the editor but it's one of those things that can save you a lot of trouble if say you've got that month long lag time, a lot of changes can happen on a site from then, particularly in something like higher ed. So if it's static content then you're making a change to put it in the log. Yes, well, she just mentioned using virtual source save as like a way to check in and check out errors and you guys, what is offered? Yeah, but another question, yes. Oh, right, sorry. That is such a good question. I think that it depends on their comfort level, really. Like it could be possibly something baked into the workflow of saying we're gonna stick with this process and then it'll be transitioned to Drupal or pasted into Drupal because at some point somebody's gotta learn to do the content entry and put the content entry in. If that turns out to be a separate role, like if that's a webmaster role and I know you don't hear the term webmaster a lot anymore, I'd like to bring it back. I think it'd be great because having somebody actually manage that content, Larry's laughing, but I'm like, bring back the webmaster role because you have somebody who would actually be focused on that and doing those changes and then the editorial team can focus on its work which is considerable. It's not just streaming words together. So in my ideal universe, I think that'd be a great idea. Keep them and gather content and then you have a status that says upload to Drupal and then you let the webmaster know and put the content in and they're managing that content from there on out. It's also such a clean system. I mean, it goes back to authoring experience, right? Where gather contents are pretty good authoring experience and the runway for training is really short. Whenever I'm training clients on how to use gather content and we train people who aren't always that web savvy. It takes about an hour. They figure it out pretty quickly. We'll do a little bit of back and forth but they take to that faster than they take to Drupal so they can get going. And then sometimes you'll get some static if I don't have time for that or I need my word docs and you're like, okay, okay, but just give this a try and they really like it maybe because they can change the colors of the statuses. I don't know, but it's really, it's very clear and easy and you can also give them, if your content modeling, you can give them fewer as I call them slots, you give them fewer fields to work with so they're not overwhelmed by all the fields that are required in Drupal that you have to have. But in gather content, you could streamline that to be title, subtitle, whatnot and a few fields for image upload. Then they can focus on that and they're not, yeah. Any other questions? Okay, so thank you. Thank you for all these suggestions. I'm gonna be taking things away like the HTML validator and what was the name of the versioning tool? Thanks for the patience with the internet connection. Okay, so it's a part of something that doesn't matter. It doesn't matter, I have a tool that's made out of software. Hi. We can use it for the website too. If somebody is inspired by a piece, that should try to come up with it. Yeah. I think it's what I'm looking for. Oh, yeah, we use it. Oh, yeah, we use it. Oh, yeah, we use it. I have done an accent with that one. I think that's a good idea. Well, we use it to do all of that. Unfortunately, it's not that bad. I don't know how to put it in the picture. Sure, I'm not gonna have to say that. We need to do it. So, this is your normal page, right? I think that would be good. But we need to have all of that. We're just gonna see what we can do to know what to add to the list. So, I think we're gonna have to do that. So, we're gonna have to do that. But we've got to do it. So, we're gonna keep going for the list right now. So, we're gonna have to do that. And you're all very simply gonna get a card. I actually need to see what it's about. I love you. I'm gonna get a personal card. Yeah, I mean, that's not crazy, but... That's not crazy. You're gonna have to write down what it's about. Yeah, give them the card you got. If you already have a card. Yeah. Build the things you can do with the sites. Yeah. Yeah.