TPR8: Drupal Workflow: Set it and forget it!

Mark Marcello 
Web Designer, Rochester Institute of Technology

Alexander Gartley 
Associate Web Designer, Rochester Institute of Technology


The audio for this podcast can be downloaded at http://2011.highedweb.org/presentations/TPR8.mp3



Announcer: This is one in a series of podcasts from the HighEdWeb Conference in Austin 2011.

Mark Marcello: All right. We work for University Publications at RIT, so we do a lot of the print and web that RIT produces for marketing reasons. Two of our biggest print pieces are these books, the Undergraduate and Graduate Bulletins. Some people call them the Catalogs. Basically they are huge 300-page books. They have all the programs and courses you have to take and everything to graduate. These are a lot of work.

I'm not going to talk about how Drupal workflow changed our process of making these. It revolutionized the way we make these.

For 10 years, these were done in a print-centric model. At first, we would do the print piece, so that would take months, and then when we were all done, we'd print it, and then, 'Oh, we should now put this up on the Web so people can see it.' But the thing is, everyone looks on the Web to see it to begin with, so it seemed kind of backwards.

Now, with the workflow, we're able to keep the content on the Web up-to-date all year, and then once a year we just take a snapshot of the Web and print these books. So it totally flips it around.

 01:08

We'll be talking about the organizational structure of RIT, not to educate you on RIT but just so you can see the breadth and the depth of the scope that we had to go through to do this process, and it will work for you if you're a large university, a small university.

We'll talk a little bit about the history of these Bulletins so you can see where we've come over the years, because it's been a pretty slow progression until this past year when we completely flipped the model around.

And then we'll talk about the implementation of the Drupal workflow, because you're here and you probably want to learn how to do it, and training. I say it all the time: you can build the best product in the world, but if people can't use it, then you just wasted all your time. So we implemented a very good training system to have over 100 users use our Drupal workflow.

And then we'll talk about the challenges and benefits we had along the way.

Alexander Gartley: All right, just to give you a little bit of overview context of our university. We're Rochester Institute of Technology in Rochester, New York. We have nine colleges and two institutes in our university. We have about 17,000 students, about 3,600 faculty and staff, just to give you an idea of the size. We have slightly over 230 programs, and all of those are in these Bulletins.

 02:25

We don't have a marketing department at our university. We're pretty decentralized, so it's always a challenge having consistency across the university, whether that's branding and stuff like that, but also content and information that we're communicating. It's always a struggle to be consistent with that.

Mark and I work for University Publications. Our department does print and web work. We do the main website pages, secondary pages with that, and we do pretty much all the print stuff for admissions, including these Bulletins.

 03:06

Our Bulletins, just to give you some history with them. They were originally done, all the edits were done on paper. The coordinators for each college who knew the material would mark up by hand, cross things out, write things in all these markups, give them to us, and we'd have to put those into the design. So all the edits are handwritten. Very inefficient and very time-consuming way to do things, but that's how it was done.

Then, about eight years ago, we moved to Microsoft Word. Yay! We used word tracking, and the reason we did that is not all the changes the college coordinators are requesting be made are actually made. We have an editor that's just making sure that things are consistent between colleges, the lengths of things stay consistent and the style is correct. We used word tracking in Word and then we'd import those.

 04:04

And then, like Mark said, after the Bulletins went to print, we'd then take those Word documents and export them as individual HTML web pages to a program's website.

The timeline for how that worked, the coordinators got three months to make all those changes in those Word documents. After they made those changes, the Word documents then went to our designers that would import them into InDesign, and they got a month to do that. They had to bring them in once that tapers off, and then they'd go back to the coordinators. They'd mark up on paper more changes, and they'd go back and forth until we finally had the print piece.

 05:04

Again, after it went to print, actually now it would have to take a couple of weeks our editor would have to go back, and all those changes that we made along the way to the print piece weren't made in those Word documents, and that's why we were taking them into it.

Mark Marcello: And just for the record, our editor was often busy, so I would do this. As a web designer, I'd have to go and make edits in Word documents.

Alexander Gartley: We had to remake those edits that were in the print piece to those Word documents, so finally those Word documents matched what we were printing.

And then once we finally had that, then we converted about a month-long process those Word documents to a static website, where we cleaned up tags and everything for each individual page, made sure the style was correct and everything.

All right. The next phase was about two years ago. Nothing changed up to the print side of it, but now for the Web, we created a database with a little CMS. Now, instead of changing those Word documents to individual HTML pages, we're now putting them into our database.

 06:12

That did two things for us. That cut down on our time. It was much faster to Word documents into the database than having to create individual HTML pages. But also, it gave us some more functionality on the website.

Like Mark said, we're starting to realize that more people are accessing this information on the Web than in the print pieces, even though our focus in our department is on the print side of it and not on the Web. The Web is almost like an afterthought. So that's starting to change here. And because everything was in the database, we could now categorize the programs so you can now sort by college, you can sort by degree level, things like that.

Throughout all these different phases, the basic model didn't change. The basic workflow going from print to Web didn't change. So the print every year in July was delivering.

 07:12

The problem with that is we're taking these Bulletins, which are updated once a year, and then we're updating this website once a year when there's actually changes made to programs throughout the year.

And that was an issue because we would get requests from coordinators saying, 'Hey, my things are out of date online. Could you change them?' and then we were stuck in a place where, do we go now and make all these changes and get a lot of time, but then also, we just didn't have a system built. It doesn't work that way.

So finally, last year, we moved into Drupal, which has been awesome. A huge undertaking. We moved away from the coordinators making all those changes in Word. Now they're making them right in Drupal online. So now we're starting with the Web. When they make those changes, once they're approved by our editor, who's also in Drupal, they go right to the website. This is awesome. They can make changes throughout the year now.

 08:11

And then what we do now is, at a preset date that the coordinators know about, we turn off the logins, download that information, and import that into the print piece. Now we have a snapshot, the newest snapshot of that print piece, the most up-to-date, and now the website is up-to-date year round with those changes.

So we finally switched now. We're web driving print piece once a year. Now it looks better.

Mark's going to talk about how we did that.

Mark Marcello: For those that use Drupal, now you know there's different user roles when you install Drupal. You have administrator, authenticated user. Well, we needed more granularity for ours, because we have a workflow with different types of users. So before we actually went in the system and started using Drupal, we had to plan this out.

 09:06

I don't want to join the... Hold on. Good. Sorry. What happened here yesterday?

We had to plan what user roles we would need for the different people across campus, so we came up with these four, and that's Author, Coordinator, Editor and Site Admin.

As you see there, in alphabetical order, this is for a reason, although not that important. In the permissions panel in Drupal, it lists these horizontally in alphabetical order, so now when we're setting permissions, we can easily do the permissions and see who has what.

The author are the lowest level in the workflow and these are the department heads, the secretaries in the departments. They're the ones that know the information the best. So they actually go in there and say, 'A student has to take this course and it's this many credits.'

The college coordinator, there's one per college most of the time, they also know the material, but not quite as well. They're more focused on consistency throughout the college and making sure all the programs within the college have the same look and feel.

 10:09

The editor is in our office and she's, again, interested in consistency, but now for all of the colleges. She makes sure that our marketing and our branding messages are unified across all the programs. And then of course if there's any spelling errors or things like that along the way, she takes care of those.

And then the site admin are Alexander and myself and Jared Lyon, who's not here today, and we're the ones that fixes it when it breaks.

Now that you know the user roles, I have a video. And this is two-fold. This is the video that we created for the coordinators so they can learn how to use the system, but for all of you, you can see the whole process from start to finish of the workflow in editing a program.

This is about five minutes, but it will really help.

Video: The subject of this video is updating RIT program information for coordinators.

 11:02

There are three user roles that can modify program information within our system. Authors can update information, but then it has to be approved by a coordinator, who finally sends it to the editor to make the update live.

As I mentioned before, this video just covers updating information from the coordinator's viewpoint. If you are an author, please watch our video for authors instead.

Here, I've already logged in to the program's website and I'm doing the programs in my college that I can edit as a coordinator in the College of Business. You will notice a column on the left of the site that says "In review". This column lists programs that have their workflow state set to "In review".

There are a couple of different scenarios where this could happen. It will list programs that an author has edited and submitted to you for review. It will list programs that you have moved from 'live' to 'in review' because you want to edit without the author being involved or it will list programs that the editor has sent back to you for further review.

 12:04

As a reminder, the program's by links above this area will always list any programs in your college no matter what state in the workflow they are in. So programs listed in the program's by links may not be editable by you depending on where they are in the workflow, for example, if they are with an author or an editor.

From here, there are two scenarios. You may want to review one of the programs in the "In review" column, or you may want to start editing a program that is currently live. In order to edit a live published program, we first have to change its workflow state to "In review with coordinator".

First, I'm clicking on a program, if not viewing it already, and we see right by the title of the program three buttons: "View", "Revisions" and "Workflow". Note that we don't see an "Edit" button right now because this particular program's workflow is currently set to 'live'.

 13:02

From here, I click "Workflow", change the current state to "In review with coordinator", and click "Submit". Now we're back at the main view of the program, I can see that the "Edit" button is showing up and the program is now also listed in the "In review" column on the left.

At this point, the editing process for any program in the "In review" column is basically identically, whether the program was sent to you by an author or an editor, or you have specifically pushed it from 'live' to 'in review'.

Just click on the program, click on the "Edit" tab, and edit the program as normal for as long as you want, obviously also keeping in mind the deadline for the print version. You will always be editing a pending revision and not touching the live published program's page. After you're done editing, just save your changes.

Now the program must either be sent to the author to clarify something or sent to the editor for final review and to be published.

 14:05

Let's assume for this example that we want to send the program up to the editor. So we go to the program, if not there already, click the "Workflow" link by the program title, change the current workflow state to "In review with editor", add an optional comment, and click "Submit".

The comment area is very important for coordinators as this is where you can make comments to the author or editor about what changes you've made or what changes need to be made.

Once we've changed the workflow state, you cannot edit the program again unless the author or editor sends the program back to you by setting is as "In review with coordinator" or the revisions are fully approved by the editor and the program is back in its live published state.

Here, you can see the "Edit" button is now gone and the program is no longer listed in my "In review" column. And that's about... we've now successfully made changes to a program and send it off to the editor for final review. As a reminder, here are the only available Workflow transitions available to coordinators. From "in review" with coordinator to "in draft" with author, from "in review" with coordinator to "in review" with editor, from "live" to "in draft" with author and from "live" to "in review" with coordinator.

Finally, it's also a good idea to log into the system from time to time to check to see if you have any programs "in review". Again, this could be programs you're working on or programs that have been sent to you from an author or editor. Thanks and I hope you enjoy this video.

Mark Marcello: OK. So that works pretty well.

Alexander Gartley: Can you ask him, third speaker?

Mark Marcello: Now, can you? Okay.

 

16:00

The system works great and this is now how we did it. And we really only need three main modules to get the workflow to work and that's revision workflow and trigger. There are other modules that add functionality to it and a few that are required by these three modules but what we talk about today are the top three.

The first is revision and what this does is every time you edit a page and then press save, it creates a pending revision. So this allows to track all of the changes of the versions overtime and this allows the people above you in the workflow to accept or deny the change. So if an author makes some ludicrous change on the program that the quarter does not want, she can easily just edit it herself or deny it altogether.

Another benefit of the revision module is that it keeps track of all the changes overtime. So right now, our IT is going through quarter to semester conversion. So in two years will be semesters.

 

16:57

If three years from now we find out it doesn't work, then we have to go back to quarters. We don't have to go back in and change all these programs. We can just revert to an earlier version. So that saves time if needed. Also, if there's a problem, say the vice president comes to me and says, "Hey, this change should not be here. Who did this?" It logs it off with the username so we have, you know, a log of everything that happens. So very good.

The next module is the workflow module, and this is really where you'll do all the configuration of the workflow. And as you see, we have states and this was mentioned in the video as well. And these are where the revision is in the workflow.

And for simplicity, we quit the user role name in the state so we have "in draft" with author, "in review" with coordinator," in review" with editor and "live". So before you do any configuration of the workflow, you have to first decide on what states you want and then create them at the add state button.

 

18:01

Once, you have those figured out, you can go and edit the workflow and this where you get this awful administrative piece here with a 100 checkboxes that you have to check everything that you want to happen. So it's confusing but if you look at it, it kind of make sense. Basically, like the video said, there's different state transitions which each user role is able to do.

So for author, they have two. They can take it from "live" down to "in draft" with author or from "in draft" with author up to the coordinator. So somewhere on here, you have to find those checkboxes and click them, and then you do that for each one of the user role states. Luckily, down further on the page, there's a human readable version of this. As you're editing that then you can actually....

Alexander Gartley: That what you're doing is making sense.

So, this is where you'll spend most of your time in here and it takes a lot of testing because you may think it works then if doesn't, so you have to back and change it.

 

19:00

So, test, test, test them and keep going in here if it's to work. I wish I give you this just to end all be all, take mind probably in the work for you but you'll be able to figure this out.

The third of module is a trigger module and what this does, well let me set that. In the workflow, when you push from "in review" with editor to "live", now it's out of the workflow and filed in the its "live" but not quite because its still a pending revision. So we are testing this and our edits were actually showing up "live". You can figure out why? It's because you need the trigger module to take care of this.

So what has developed is every time the transition state goes from whatever to "live", it publishes in it with revision. So this is how we are able to complete the workflow and now when you push "live", the newest content shows up on the web. Some of the additional modules that we used, one is deep and this is very handy for comparing revisions.

 

20:00

What I'll do is side by side to see the original and the change. There were actually highlight why this has been changed in revision. So this way, our editors don't have to go through line by line, read it and try to compare and see what happened, and edit if for you. Taxonomy access has been shown. This is free. And then the video, it mentioned how they're only showing College of these programs.

We have over 230 programs so we don't want all of those to show up for every user because they're only within one pallet. So College of Engineering only see the College of Engineering Program. College of Business only see the College of Business Program. And a few of the ones are just basic SQL functionality but they were helpful in this workflow system.

I mentioned permissions before and I can't discuss this enough. Check your permissions. If something doesn't work, it's probably a problem in here. In Drupal in time to turn on module or make a significant change, you have to go update the permissions.

 

21:00

So, I think in an account, how many times it happened? You would have everything set up perfectly, you test it and doesn't work at all. And then you come in here, this is the checkbox that you have to give all the users access to it. So 90% of the time, if something doesn't work, it's your permissions. The other 10%, it's probably going up in clearing your cache because I don't know why people does that but it actually works.

So, now we have the workflow set up and we want to make it easy for the users. So this image on the left that's probably hard to see, which is not good. It's where we illustrated the taxonomy to access control.

This is an example of coordinator in the College of Science and they only see the programs in the College of Science. This makes it easier for them. The image on the right shows the editing window.

And for those of you that use Drupal, when you press edit, you'll have the whole bunch of extra options you can select, the menu name and where you want off the menu, you can choose the path you wanted to display, if you want it to be a pending revision or not.

 

22:00

On my end, I don't want these people to make those changes. I just want them to edit the content and not worry about the URLs. I don't want them to worry if this the pending revision or not. So we hid all the information.

On their end, they appreciate it because they're not confused. They always think, you know, they haven't seen before They just go in and looks at Microsoft Word. They make their edits and they're good. So it works for both of us very well.

Mark Marcello: So once we had built and tested and got the Drupal system working and ready, we had to train the coordinators and authors how to use it. And it's over a hundred people that are using the system. So we started out by having a training session for coordinators. So it was small, you know, manageable group.

We did the session and it was interesting how it went actually. Because the things that we thought would be difficult, you know, moving to a whole new system, they're used to make in their edits in Word, now they're making them in Drupal.

 

23:00

Actually went pretty easy because, like Mark just said, once they were in that view of editing, once they've got logged in and everything, it look a lot like Word. So they have the same bold, metallic and all that stuff. So that actually wasn't too bad. That actually wasn't too hard for them. Just funny things came up in the training.

At one point, you know, we were going through to see the change that had been made. You had to refresh your browsers so we said, "OK. Everyone refresh your browser." And we got a bunch of like strange looks and people just like how do I refresh a browser. So we had to walk around and just you know show them how to refresh the browser. Just funny things you know.

But overall, it went very well. They were able to catch on and we then created some videos which we just showed you the one for coordinators but one for authors and few others. And those were great because the coordinators and authors, they're not making these changes everyday necessarily or even every week, you know.

 

24:00

Just whenever there's changes to the programs. So they're sometimes forgetting exactly how things work. So they can actually watch the videos and just be walked through and reminded how to do things. So that was great. It helped us with our training. Then the coordinators actually trained their own authors. So we didn't have to train all 100 plus people.

Those coordinators went and train their authors on how to do it. They used the videos that we made to help them. Then we edit the video straight into the Drupal site. They're on the side by there in a block that displays by user role so if someone's an author, they'll see the author video there on the side that can help them and walk them through. And we do occasionally provide support but it has been pretty rare. It's nothing bad at all. So the training overall went really well.

 

25:00

[Cross-talk]

Mark Marcello: OK.

[Cross-talk]

Mark Marcello: How do I do this? OK. Sorry, you already did it.

[Laughter]

Alexander Gartley: This is not on again, is it? OK. So now we talk about the web component of this. How the content is up to date year round. Now we have to print these books. So the solution we had is pretty neat. Since Drupal is a SQL database, we have access to the database, it's pretty human readable, so I was able to create a short script that creates XML output from the database.

So on this page I made, you select the college and the degree level you want and it prints all this XML. And it has the important information that we actually care about for the print piece, the title, the description, what college is in, the degree level.

 

26:07

And then we worked with the freelance experts in print the web what to print and he created this XSLT style sheet conversion, magic black box thing. Basically, we give him XML and what outputted is all of these ready code for InDesign.

So overall the styles are done, the tables are formatted correctly. So for the first time ever in the bold and creation process, it's uniform in going into InDesign. Everything is styled the same. So now we have that consistency that we wanted for all these years.

[Cross-talk]

Alexander Gartley: Yeah. I guess I don't know much about his background but he does web to print stuff and it's XSLT style sheet that he used for the conversion of the XML to the InDesign ready file.

 

27:07

I'm sorry I lost my train of thought here. So, no. Now we have these InDesign files that are ready to go and what's school that? No, now they're consistent and the designers have less stuff to do now because I don't have to worry about the styling. All the H ones, all the paragraph tags, the fonts, the table, are already designed and this done from the system.

Mark Marcello: So it challenges moving to Drupal. Drupal wasn't available at our university until last year of 2010 as a supported system. And actually if you want to hear more about that, you can come to the very next session here, Jason Potoniac is going to share how exactly we did that. So that was kind of challenge, once that was available.

 

28:00

We still had to come in two more things. Most of the college coordinators and some of the authors even are more nontechnical people so they've been at our IT a long time, very long time. You know but doing things a certain way so teaching them a whole new system didn't know how that would be but figured it would be, you know, significant thing. And then also just resources, right. So we have two and a half basically web developers. I'm actually a part time print design and part time web design. Limited resources for supporting the system, for building this, for training, everything.

So again, going into this, we really didn't have much of an idea how big of a task this would be in undertaking. But even with those challenges, we had obviously many more benefits.

Alexander Gartley: The number one benefit is the content being up to date year round. And even better than that, it's done by the owners and not myself.

 

29:00

Because in the past, if a phone number changed, say an author send it to me, I probably make the change because it's a phone number. But if a program title changes, do I have to then contact the coordinator and ask myself? And then if she says okay, I have to check with the editor to make sure it's okay with her because maybe for some reason our university does not want the title yet.

So now, I'm doing all these run around when I don't even want to be updating content in the first place. So now the workflow takes care all that and actual owners the content editing it and then it's going up the workflow, it's getting approved every state.

Time savings on my end for the web, it's done. I mean I spend off bunch of time up front building the system and now I don't have to spend a month converting Word documents to web. It's unbelievable. This year was rate for this. And for the designers like I mentioned, they're not spending time converting the tables to workpages line up properly and there’s no straggling words left behind so they're spending less time. I’m spending way less time. It’s great and then consistency between programs. Now, with Drupal we have these fields people are filling out information in, so they don’t this have free round of a Word document anymore to go on as long as they want, and put whatever they want. They’re putting in title program share. They’re putting in the tables they have the course numbers. So we have consistency all across the board.

So in conclusion, the Drupal workflow – it works very well for us, and it can be done pretty easily using three modules. And that’s the revision, the workflow and the trigger module. And I mention a few others that you’ll probably want to implement to make it work better for you but those three are the work course.

Test it a lot because it is difficult to set up even with tutorials online, it still took a lot of work. And what I recommend, you can only be logged in a browser with one user at a time. So I have three different browsers open. I had Chrome, Safari and Firefox. And every time we made a significant change, I’m actually editing and moving up and down the workflow to test everything because it already difficult pushing out a brand new system to over a hundred users on campus. So that brand new system is full of problems, then it’s never going to work. So test it very well.

31:16

If something doesn’t work, it’s probably permissions related. It’s very frustrating always making sure all the permissions are exactly how you want, but it has to be done to have this work properly. You can use custom blocks, views and CSS to make it the look and feel easier for the users as well as for you. I showed the text on the access control. We also use CSS injector and a few other tricks. So on the left hand side, the correct video shows up for the correct user row, they don’t want to go hunting for that. It’s right there for them.

And then with large sets of users like we have, I really recommend videos for training because you’ll going to be supporting the system. You don’t also want to be supporting all the users training them all the time. So you can reference these videos and then on small cases that you can go and help people if they absolutely need it, but this work well for us and I think it can work well for you too. So, thank you and we can answer any question hopefully.

32:16

Audience: [Unintelligible]

Mark Marcello: Mostly now, right. We do have a university-wide Drupal installed and that’s what we used for this. We have a very – we have tons of Web servers across campus because there’s a grow on Web servers. So, I’m sure there are other Drupal installs. I believe some colleges have their own. But what we use is the university Drupal install for this.

Audience: [Unintelligible]

Mark Marcello: Well, technically our homepage doesn’t run on Drupal. But if it did, that would be true.

33:00

Audience: [Unintelligible]

Mark Marcello: We use Drupal 6 for this.

Audience: [Unintelligible]

Mark Marcello: Of course. OK.

Audience: [Unintelligible]

34:01

Mark Marcello: Yeah. And I actually use the view to help create the code, to have me create this page. I guess, I just wanted – I felt more comfortable doing it this way. So, because when you created a view you can see the sequel statement at the bottom. And then I was able to use that and change it the way I needed to create this. But yeah, that would be a solution too I believe.

Just for – you mentioned Drupal 6 and 7. On this bottom on this page there’s this link drupal.org/project/revisioning. That has a great kind of walkthrough on how to set this up. And that’s really what we use for this. It’s only for a two state system. And we had a four state system. But you can really adopt that to your needs. So I recommend going to that link if you’re interested in this process.

Audience: [Unintelligible]

Mark Marcello: Correct, but it always keeps the newest published revision live. And then you’re working at the revision the whole time. So only when you’ve actually go to live, there’s to replace that copy.

35:06

Audience: [Unintelligible]

Mark Marcello: Sure, and we’ll be going through that process right now with the semester conversion because many of the programs are going away changing. Most of these have been around and we haven’t been adding or taking away many programs. When we do that, we usually take at the editor level because that’s in our office and we work under enrollment management.

We do our best. And if we do make a mistake, nothing we do. We hear about it like that. Do you have a question?

Audience: [Unintelligible]

36:01

Mark Marcello: Yes. It is rit.edu/programs, and we pulled up. I don’t think my wireless is working at all, so rit.edu/programs. And then if you want to look one of these just to see, it’s really identical information for the actual programs themselves. There’s extra information here as well.

Audience: [Unintelligible]

Mark Marcello: RIT, yeah.

Audience: [Unintelligible]

Mark Marcello: Do you know what software it was?

Audience: [Unintelligible]

Mark Marcello: Yeah. Our coworker Jared Lyon did that video. And it was – you can tell it’s kind of edited. Our office got silent sometimes so we’d bought some software for our office that does a screen grab and then you can overlay the voice and edit it afterwards. Because that’s how they was able to zoom in and…

37:01

Audience: [Unintelligible]

Mark Marcello: Yeah, and well luckily we just did a redesign – was it, for this year rather last year on this page. So, hopefully we won’t be changing anything major anytime soon. But we’ll update the videos when that happens. Yeah.

Audience: [Unintelligible]

Mark Marcello: Currently, we’re dependent on getting on their check. What I believe using triggers, you can set up the same type of thing where it does a transition state to them. It can send out an email. And I actually don’t know why didn’t do that. But I believe that would work just like that.

38:03

Audience: [Unintelligible]

Mark Marcello: That’s a good point. Basically, all of it. It was – Alexander mentioned how last year we went to a database instead of Word documents. We’re able to copy a lot it from there because we had a lot of the same fields – title, program, chair and then the description. But the tables we did a little bit differently, so we had to go pretty much program by program and get exactly how we wanted for this. But it’s one of those things where you do it once and you don’t have to fix it later. So we just spent the time upfront as part of this process, and I think it would be good for a while.

39:03

Audience: [Unintelligible]

Mark Marcello: Yes. Yup, we use tiny MCE in there. And then we limited the number of buttons they have at top so that they can do the basic table editing things like delete row, add row and what not.

Audience: Can you talk a little bit about how you achieve this switch from print to Web, from Web to print organization, you know – the theory or technically with. Because right now we have but everything that they do in Drupal comes from different sources and we can’t get them and let go...

40:04

Mark Marcello: And we are on that same boat for over 10 years, so we finally did it this year. Really, for two years where slightly people know it’s going to be this way. I mean, you have to be strict with that because people –

Audience: [Unintelligible]

Mark Marcello: Yeah, we had some conceptual meetings with the vice president just saying the benefits of this, and I think he grasp onto it pretty well. And then we actually we’re quite afraid that the users would not want to do it because it’s a big change. And most of them took to it. We had a feel that, you know just wouldn’t want to do it but then again, they have to do it because that’s how we do it.

But yeah, over two years we just let them know this is coming, this is coming. We had the training. We had a forum to talk about it. They knew about Drupal at this point, and then with the videos it went smoother than I thought. I wish I had a better answer for you. But yeah, it really takes time the top down approach I think is probably the best way. Thank you very much everybody.

[Applause]