 Okay, I think I'll get started, it's right on 1045. So I hope you're all in the right place. This session is for the love of the content editors and my name is Pamela Barone. Just a quick introduction of myself. I work for a Drupal shop that's based in Sydney and we're called Previous Next. I've been doing Drupal for about two and a half years and I'm currently working as a client services manager. We do a lot of government media, nonprofit, higher education websites and I am also a former content editor. So it's not really a conflict of interest. That's not the specific reason that I'm interested in this topic. But now having done both, so having been a content editor and now as a project manager, I think it gives me some insight into the value that this can provide. So the concept here is that you can build better websites and get better results by paying a little bit of attention to usability issues. So I'll start by explaining why I think this is true and then I'll go through some specific ways that I've found that we can achieve this. And just a quick disclaimer. I'm not gonna talk about major UX improvements and complex editorial workflows. There's so much complicated stuff you can do in Drupal around usability. But my intention is to get you to start really small and start paying attention to little things that you can build into your process without really adding too much to the budget. So the idea is to start with a foundation and start with a few best practices and strategies that get you toward a baseline of usability that you can then extend with the complicated stuff. But if you're here to learn about complex UX and editorial improvements, then you're in the wrong session. So just thought I'd let you know. So the idea is, yeah, just to get you thinking about these things and then working out little ways that you can find on your projects to improve it as well. And I think it's important first to just talk about who content editors are. I think there's often a wall between project teams and editorial teams. So most of our developers absolutely never come in contact with content editors. They don't talk to them. The client lead doesn't talk about them. So nobody really asks. And as a result, we don't know very much about them. And there's no real answer here who are these people. They range on a very wide spectrum from very non-technical to extremely technical. And oftentimes, these two types of people will be working on the same team. So you can't really nail it down, but I think that concept of you're catering to a really wide range of people is really important. And the other point to make is that it also ranges in use. So some people are using the system maybe once a month. They have 10 other jobs, and one thing they do is update the website once a month. And then you have people that work in it six hours, eight hours a day nonstop. That is their job, is to work on the website. And another important thing about even those people is even the people that work in it all day, some of these people are writing their own content. Some of these people are getting emailed content in 15 different formats from 15 different people. So there's no real cookie cutter model that you can say, yeah, this would suit all of them because they range so widely. And it doesn't really matter which end of the scale they're on. If you apply some simple principles, you can make their experience a lot better. So that's who they are, but why are you here? Why are we talking about this? Quick cautionary tale, when I worked as a content editor, I think I used probably about five different CMSs in about four years. And every time we had a new one, our boss would go off and spend a year building it. And I don't know what he was doing over all these meetings. And someone would come in one day and just say, OK, you're going to be trained now in your CMS. So we would sort of hesitantly walk in the room and sit down. And it never failed that within 10 minutes, they'd shown us something that completely undermined our workflow. It showed us that they had absolutely no idea what we were doing on a daily basis. And they hadn't put any consideration into how we were actually going to use it. And really, it was the little things that drove us crazy that showed us that they hadn't paid attention. And I always thought because most of these systems were very large, clunky, expensive proprietary CMSs, that it was a case of, well, it's just too hard to change. This is what you get out of the box. And so that's what it is. So it was never really an option to say, well, maybe if you changed this a little bit, it would save us a lot of time. And when I started working in Drupal, I couldn't believe that this was still the way it was being done. And it was the way it was being done. And most of even the projects that I managed, the client lead didn't discuss these issues, didn't want to let us talk to the content editors, just didn't really consider it important. And I think the advantage that we have using Drupal is that there are so many really small things you can do to make it better for these people. And it's not about saying, well, we just want to improve people's lives. You're creating a tool that enables people to publish information to promote some kind of a business goal. So the ease of use of that system directly correlates to the value for the client. If publishing things is hard or annoying or frustrating, then your tool is less valuable to them because it's gonna get done slower and it's gonna get done less often. If it's a nice system that they don't hate to use and they can do things quickly and efficiently, it's more likely to successfully promote that goal that they initially came to you for in the first place. So it's important not to think of it as you're doing someone a favor or this is a little nice thing that you can add at the end. It's critical to the delivery of a successful product that the system is usable. So it is nice when you make something that people like to use, but that's not really the point. I mean, just to put it simply, if they hate to use it, then they won't use it. And then they will say bad things about you, which I can assure you we did very, very often and for very extended periods of time. So I mean, if I feel like that's a pretty kind of obvious point that if it's a nice system, then it's a better product. But most people still don't do it. They don't focus on this, they don't really care about it. And I think there are a lot of reasons why. The first one being it's just easier if you don't. So there are a lot of other things to focus on. They're complex backend integrations. There's, you know, is it pixel perfect matching the design? And if the client doesn't care, then it's really easy for you not to care. If you wait till the end, so if you say, well, the client didn't ask for it, let's just hand it over and then see what happens. That is just not gonna work because if the client didn't think it was important then, they will be made to know that it was important after. Like I said, we were constantly complaining and cursing these people and saying, why didn't they ask us just the simplest question? So at the end it's too late and not because you can't make changes and you've locked yourself in. Obviously we all know you can still make changes but the damage is done by that point. So if you've delivered something that very clearly shows no indication that you gave it any attention, then their suspicions are validated. So we always approach this very suspiciously. If we weren't consulted, we'd come in saying, it's gonna be another one of these ones where nobody asked us, nobody knows what we're doing and they're gonna just sort of impose this upon us. Someone once put it as being a victim of a CMS. And I just don't think that that should be happening with Drupal. So the goal here is to start from the very beginning and build it into the process. If you start at the beginning and if you do it from the beginning, it's not that much work as you go along. So the first tip is don't settle for core. And we all know this on a technical level that core doesn't provide everything you need to make a website. So we always install contrived modules. And I mean, it's pretty unusual that you'd be building one without contrived. If you are building a website and you don't want to use contrived then this is the wrong talk but there are so many contrived modules out there that can improve the editor experience. And oftentimes this is a simple case of installing it and enabling it and that's all you have to do. So there are countless contrived modules that you can use to achieve this but I'm gonna just show you a few that we use as kind of a base build for our projects that just sets you up to be able to improve things. So here's a quick list and then I'll just run through them one by one. Views, bulk operations with administration views. This is the core admin content screen. You have two options for filtering status and type. If you've ever tried to use this system it's really clunky. You have to apply one, then reset and then apply another. It's really hard to find things. There's no keyword search. They may not have listed a keyword search for content as a requirement but if that's the case it's because they assumed that it would come with it. So simply by installing views, bulk operations and administration views you get this much prettier content screen which has a title search, better filters that you can apply quickly and the best part is you can add your own filters. So this is what it comes with out of the box and this goes a much longer way than the initial one but the best part is you can so as you're adding content types and as you're adding taxonomy vocabularies you can keep adding filters to enable people to find things very quickly and you can also add columns to the results screen as well which a lot of people find useful and this same thing applies to the admin people page. I did a quick survey as I was putting this together and I asked if anybody realized that the core filter that comes on the people page is filter by permission which is extremely not helpful. It's literally a select list of every single permission on the website and sometimes this can be thousands and the average user isn't gonna be able to assess what that even means so it's not useful. This is much better, you've got out of the box you've got a username search, an email search, can filter by role and again you can add new filters as you find you need them. The next module is administration menu which adds a fancy little drop down menu. Definitely it's important when you install administration menu it also comes with something called administration menu toolbar style and this just makes it look nicer so if you're gonna enable one, enable the other and then disable the regular core toolbar so they don't conflict with each other. And a big point I would make about this is it's not necessarily that going from three clicks to one click so if you wanted to go to the taxonomy page you have to click structure or taxonomy find your vocabulary this way you can just drop down to one. A lot of people have trouble finding things in Drupal because if you don't use the system every day you're not sure do I go to content or do I go to structure and the drop downs allow you to kind of pre-screen the page before you go there so it's not necessarily about arriving at the right page in fewer clicks it's about finding the right page in the first place. A WYSIWYG, we all know this is in Drupal 8 now but it's still gonna be an issue for all of us Drupal 7 users. Just install one, just don't let your clients see Drupal without a WYSIWYG because they're gonna be really confused. You can use CK Editor, that's what we typically use it doesn't really matter what you use but make sure you have some basic options enabled and a really important one is spellcheck as you type which doesn't come enabled out of the box and if you're using the WYSIWYG module it's not actually an option so if you find that you aren't able to work it out a simple Google search will find you this custom module that switches spellcheck as you type on by default and sets the default language if it doesn't happen to be American English. And one of our developers said but you don't need that because the browser will tell you if something is spelled wrong and that's actually not true in the WYSIWYG field it doesn't so this is a case of the technical person was trying to say no no they're just being demanding but the reason he didn't know is because he hasn't spent all day working in a node with 15 different WYSIWYG fields and if it's not on by default you have to enable it in each field one by one. Linkit is a module that improves the internal linking process so if you don't have Linkit installed on your site if you go to a node and you try to add an embedded link the process is you have to open a new window find the page you want to link to copy either the node ID or the path alias most likely it will be the path alias because it's really hard to get people to actually use the node IDs and this can result in more broken links and then you have to copy it bring it back into the other window and create a regular hyperlink. But the Linkit module with a few really simple configuration updates allows you to click the Linkit icon in the WYSIWYG it pulls up this model which allows you to type the name of any node it auto completes with the options you click on the node title and it creates as you can see an actual node path rather than an alias path. The next one is login destination which is something that we overlooked for a really long time until one of our clients said why do I always go to my profile page after I log in and we thought well let's just because it's the way it works but on almost every site we build the user profile page is not used for anything at all so it's a really big inefficiency that every time they log into the site they're on a page that they can't use. So the login destination module just lets you pick a better page you can set up a number of rules depending on the role and just ask the client sometimes they'll want the homepage sometimes they'll want the workbench page sometimes they'll want the admin content page but it's less than five minutes to set this up and it saves them an extra click every time they log in. And then kind of a minor one that I just like is to pick a different admin theme I think the seven theme is good but it has a lot of problems and the shiny admin theme is a really nice one it's actually the commerce kickstart admin theme and it also is quite similar to the new Drupal 8 admin theme and it's just a little bit more professional it's a little bit nicer it's not, this isn't really critical but I think it just I think it goes a long way and it's extremely simple just install and enable. The next tip is to ask questions and I thought about calling this ask the right questions but I think the point is that it doesn't really matter what the questions are and how you phrase them if you get a conversation started then you're more likely to get valid feedback the only way you can give people something useful is to find out what they actually need and what they actually want so ask them how things work talk to them about do they currently have a CMS probably what are the biggest pain points in that current process what are the things they do most often what do they love about their CMS and what do they hate about it because if there is something that they hate they'll probably tell you if there's something that they love they probably won't because they take it for granted so if you deliver them a Drupal CMS and they can't do the one thing that they used to love in their old one they're gonna be really unhappy even if every other thing you've done is better they'll say but how come we can't do this and I think once you encourage them to start talking about this then they'll be more comfortable asking for things and saying well actually this is kind of inefficient do you think that we can change it and a really good example of this is a site we built where there was a content type that had a square thumbnail which was called the thumbnail image and a rectangular feature image and just kind of without thinking about it we built a content type that had two image fields we had a thumbnail field and a feature image field I mean probably if you'd asked we'd said well maybe they'll use different images but I think probably we didn't even put that much thought into it and I was looking around the site after it launched and I realized that I think they had about 200 of these nodes and in every single case they used the same image in both places so we could have saved them a ton of time by having a crop feature instead so they upload the photo once and then crop it twice rather than cropping it twice outside Drupal and then uploading it twice so I mean that was a situation where I think if we'd empowered them to ask about it and say hey how come we have to upload the image twice then we could have made the improvement but we didn't know that we needed to do it because we didn't ask the next thing is just kind of a simple thing but we all know that naming things is hard so it's really important that you make a plan and a lot of times when you're working on a project there's an existing terminology that the team will use and if you deviate from that it can make things really confusing for them I did a training session for a group of people and I used the word teaser all over the place because it's what we called it throughout the build and at the end of the session someone raised their hand and said what's a teaser and I mean that's such a fundamental question that we overlooked and we went the whole day talking about it and they didn't understand the concept so a good way of doing this is when you're doing your IA and your designs label each field as it appears on the page and define it so ask the client do you have a name for this already if you don't is this name okay and then you can distribute this to the developers when they're setting up the content types because if you don't they'll each come up with their own name and then there will be no consistency the next tip is about help text which is my favorite thing to do on a website it's really important to write good help text a lot of our support requests I noticed were resulting from users just not understanding how it was supposed to work or they you know we provide extensive documentation and screencasts and we train them in how to use it but if it comes down to it and they're in the page and they don't know what to do it's much easier to call you or to create a support ticket than it is to actually look it up so if you provide help in context then they don't even have to go anywhere to find it and I'd say they'd probably rather not have to call you so if that help is there they'll probably use it these are just a few things I've observed about help text I think one of the most important things is describing where it will appear obviously answering any obvious questions like if it's an image what sizes it needs to be that kind of thing and also listing any limitations so if there's a character limit or a specific requirement for it then it's really important to list that some bad help text I'll show you some examples of this but obviously bad help text would be providing no additional information so if you have a field called icon image and the help text is the image or icon for the widget anyone can work that out so it's actually a waste of their time to read those words like you may as well have no help text there because there's nothing in that help text that they couldn't have arrived at on their own and this is really bad help text this is actually just confusing so this came from we were using the title module which allows you to convert node titles into field APIs so you can use them more flexibly and this is just what it came with so it's just a title you just don't need help text and this was what it came with so the developers just didn't change it but if a client saw this I think it would be not only would they not know what to do they'd probably call you and say what does this even mean so rather than using the title field which is the easiest field of all to use they would actually be confused by it so luckily the client didn't see it but you just have to be careful with these kinds of things and this is another example of kind of bad just the Facebook field URL the help text is enter the Facebook URL and this is pretty common that you just write the help text enter the whatever the field is called and again that's extremely not unhelpful I mean anyone knows it's a Facebook URL field this person is employed as a content editor they can probably work out that you're supposed to input that information but describing what it does means that they don't have to ask you so the better help text is adding the Facebook page URL creates a Facebook like button for the page so now they know what it does this is another example of average and then better so if you have a field called broadcast network and a select list choose the network that airs this program I mean that's clear enough but if you say choose the network that airs this program if your choice doesn't exist you can add or edit the list at this link and you can actually provide the link to the page that they need to go to so if you have you know this can be a problem if you have permissions issues well not everybody can edit taxonomy you can link to a help page that's in the actual website but as long as you're not forcing them to take that extra step of going somewhere else to find out whether it's calling you or whether it's looking at documentation that you've provided your saving time both for them and for you and one of the big challenges we had with help text was we use features for config so what ended up happening was the developers would write the help text and then we never changed it but we started doing a process where I think it's really hard to take a field and write help text say in the spreadsheet and then send it through I think it's important that you write the help text you save it, you read it, you read through the page and you make sure it all makes sense so what we started doing is waiting till the content type was finished once it got to the dev site I would look at it go in update all the help text and then have one of the developers rebuild the feature from the dev site with the updated help text and after you've done that you can send it through to the client and still ask for tweaks make sure that they know that this is something that's really easy to change so a lot of times they won't ask you to change things cause they don't know if it's easy or hard this is one that's really easy and can pay off and there are a couple of bonuses with help text writing it can reveal issues that you need to fix such as in Drupal every time you make a content type you get a body field but you don't always need a body field and most of the time the developers leave it because it's extra work to take it off but if you find yourself writing help text and the help text that you write is this field is not required it is not visible anywhere I mean you can't actually seriously write that so send it back to the developer and have them take it out and there's nothing more confusing to a content editor than seeing something like don't worry about this field well you know why is it there and the other thing is that you're gonna have to write documentation anyway so if you start by writing the help text then you can copy and paste this directly and either use it as your how-to or use it as a basis for your documentation so it's not time that's just spent on that it's time that's kind of invested in future work and again like I said I think this is the number one way to reduce support questions that result from just not understanding how it works tip number five is contextual links which is my favorite thing about Drupal and that's because this concept of in place administration is really different to the way a lot of content management systems work with a lot of proprietary ones you have CMS.login.com and then you have website over here so you log into the CMS you make the changes and then you have to refresh the page over here and what's happening with the case it's really hard to find things in Drupal that just isn't a problem because you're already in the CMS the website is the CMS so if you need to find if you need to change something navigate directly to the page click the edit link and then you're there and even when you save it it refreshes the page and shows you your changes which I think we take for granted and I took for granted as well after a while but thinking back to the way I used to do things it was a nightmare to have to have that just a big huge list of 800 things that you had to search through and you had no way of easily finding things and editing them so contextual links in Drupal are extremely helpful but I found a few websites where the editors didn't have permission to see them which is completely undermining one of the most valuable things that Drupal provides so number one is make sure they have permission to see them and number two is make sure they understand how to use them if someone doesn't have permission to edit a view then they don't see the edit view contextual link so you don't really have to worry about permissions but of course it's always best to test and of course there's a module for creating custom contextual links and any time there's an extra step required to make an update or publish something you can add a custom contextual link to save a ton of time this is an example of just regular old contextual links if you have a view of an article you click on the gear and you have edit and delete so let's say you wanted to remove something from the home page you have to click edit, scroll down click the publishing options tab uncheck the box and save it and then it's gone with custom contextual links out of the box you can add a few specific things one of them is making content unsticky or sticky and one of them is removing content from their front page so rather than having four clicks you can go to the page, click the gear remove content from front page and that's done and then from there I mean those are the ones you get out of the box but you can try to think of better ones as you go and as you start doing them you'll think of more and more useful ones so let's say this client is really keen to promote photo galleries so add links to create photo galleries in as many places as possible and encourage people and make it easy for them to do that you can add a link that say you know tweet a link to this article and like I said I think as you use it you'll start coming up with better and better ways and sometimes even the client can suggest them but this is something that a client would never suggest if they didn't know that they could do it the next tip is fairly simple which is just use common sense sometimes and one of my least favorite examples of this is if you have a node that has three fields and the node edit form those three fields output in the same order on the page that makes perfect sense and it's really easy to have this at the beginning because you make the fields in order probably and then they appear in order but as you create as you add new fields to content types by default they appear at the bottom so what you end up with is these two things being completely out of alignment and I think I've gotten some pushback on this one where a developer said but why does it matter and it's just not intuitive so when you're thinking about creating a page you're thinking about those elements in the specific order so if you come to the edit screen and they're out of order that can be really confusing and I know that now in like Panopoli and in Jubilee there are a lot of complex some updates that they've made to the user interface and in those situations obviously if the save button's at the top or if the menu information is on the right that's different but when you're working with a simple node edit form it can be just a case of as you add a new field just move it into the place that it appears and then of course turning off stuff Drupal comes with things turned on and even control modules come with things turned on and you don't need them so keep an eye out for this and if you have a website that never uses commenting just disable the module one of my developers said but I have it in my head now I always turn off commenting first and I said well first of all that's an extra step that you don't need to take and second of all if you're an admin with comment administration permissions this tab appears on every single node page so you can simplify that UI just a little bit but you can simplify it and just remove it from the page and this is a really small example but I think the concept is keep an eye out for things like this and they'll start becoming more and more obvious tip number seven which is what I call you build it you try it and this is the developers testing things so if a developer builds something the way we do it is there's a peer review process and a testing process that ideally before they create the feature they'll write out the steps that it will take to create a piece of content or update a piece of content and if you start writing out the steps before you've done it and it's 10 steps you might actually think oh that's a lot that's kind of complicated what can I do to make this a little bit simpler and then after they've done it when they deliver it another developer has to actually test it so sometimes they'll test it and say this workflow is crazy change it make it better that's not necessarily the point I mean I don't really see the developers as a gateway for that kind of thing but the idea is that the more they actually use the CMS the more likely they are to notice things that are complicated or that don't make sense and then they get better so if they notice it's something that someone else did that was a little bit clunky doesn't necessarily mean they had to send it back for change but next time they build that they'll have more of an understanding of the way it's being used and the way they can do it better so this is the seven tips all in a row and I mean I think this looking at it it's a pretty simple list of things to do there's nothing particularly time consuming or scary or expensive here and the point that I made earlier is that when you start with a really good foundation then you can start looking at things like context admin which is where you can create complicated pages to do things in bulk and contextual workflows those kinds of things but that's not what the takeaway is from here the takeaway I think is that by just starting out with some really simple best practices and strategies and things to look out for that you can build a better product and this is not something that I said but Jeff Eaton said in a presentation that he gave content editors are the most important users of your website I don't think this needs to be controversial it's not a debate but you don't really need to agree but the idea that a website is only as good as the people who create the content if you make a system that content editors like and that they find intuitive they'll create better content they'll create more content and they'll do it faster if you don't they won't and I think if you don't take away this that content editors are the most important users I think if you at least take away that content editors are actual users of your website so when you're building the website and when you're doing the UX we always focus on the front we focus on the design we focus on the pixels but the content editors are the most critical piece in making the website successful so just paying those little bits of attention here and there really goes a long way and that's all questions? Hey that was a great talk with WYSIWYGZ which could be a discussion in itself but a fellow Australian actually said we should stop calling them that and call them visual editors because they give too much connotation of power to a content editor and they create a bug but what I see is not what I get the question was what was your thoughts on that I guess that was the answer but well I think it's just it's just a necessary evil I mean obviously I would rather not have to deal with it but I think it's about explaining what they are and how they should be used and I think a lot of times at the start of the project the client will demand that everything look perfect and it's stripped their Microsoft Word tags perfectly and you know do their line breaks perfectly but I think it's all about educating them and saying we can spend two days trying to ensure that every time you pay something for Microsoft Word it's gonna be absolutely perfect but it's probably better for you to spend you know the few seconds it takes to use that little erase icon instead and it's probably a much better result I mean I think a lot of it is educating and explaining and yeah I don't enjoy WYSIWYGZ myself no other question what's your thought about content strategy and making tools for the editors to support a content strategy I mean we build websites that's responsive so you have to write content both to smaller screens and larger screens so what's your thought on that I think it's fantastic but most of our clients aren't interested in spending money on it so I think if everyone wanted to invest the time then every product would be a lot better but what we found especially with government and with big with big kind of government higher education I think maybe media companies are much more interested in investing that time and I mean even having a content strategy would go a long way on this process especially like you said with responsive sites but this is kind of why I pitched this talk is that I know that it's not practical for all of us to spend three months researching and doing user testing and asking people how they find the tools to use this is the tool that we're building with so it's about maximizing the value from it for the least amount of effort I have a question in regard to training so what kind of material do you provide to your clients does your approach replace the training of documents? Never, never but I think it depends on the team I did training for a team of I think 100 editors and I put together like a 25 page manual that they could follow along and then use after the fact but most of the time if the system is intuitive and you provide a fairly detailed just kind of step by step sometimes we do screencasts but the problem with screencasts is that they're really hard to update so if you make a small change then the screencast is no longer useful so we have wiki pages in our project tracker and then I actually have started creating we'll set up a content type in Drupal that's only visible to logged in users and then actually create the how to guides in Drupal and link to them from the main menu so that way at least it's in the right place so like I said with the help text if you have a how to page on how to build this content type you can link to it directly from the content type and that way it's in the website they don't have to log into something else they don't have to find another link it's right there but yet training is it's something that we build into the budget so if we know that it's a team of 100 then we'll budget so much time for putting together the material and then actually training them but I think nothing will nothing replaces in person help thanks how much do you work with the clients to work out the editorial workflow which is very personal from a client to client but to what extent do you handle it it depends on the client there because sometimes as I said we have clients that say you can't we don't want you to talk to them you know we don't care what their workflow is we're gonna set up a workflow that they're gonna use because we know how it should work and they'll just have to do it and obviously the problem with that is and this is what I used to always do is then you get those highly technical users that are just constantly trying to find a way around the processes that you put in place so where possible I think it's really important but one of the things I found is that when you ask even media and like pretty savvy web teams what's your editorial workflow they kind of go what do you mean you know put the content in that's that's how it works so obviously establishing you know do your reviews offline do your reviews online is there something we can do online to make that process easier that really helps but most of the time they don't know what we mean until we build it so you build them something simple and this is the approach we take a lot is we deliver them what we think they need at a minimum and then add to it as we go because I think a lot of times if you get that kind of top down this is what it is you'll get a workflow with 10 approval steps and then within two weeks every single one of them has been removed because it just wasn't practical so I mean that's not really an answer but if the client's willing to then it's highly beneficial to do that at the start and the great thing about Drupal is what we have also started doing is spinning up a kind of a just a base install with the things I mentioned and sending it to them at the very beginning and saying play around with this you know you want a forum on your website play around with the Drupal forum let us know if this meets your expectations is there any extra that you want to do and even something as simple as creating a node and saving it sometimes people are really impressed by how easy it is to do that in a Drupal and when you save it it takes you right to the page and then you can start that conversation okay it works but what are some things that might make it better we just had a Drupal shop builder say a large multi-site platform and we had editorial workflows in the RFP and they intentionally removed that from the RFP and said we don't want to touch that this is a bit of a third rail they can do that what they said was every site that comes on is going to have their own editorial workflow and we don't want to be caught up trying to figure out all the different patterns and combinations involved and so they left it out and I was wondering whether there was an alternative way to approach that problem when you say multi-site what's the actual setup so it's one database serving multiple databases it's one doc route and one set of shared tools and then multiple sites adding customizations as needed and they each need a different workflow yeah different offices in different countries working different ways hmm well I mean we've set up some pretty complicated ones using workbench which allows you to set up sections and it's not perfect but it does allow you to segment it a little bit I mean I would definitely say it's not something that we wouldn't touch because it's the third rail it's never particularly fun but if you budget for the time and the testing and the feedback that you need I think I think with something like that it'd probably best to say let's spend a week workshopping it and then see what we can do but oftentimes when you ask the client what their workflow should be they really don't know and they'll ask us what do you recommend so did you have it mapped out beforehand no I think every office had their own expectations and they all kind of thought that the workflow would be similar to the one they're already using for their current website and I think that was probably why the developers sort of removed it but now we I mean what they ended up delivering was the default the admin user and the content editor user types and so now we're trying to sort of fold in workbench after the fact and it's workbench is really good for that kind of stuff and even there's something called there's a module called context admin and even view bulk operations you can use to set up pretty simple but useful so if five offices each want five different filtered or landing pages or whatever it's really not hard to set those up just got to know what to ask for I will be asking for it thank you okay one more question feedback of course if you go to prog2013druple.org slash node slash 99 you can rate my session so thanks