APS10: Drupal 7 for a University CMS

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

Daniel Frommelt: My name is Dan Frommelt. I'm the Director of Applications and Development at the University of Wisconsin-Platteville. We wanted to do a session today on an approach that we took for an open source CMS. We partnered with CompuNET in this regard and they are to help us with the project management, organizing the technology, getting the process flow going, taking care of a lot of the details.

My job with this particular project was to orchestrate the RFP process, and I can tell you, having never been through an RFP before, that was hell.

[Laughter]

Daniel Frommelt: It's definitely something I learned an awful lot, but I don't ever want to do it again. Unfortunately, I'm the only one at the university who has done one the last 10 years, so unfortunately I'll be saddled for a whole bunch more.

In that regard, I was able to get a team of people to work full-time on this web project, so I'll introduce my team here, and then we'll let them go from there.

I've got John Vieth. He is our Web Designer. Mike Steffel, he's our Web Programmer. I'm very grateful to have these two gentlemen working with us. And from CompuNET, we've got T.J. Carter, and Amber Aurora is right up front here.

So I'll turn it over to these guys, and they're the ones doing the hard work, anyway.

T.J. Carter: And I will add real quickly, the RFP took actually longer than getting the site done.

What we're going to do is we're going to walk through the before, the after, a lot of the dynamics that were driving this site, and then we're going to talk a little bit about Drupal, why Drupal, and then some of the migration challenges in there. I'm going to talk a little bit about the background and where we were in trying to go from a high level.

The first thing is where we started. Over the years, the Platteville site grew in, what I'm calling, an unfettered fashion. Organically, there was really no brand standards to guide look and feel, there were no formal objectives or expectations from above to drive and help them make decisions about what should be done.

Technically, there are a bunch of CGI apps bolted around a static HTML core and some FTP and all kinds of incredibly creative things, there was WordPress in there, and a bunch of sites were actually put off into the cloud, cloud-based apps, AluMnation and that kind of stuff. It was, I think, four or five different external things that were out there at that point.

The Web Development Office at that point was, I think, just Dan and students. There were a staff of 10 students. Now we do have the two full-time guys, and the students are still there, too. There was really no process to manage a site because there were no expectations, no real process there. What got done got done and, again, in ad hoc fashion, depending on who might yell aloud is and that kind of thing.

It was a bit of a chaotic environment, and it grew over time into quite an impressive site of over 100,000 pages. A hundred-and-one templates, no standard.

Again, you see up here, everything from this black radio station 'who knows what that is' to AluMnation off in the cloud and bright orange headers, it really was hard sometimes to understand, 'Am I really at the UW-Platteville site?' And this is pretty typical with a lot of university websites these days.

Existing in system landscape was, again, we've shown five things living in the cloud, a bunch of different servers doing all kinds of different things. It really is pretty impressive how it all came together over the course of time, but obviously tough to maintain. A lot of areas that, a failure and what not, six servers, three to four separates OSs, five hosted services; not something when we look at IT operations that the operations team was really thrilled about. They liked a little more consistency, a little more consolidation and what not. Again, there was room for improvement.

Information architecture. Because it grew as it did, and I'm just highlighting if you follow the red circles and the green circles, we could do that in the other areas, too, content was spread in different areas depending upon who felt like putting things in there.

Current students were in multiple different places. It was a very difficult information architecture, and what it led to was an A to Z directory, and that didn't help a ton, either. And then search that was random in how it brought back results. Again, it wasn't something that was intuitive and easy to get to the information you wanted.

The goal, then. A new chancellor came into town, and this chancellor wants to double the enrollment to the university and he really wants to get a consistent message out there, because it's pretty important if you're out there doing some formal marketing that you can build a brand and reinforce that brand.

So really, the goal here was work on the transformative redesign. We wanted a consistent look and feel aligned with the brand strategy for all sites, in capital bolded 'ALL'. 'This is an academic site. This isn't a sports site. This is UW-Platteville. If it's www.uwplatteville.edu, it's going to be in this structure.' And this only happens with the leadership.

We really wanted to bring in a state-of-the-art platform that's going to evolve and serve the foreseeable needs, because, today, it's not just a website. It's what we call a horizontal platform that's going to serve as internet capability, it's going to start to reinforce with some workflow processes, serve as a mashup platform for different apps and information at times. So we needed to have that ability to evolve and grow after that first release got out of there.

We wanted to establish and transfer ownership of content out of the Web Office. The Web Office was taking requests to build pages or edit pages, and in today's world of CMSs, we know that's not the way it needs to be. We wanted people to own their content.

Of those 100,000 pages, there were so many pages that were orphaned. Was it stale? Was it good? Was it pertinent? Nobody knew anymore. With that, real solid, solid ownership concept is something I wanted to put in place.

That helps us change the role of the Web Office. Why have students doing content updates when students can actually go and develop new modules? Maybe they can do integration, maybe they can add real business value, as we would say, in the work they do. We had to clearly cleanse content, the content that was crazy.

And then, last and not least, this is probably one of the most important parts of it, we wanted to institutionalize the stewardship processes. We started, in our consulting terminology we call that 'governance'. What we found out is there is a governance process in the university already that deals with academic matters and the other stuff, and it confused them.

Dan came up with the word 'stewardship', which I think is brilliant because if you're a steward, you're thinking for the good of the whole university or the whole website, not just for your individual needs, and this process to really manage the ongoing evolution of the site. There was a previous session this morning about governance. It's preaching to the choir. You're not going to maintain a consistent site, you're not going to get what you need unless you have that in place. All this does take leadership, and it needs to start at the top.

Where did we end up or how did we attack the problem? The first thing is our project structure. We came in and supported pretty much at a high level project management, information architecture. We provided some real developer resources and help on the technical architecture.

Creative design. We don't personally do creative design, but what we did is we matched them up with an organization that does. We're out in Minneapolis and there's a great wealth of folks out there. So what we do is understand the needs of the client, what they're trying to look for, get a design firm in there.

I strongly recommend it. These guys live and think and breathe what's connecting with people today, what kids want. Whatever your demographics are, these guys are really edgy but they did a lot of Dairy Queen-type stuff, so it seemed like a pretty good mix for them.

We helped with some migration strategy and changed management because, again, this is transforming roles and responsibilities, and that's a pretty big thing to step into. What we did do, though, is we really leveraged the development office, the Web Development team. John, Mike and 10 student developers have done an awful lot, if not a vast majority, of the development on this site.

And there's not a lot of customizations. The theming and the look and feel's been customized, but this is largely an out-of-the-box implementation of Drupal modules. So as some people scare you about it, you don't need to go hog wild with Drupal. and do it if you understand what it can do and shape your solution around it. And I think you'll see the site is quite impressive in how that delivered.

Last but not least, when we started, we had zero content stewards. When we ended, we had over 150. These are the people that needed to raise their hand and say, 'I own this page.' If they don't own the page, it's not coming, and there needed to be a name against each and every page or it wasn't going to move forward.

But it's really important in this case. Again, when this site is done, it's not like our guys are throwing something on Platteville and, 'Here, take it.' These guys own it. They understand intimately how this thing was put together so that they can take it forward and evolve it over time. It's not something that is going to have a long-term dependency on our resources.

So our results, real quickly. We ended up with 10 templates. Period. And there's reasons to this.

One of the reasons is simply, if indeed this is ever going to happen in the future, we want to keep it consistent. It's a lot easier to migrate into a new platform if you've got a fairly consistent set of standards to start with. We'll talk about migration. It was not an easy process because of where we started. But going forward, we're going to have a lot more consistent architecture and data model underneath it, if and when that happens.

From a design consistence perspective, this is just one of the wireframes that drove it, just to point out that above the line, you're not going to change a thing. Too key to the information architecture. So it's not going to happen.

A lot of complaints. 'Library's not up there anymore. It used to be right at the top.' Some people won, some people lost, but again, it really is now driven. We want to put kids in the classroom. This isn't all about finding books in the library anymore. You will get to the library; you just have to navigate to it.

Down below, though, you've got room for navigation on your own area, page titles, contents and modules that can be used to customize your content as you see fit.

Modules to begin with, six of them.

Calendar module. I'll tell you, Drupal calendar, it's really, really powerful. You don't need a third-party tool to do that, and John can talk about that more. But calendar, dates to remember, that kind of drive out of there.

'What's Next', which are bunches of links, social feeds. We're starting with, I think, just Facebook, but obviously Twitter and others will be in Release 2 of the website if people drive it, as the stewardship process drives needs for these things. It won't be done willy-nilly.

Contact information, news and announcements, pretty simple, but again, things that the content owner, the steward, can decide to use to add value to their specific pages as required.

Information architecture. You'll see it's very streamlined. We pretty much broke it up into your life cycle relationship with the university, before, during, surrounding and after. I joke a lot, if you've been to Platteville, it's actually built around a cemetery, so the 'after' really has some interesting meaning out there. But it's very, very clear design for navigation, and very intuitive.

You'll see we locked down some sites which are for internet capability. There is an internet capability now which they never had before. Again, that's pretty transformative for them, so they can start to deal with internal, department-related, administrative data that they don't want to make public to the world in information.

And now I think I'm going to leave it to John to talk about more of the Drupal piece of it. And then Mike will take over and talk about migration, and we can take questions later.

John Vieth: Thanks, T.J. Can everybody hear me all right? Is this thing on? OK.

So why Drupal 7? I've listed a few bullets here to just give you a quick rundown, then I'll talk about each of these in detail.

The reason we chose Drupal 7 is because of just a lot of great features that are a perfect match for a large university. Content types. Powerful and easy theme engine. 

Drupal 7 handles very large information architectures very well. Minimal customizations are necessary, although you can customize, but you can build a lot without a lot of crazy customization.

Basically with Drupal, for a very large website, if your university can dream it, you can build it with Drupal because of the flexibility and the power.

And finally, support and documentation were key compared to other content management systems which includes proprietary content management systems.

Real quick, we'll talk about content types. Content types are a core feature of Drupal 7, and I really feel like Drupal is just really all about content types.

A content type is basically just a type of content, but in Drupal 7 that means that you're building a collection of fields that determine what the editor user interface is when people are editing that type of content. It's just basically what most of Drupal 7 is centered around.

A real important aspect of content types and fields is that fields help control the content and the layout. So you really get to control what your users do by using fields because, with each of these fields, you're prompting them to enter certain pieces of information.

And then in the case of image fields and video fields, you're transforming what they upload to make sure that it fits perfectly into the layouts so you don't need to rely on people to be expert at using some sort of WYSIWYG editor and resizing images because they will never master that, ever. Content stewards, at least, will not.

These fields, when you're working with content types, include everything from image fields to video fields, date fields which are useful for calendaring, file fields so you can attach files like meeting minutes, which are obviously very prevalent in a university website, and of course content, HTML content using fields on which you can apply a WYSIWYG editor for easy editing.

Part of all this content type and field stuff is that with Drupal, you can very easily query your content, then, just like you can query a database. You can query this content using a feature in Drupal that's called Views. Just by clicking around, you can very easily build a view that you can then present as a page or a block in a layout. So it's just very easy to build stuff.

I'm going to just very quickly show you a live demonstration of what I'm talking about when it comes to content types and fields.

Here is a content type. We are in the managed fields tab. It's just, again, a matter of clicking together a bunch of fields of all sorts of different types: boolean fields to trigger whether something appears or does not appear, taxonomy fields for choosing what category a piece of content is in, image fields, video fields, text fields with a WYSIWYG editor.

Then, once you build that content type in Drupal 7, you end up with a very nice editor UI where it's just very easy to upload an image if you want it to appear in this spot, upload an image if you want it to appear in this spot, what section does the website belong. You've got your 'what you see is what you get' editor down there.

Drupal provides you with a lot of flexibility for how you build that 'what you see is what you get' editor. You can control exactly what features people have access to. There's countless 'what you see is what you get' editors you can choose from, if you have a favorite, including Yahoo!'s YUI editor, TinyMCE. We use CKEditor, which we feel is the best choice. It's very popular with Drupal.

Moving on. Theming. Another very big reason we chose Drupal 7. Theming in Drupal 7 is extremely powerful. With theming in Drupal 7, you can take a flat file, whether it's a Photoshop document or a PDF, and if you have reasonably talented front-end developers, you can transform that into a pixel-perfect rendering in the form of a Drupal 7 theme, and you can really delight your top brass by saying, 'Hey, this is what you approved, and now it looks exactly like what you approved on our Drupal website.'

In Drupal 7, everything can be themed and customized, so you don't find yourself implementing the theme and getting stuck where this one little piece you can't make it look like what you want it to.

Everything can be overwritten. Since everything can be overwritten, there's a lot to know, but it's extremely logical and elegant. With a little bit of learning, you can really make it sing.

It's very easy to do this. Sub-themes make it easy to get started because you don't have to build a whole theme. You can base your sub-theme off a master theme. Just change what's necessary in order to get the job done. We use as our master theme the 960 theme for Drupal, which is based on the 960 grid system CSS framework.

And if you're good, near the end we will show you basically a 'before and after', what we were given, what was approved for design and how we implemented it. So I'll try to cover these next ones a little more quickly.

Large information architectures. That's really important for a university website. Your CMS really has to be able to tackle large information architectures, and Drupal 7 is excellent for that. If it's good enough for whitehouse.gov and Harvard's OpenScholar project, I feel it's good enough for just about any university.

And the reason it really works is because you have very flexible and unlimited menus, which means you can grow your website without constraints. You can always add more menus, you can have huge menus, you can have multi-level menus with unlimited levels, you can put these menus in all sorts of spots in your layouts. So you're never constrained with like how you build your navigation.

You can also keep your menu system very simple, if you like to, so it doesn't have to be really complicated.

Multi-site option reduces management overhead for multi-site universities. If you can't get it all done with one website, Drupal 7's multi-site feature lets you branch out to other websites while still maintaining one code base and one server. And unlimited themes and content types for each website just help you accomplish a very large and sprawling diverse information architecture.

T.J. touched a little bit on minimal customization. That's one of the reasons we chose Drupal because, if you know Drupal and you have some experience with Drupal and you know how to build things the Drupal way, you really can click together a huge, very complicated website without really writing a lot of custom code.

Drupal lets you build huge custom applications if you want to, but you really don't have to. And we really didn't when we built our very large website, which is about to go live soon here.

The reason this is important is because it simplifies future migrations. The more custom code you have to write, the more likely it's going to be very difficult to migrate something new in the future, for example, Drupal 8 in a few years, so you really can click together a very large website very easily.

In our case, we did a lot of customization, but it's not really custom PHP programming. You'll find that a lot of times, if you can't get it done with CSS and you have to overwrite a bunch of templates, a lot of times you're just rearranging PHP code so that things happen in a different order or things that you don't want to happen don't happen. So it really simplifies things, and it's easy to document.

And a strong API minimizes the need for a lot of custom code because a lot of the code is written for you. You can just call API functions to get things done.

All of this, still, I don't want to make it sound like it's really 'anyone can do it'. You do want someone with Drupal expertise. But if someone dives in and builds a Drupal website or two, takes like a boot-camp approach and just really embraces Drupal, and they're a technical person, they're going to really be able to make Drupal sing.

And you can't be afraid to bring in outside expertise, too. But usually, if you need Drupal, it's because you have a very complicated website and you really need that.

If you can dream it, you can build it with Drupal. I find with a lot of other CMSs, I'll just use WordPress as an example. I'm a lover of WordPress, but it has limits, and I find that a lot of people do things with WordPress and others simpler CMS where they're basically constrained by what it can do and they just live within those confines.

Whereas with Drupal 7, you can just really think about how you want your website to work and then just go out using Drupal core and contributed modules from the community to figure out how to make it happen. And you will be able to make it happen. Worst case, you write some custom modules or do some customizations, and like I said, in our case, we really minimized the customization that way.

The result is we ended up with, we feel, a cutting-edge Drupal 7 website by doing things this way, the Drupal way, and just really learning how Drupal works and making the most of Drupal.

Another really important reason we chose Drupal 7 is support and documentation. The Drupal 7 community at drupal.org is, I feel, unmatched. There's an issue tracker for every module, so if you have a problem, it's going to get attention. You enter it as an issue. There's extensive documentation, really detailed documentation that's always growing and always evolving and you can contribute to it very easily.

There are discussion forums where you can post questions and then there's also real-time IRC chat. And I'm not exaggerating when I say that 24 hours a day, no matter what time you log into IRC, there is going to be at least a couple hundred people logged into the IRC chat channel. Results vary, but you're probably going to be able to talk to somebody, and I've gotten some pretty good questions answered that way.

Massive and growing hordes of Drupal consultants, which we utilize at UW-Platteville. Open source means more options for support.

Even though it's open source, you can go commercial with your support options. Acquia is the commercial arm of Drupal. If you want to go high-end, you can hire them, and you're basically hiring the people who built Drupal to provide support for you.

There are also other more intermediate-level commercial firms like CompuNET right down here. They do a fine job.

So that's basically why we chose Drupal 7.

I'll tell you just a little bit about our hardware and software implementation. It's a LAMP server. You'll hear a lot of people talk about Drupal and other CMS and suggest that, 'Hey, you can use other databases,' or 'Hey, you can use a Windows server with IIS.' People in the know know that it's all about LAMP, a good standard LAMP server.

Right now, we have the equivalent of four virtual CPUs in VMware Server, a virtualized environment with multiple servers for production, QA, testing and so on. In the testing phase, before we go live, right now we have 4 gigs of RAM prepared to go up to 8 gigs of RAM, which should more than suffice, but yet there's still room to grow with a virtualized environment.

Drupal loves virtualization. I'm running for a demo. I basically have a copy of our entire server on this laptop for security reasons so that we can demonstrate some stuff. So it's really portable that way.

A little bit more information that you can access in our presentation online once it's posted. There are some customizations you can do to improve performance.

And that's it for me. Next, Mike is going to discuss the migration process and its challenges.

Michael Steffel: Thanks, John. Can everybody hear me? Switching mikes again.

Migration. The big challenge was we had 100,000 pages. We were trying to drop that down to less than 30,000, so getting rid of two-thirds of our existing content.

We had many custom applications. T.J. pointed on that with some of our CGI scripts, some of our Perl applications.

There was not a one-to-one mapping between our new and old templates. We gave our content stewards the option to go with four different templates out of the 10 we had. Some of those templates were, they're marked for like the homepage, but we gave them access to four.

There were 100 different templates out there starting out with this project over those 100,000 pages, so we had to go through and basically map it out, say, 'OK, which page goes with which template?'

Not all content was migrated to support existing links. Inconsistent standards were used on old content. Yeah, they were HTML pages. Some of them were nine, 10 years old. They were not as current as they probably should have been.

The goals. To establish clear ownership for each page. Identify who that person is who should be updating that page.

Educate content stewards on the objectives and use of the new CMS. We wanted them to become comfortable with it out of the gate.

Preserve while cleansing existing content. The stuff that they wanted to migrate over, we wanted to make sure that that was a page that they could migrate over and that we took a lot of extraneous code out of it. We don't want to leave stuff just hanging out there.

Eliminate manual entry of existing content. Those two kind of go together because we don't want somebody sitting there cutting and pasting for three months all their content. We want to be able to have them jump right in and start updating.

Enrichment of content and hands-on training of content stewards. Again, it involves them in the process.

Our content owners, what we did with them.

First of all, we established who they were. This kind of goes with the second one, which is prioritize content for launch. We created using a script, an Excel file of all their pages. On that Excel file we also had, 'Do you want it to come over in first round, do you want it to come over in second round, or do you want to completely discard it?' They made those decisions.

We identified the templates to migrate content into. When they came back and said, 'This list of so many pages, we want that to go over first round,' we said, 'All right. Now that you know what content you actually want to migrate over, what template does it fall under? What do you want it to look like?'

And coupling that, we also explained to them what modules they could have on the side, the modules like the calendar or the contact module that T.J. showed you earlier.

The technical end. We actually used the URL in those spreadsheets to get their page to bring that in. Once they identified which pages they wanted to come in, which template they wanted to use, we said, 'Well, we know that URL. We're going to take that one in and we're going to assign it with this template.'

We stripped out any unwanted elements such as images, inline CSS, JavaScript, etcetera, etcetera, etcetera. Font tags, center tags, stripped all that stuff out in the script that we ran across their files.

We used Drupal API to import content as a node and set the template. So their content's coming in as a node and we know what template it's using.

We brought in document files referenced within the content. A university has hundreds of thousands of documents out there attached as PDFs, doc files, whatever. We took all that stuff into their implementation. Not manually. Through the script.

We cleaned up links once the content was migrated in. What does that mean? Well, if you're only taking in a 30-year content, that means two-thirds of your links to that other content are probably bad. Also, when you're taking in Drupal, it's no longer that URL that you started with. It's now a Drupal node ID.

So what we did was go through, and while we were importing the content, we put a table in our database that had the original URL and the node ID that it is coming in as.

When we ran the script at the end, basically what it did was run through the content of each node and, 'Here's a link. This is what it used to be. Here's the node ID we're putting in its place.' When Drupal displays that as a page link, it actually goes directly to that other page and doesn't link to a node ID but links to that actual page.

The results.

Audience 1: [Indiscernible]

Michael Steffel: Sorry?

Audience 1: [Indiscernible]

Michael Steffel: Yup, yup. They don't seen the node ID at all. Even if they mouse over it, nothing.

Content stewards were involved throughout the entire process. I can't emphasize that enough. That makes them comfortable with the whole thing. It also gets you out there visiting with them and kind of promotes the website as you're going forward.

Content stewards now update their own content. Goes directly with the next one: Web Development Office can focus on developing functionality.

Now we don't get any email at three o'clock on a Friday afternoon saying, 'Hey I need this live by Monday at nine o'clock.' Oh, and by the way, when you call them back at 3:30 or four o'clock, they've taken off for the day and they forgot to give you a key piece of information you need to do that by Monday morning at nine o'clock. They're in charge of that.

That also frees our web development team up to do other programming. We can now concentrate on adding more modules or other functionality.

Added bonus? The process results in hundreds of people working with the environment before launch. All those content stewards are in the site. They're tweaking their information, they're going through, and they're creating pages, they're giving us feedback, 'Hey, what works and what doesn't work', so we can tweak it before it goes live.

I guess that's me. Wow, I'm all out. Now a sneak peek.

T.J. Carter: I will just add, we're not launching next month, but it's a new process. The RFP actually took longer than getting the site up.

And I do want to just call out Ms. Amber Arora here was the project manager. She is the one that both championed the technical architecture, and there were a lot of tough conversations. I mean, even Drupal 7, when we won the contract, we said, 'dual', because Drupal 7 was so brand new. So there were a lot of different things.

And she's been working with the content managers and their various functions. It's a lot like herding cats. I call it 'Dr. Octopus keeping that nuclear fusion in bay'.

So I just wanted to call her out because she didn't get to speak. I really didn't do much work on it, but, yeah.

Amber Arora: It's a team effort.

John Vieth: Definitely a team effort. Can everyone hear me all right?

Audience 2: [Indiscernible]

Michael Steffel: No. With the help of one student, he and I met, and actually Amber and he and I met a couple of times, we decided how we wanted to proceed with migration, what we wanted to bring in. And he created kind of his own module.

So that's how we're doing it. And it works for our static content, it works for WordPress, it works for a couple of the other things we had out there like AluMnation. It worked very well.

John Vieth: The Drupal 7 API in your PHP code gives you a lot of tools like to add a node, to do lots of things so you don't have to write every line of code. Although it was a custom module and it's one of the very few examples of customization that we had to do, it worked really well.

Let's give you a sneak preview here. This website is not live yet, but we can give you a demo. First, I would like to show you basically what was given to us as specifications. This came in the form of PDFs and Photoshop documents.

Here I have our Photoshop document. It's just a Photoshop document. There's layers, there's text, but there's no HTML there, there's no CSS, so that has to be taken and transformed by a front-end developer, which in this case was myself.

We also had a very talented developer from CompuNET who handled certain key interactive pieces so that I could focus on theming in general and he could focus on some of the dynamic features of various carousels and rotating things.

So we got a Photoshop document, we have a couple different PDFs that give us things like wireframes and information architecture stuff, as well as just really, really flat views of various templates. So you have to be able to transform this stuff into...basically running on a virtual machine here on my laptop is our live website. So I think you can agree.

I ran this stuff by you very quickly and you can stop by the CompuNET table in the Exhibitor Hall to take a little bit more time to absorb it. But I think you'll agree that basically with Drupal 7 we were able to build this really dynamic, really visually impressive website, and it looks exactly like what was agreed upon by our design committee, which was a very intense process with a lot of input from us, and we were able to just basically make that happen.

We were able to basically develop some very complicated layouts. Drupal 7 makes it very easy for you to plop a video in here and a photo there that's sized automatically for the layout, and the 'what you see is what you get' editor can flow there. And if you are so inclined, you can add photo gallery thumbnails down here and it just all falls into place.

We've got a couple of modules, a Calendar module and a 'Contact Us' module. This is just for demonstration purposes so you can see what our system that we built allows you to just insert there. All of this stuff is interactive. If I click a photo gallery thumbnail, I can go through a nice slideshow. Every image has alt tags and title tags and captions automatically pulled from the database.

That is it. Here's a view that we built basically to handle all of our blogs. Drupal 7 lets you have unlimited blogs. All of this looks exactly like the templates that were approved so we can delight our decision-makers and committees that way. They really feel like what they approved was honored.

And that is it. Hope to go live very shortly here. I'm very proud of what we built, and it was really, truly a real team effort. I'm happy with the results.

Any questions?

Audience 3: What is the training schedule for all your content stewards?

Michael Steffel: Very good question.

Amber Arora: Yeah. We are still going through the training process right now. I suppose I have to use that.

We are scheduling the training for the 150 to 200 stewards right now. What we are doing is we make sure they're able to know how to create pages, edit pages, but then at the tail end, we bring in all the content that's migrated for them. So they start to see, 'OK, these are the tweaks we have to do if we want to modify anything.'

This is all before we go live. They're getting hands-on directly on modifying content before we go live. So it's doing a hands-on training, but then they also are getting in-tune with, 'OK, this is what we have to deal with going forward.'

T.J. Carter: Yeah, they can't ignore their responsibility. There's a lot of images on these pages and there's not necessarily a lot of images on their old pages. These modules aren't on their old pages. So we can bring the content over. But if you want a calendar, you've got to create your calendar. If you want an image gallery, you've got to create the images.

So they're in there now working through in real time, beefing it up, and another added benefit in my mind is now we're starting to get dozens and soon hundreds of people working the site pre-launch, which is just a wonderful functional and load test.

John Vieth: Sounds like we have five minutes left, so we have time for some more questions.

Yes, sir.

Audience 4: [Indiscernible]

John Vieth: If you stop by the CompuNET table in the Exhibitor Hall, they will give you a demo.

But I will say that some people will complain that in Drupal you have to choose your WYSIWYG editor because there are choices and it doesn't work. As soon as you install the site, it's not there yet. But I think that's a huge plus because there are so many choices you can choose, Yahoo!'s YUI, TinyMCE. We went with CKEditor. You can totally customize them.

T.J. Carter: The bottom line, though, is it's a very friendly-user interface now. One of the reasons that we agreed to go through the Drupal is that there was a key goal here, all these content editors, we needed to pay attention to make it easier for all of them to use.

So through the editors available and the other things, it is really now quite user-friendly. It's very close to where WordPress added. It was a huge, huge Drupal 7 feature.

Audience 5: [Indiscernible]

Michael Steffel: Also by design, we took a lot of the CKEditor functionality out. We didn't want people putting in their own styles, their own background colors, colored fonts. We didn't want them sizing the fonts up to 64. Yeah.

We gave them headers that they can put in. Actually, the page title is Header 1, so we started with Header 2. Header 3, Header 4, we gave them a paragraph. We gave them a few other things to use that they can edit their text with, but we didn't go hog wild and let them destroy their site as soon as we launch it.

John Vieth: You can also, in your content type setup, you can elect to not allow the WYSIWYG editor for certain text fields. So if you want them to put in a block of text and you want it just pure text, you can just turn the WYSIWYG editor off of that and make it so that HTML tags are not allowed. So you really have a lot of flexibility.

And you can choose various profiles that are available to your different users so that some users have just a few buttons up here and your more advanced users, maybe our students, can have the whole array. So it's really customizable.

T.J. Carter: If you're really concerned about how this look evolves, you can do a workflow, so people can do a graph that can be approved if necessary by whoever you do. We're not doing that. We're doing a 'trust, but verify' approach right now.

John Vieth: Any other questions? One in the back?

Audience 6: We had an expert who was telling us that we could start out with Drupal 6 instead of 7 because...

John Vieth: Sure.

Audience 6: And it doesn't really sit well with me because of the upgrade.

Michael Steffel: Go 7.

[Laughter]

T.J. Carter: Let me just say that we were that expert...

Audience 6: I want to tell my boss, but she's trusting these other guys.

T.J. Carter: No, no. We were that expert, and that's exactly what we said to start with. We're afraid of 7 because it's brand new. We're starting in April, came out in January, and we're contracted to deliver a site. Even though they're doing a lot of the work, it's us that's on a fixed price contract that have to be successful.

So we were a little hesitant. We were talking about that yesterday. We made the right choice. There are still some modules that are out there, but again, choose carefully. And I don't know why you would want to do that today. The benefits of 7, from usability, even functionality perspective there, and it's, look what we've done.

John Vieth: The generally-accepted wisdom that's out there right now says that if you have a Drupal 6 website, Drupal 6 is still really strong, and you might have some hiccups, so why migrate now. Don't feel like, 'Oh, 7's out. Time to migrate.'

But if you're building a site from scratch and you're not yet using Drupal, I'd say we're at the point where the default answer is Drupal 7. And only if there's some really... It would break my heart to see somebody build a brand new Drupal website in Drupal 6 right now.

T.J. Carter: I would be happy to share experience with her.

Michael Steffel: Yes.

Audience 7: Are you using, like is it one big site for everyone or is it, you have a multi-site?

Michael Steffel: The question is, is it one big site for everyone or is it multi-site? It is one big site for everyone.

Audience 8: What are you using for access control so that people...?

Michael Steffel: What we are using for access control is a combination of Workbench and LDAP. They of course log in with their LDAP account and then we allow Workbench access into their respective roles and areas.

John Vieth: The Workbench suite is built by a company called Palantir. It integrates workflow, it integrates authorization access control, it gives you everything you need, whereas in Drupal 6 you had to string together a few different modules. It's good stuff.

Michael Steffel: One of the first things you see on this is right up here at the top, it shows basically all the different organizations on our campus. If Biology logs in, they see Biology.

Amber Arora: It's also organized in different things from information architecture. Our menus are extensive.

John Vieth: Workbench is a great reason to go with Drupal 7 instead of Drupal 6.

Any other questions?

Daniel Frommelt: All right, thank you very much.

[Applause]