SAC1: It Isn't About the Feature Set: Selecting a Web Content Management System that Works for You

Anthony Dunn, WCMS Coordinator, CSU, Chico


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


[Intro Music]

Announcer:  Youíre listening to one in a series of presentations from the 2008 HighEd Web Conference in Springfield, Missouri.

Anthony Dunn: How Internet beams are driving social media in the twenty first century. Actually no, I came up with this because when I did this presentation initially, it ended up being like 50 slides of bullet points, and I didnít want to do death by PowerPoint, so I decided to change it. If you donít like low caps you should probably leave now cause youíre going to get a dose of them. I didnít want to kill you with a bunch of bullet points. Actually it isnít about the feature set. What I am going to talk about today is not what content management system to choose, but the process that we went throughóa couple of timesóto find a way to choose a content management system that worked for us. Every university has different needs. Iíve talked to a lot of people about how their website is organized with the institutional infrastructures, what their politics are like, and all those drive what type of product is going to work for you, and thatís really what this presentation is about. I have a couple of questions to start out with. How many people currently have a web content management system? Ok thatís good. How many people are looking at getting a web content management system? I see some of the same hands!

We went through that exact process. We got something that we realized didnít quite work well. Our back ground at Chico State is, in 2003, we took our first exploratory look at web content management systems. We were total newbies. We didnít know anything. We were just like, "Ooo! Web content. What the heck is that?" So we sort of poked around and talked to maybe ten different vendors, went through kind of a process. Turns out there wasnít any money at the time. We ended up with the top two that we looked ató we didnít end up buying anything, of courseówere Red Dot and Collage, just to let you know what we had seen at the time. And so, we learned a lot from that process but there wasnít a political will or money to do anything about it. So we didnít. And we came back in 2005 and sort of repeated the same process. We looked at vendors, and saw a bunch of Web X demos. We were going to try to do a single source for Red Dot at that time, but because of politics, we ended up having to issue an RFP. Red Dot didnít respond to the RFP, even though we told them that we wanted their product, so we went with Serena Collage, which we are not happy with. Weíll talk about that in a little bit. And then, because that wasnít a good product for us, we decided to revisit that issue again. And in 2007, last year, we came back and we said, "Okay, well, weíve learned a lot from our experience with Serena Collage and looking at that, so letís come back and revisit that, and letís come up with a process that is going to give us the product that we want." This presentation is based on that. Right now we selected our content management system, I guess, probably about a year ago, and then thereís all the politics and paperwork and procurement and all that, so we actually got the product in March and then, of course, we had to wait for the DBAs to put the Oracle database up, and so it was actually like July before we got it. You all work at universities, right, so you know how long things take. So we are now starting to roll out our content management system. And youíll notice I havenít said what it is because it really doesnít matter what we bought. That might be the worse product for you. I was just at this companyís user conference two weeks ago, and we talked to a lot of people that were very happy with it. And we talked to a lot of people from one college who were extremely unhappy with it. The reason was that they got a product that didnít really work for what they needed. And thatís what this presentation will help you determine.

So Serena Collage. It just didnít work for us. They made a lot of promises, like that it was supposed to work with Mac browsers; it didnít. I had problems like you had to have a specific version of Java installed on your computer for the end users, so that was a real hassle for us, because itís like, I donít want to go to everybodyís office and put a specific version of Java on their computer. Thatís stupid. Things didnít work, it had reliability issues, it would basicallyóif you just let it run, like the applicationís runningóafter about two weeks or so, it would get really stupid and say, "I donít know, Iím supposed to publish stuff to the web, Iíve never heard of the web, I donít know how to do that," so weíd have to restart everything. And so it didnít have functionality. It also forced us to do things in ways that we didnít want to do them, which was really, fundamentally, the biggest issue. In order to do things like upload multiple files at a time, which people are going to want to do, especially people with lots of Word documents, you had to give somebody administrator privileges to do that. We didnít want to have to do that, but at the same time, people were demanding, "I am not going to upload a hundred PDF files one at a time!" So then we were kind of caught in a situation, and we were saying, "Well, we donít want these people, like department secretaries, to be administrators of the system." But the only way for them to do their job is to make them an administrator; thatís a lose-lose. You should try to find a product that doesnít force you into a lose-lose situation like that.

Youíd better be saying nice stuff about me on Twitter, thatís all I can say. Alright? Just to make a point here, if you are in the back channel typing away, I will be checking after the session what you say. Thatís ok; I have said smarty things on twitter before. So what we came away with, because we had actually thought weíd done our homework really well that time we went with Serena Collage, although it wasnít our first chose, it was pretty close. What we came away with from our experiences with Serena Collage was: you know the future check list and the Web X demos really donít mean much. It isnít what a product does, but how it does it that is much more important. So what we came up with when we did our selection last year was we said, "We need to have a process that is going to help us pick the right thing." So we decided we wanted to plan for success. All I can say is whoever planned this was not planning for success. They just were not planning for success, because obviously people donít pay any attention to that. So we came up with basically a five step process for us that allowed us to get a product that really worked for us, and it is working for us.

So those main stepsóand these are kind of the take-awaysóis you really need to understand what a WCMS will and wonít do for you. That is really critical. One of the things that weíve discovered in talking to people is that they go into this process of selecting one, and they really donít understand what a WCMS is going to do for them and what problems it is not going to be able to solve. And thatís a critical issue. The second thing is that you really need to involve the right people. The first time, around we didnít involve the people who were actually going to be using this system; it was all the tech guys, who said, "Well we know the specs and everything, so weíll pick the product." What we found out is that the end users didnít like it. So the second time around, we made sure to involve them and also to involve more people from a wider swath of campus so that we had a greater buy-in. So that it wasnít so much that we were getting people to say, "Oh I like this one," but it was to say, "Weíre doing this process. Do you trust us to come back and make a recommendation? And you can ask whatever questions you want." So they werenít necessarily directly involved in selecting it, but they had a say in the process and that was important. You also have to decide: what problem are you trying to solve with a WCMS? This is the question that no one seems to ask. "Oh we need a WCMS." Well what are you trying to do with it? What is it intended to fix? If you donít know what that is, it isnít going to fix it. Another really critical step is knowing your content processes, and weíll talk about that. And then come up with a process, which we did, that is going to give you the product that meets your needs. And we will go over the process that we did.

So learning what a WCMS will and wont do. Well, Collage did a lot of that. The first thing to realize is that a WCMS is a tool. You know, it isnít going to solve all your problems; itís a tool. Itís like this guyÖ no itís not that kind of tool. Itís a tool, it does certain things, and it isnít going to solve your problems, but can help you with certain aspects of it. It can help you manage your content, but wonít do that for you. It can help you manage your look, but it isnít going to do that for you, but it can help. It can help you manage work flow, but it isnít going to manage work flow for you. People still have to be involved. Itís not a construction crew; it isnít going to build your website for you. People still have to do all the heavy lifting. People have to do all the designing, writing, content updating, and all the organizing. So you have to realize that depending on what the problems are with your website, content management system may or may not help you with your problems. And thatís the first thing is to get realistic about it and look at what it is going to do. If the problem is nobody updates their content, is the content management system a solution to that problem? Maybe it is or maybe it isnít, but you really donít know that if you donít know whatís causing those problems. But it does have benefits. One potential benefit is less fail. Weíre looking at it and if we identity the proper issues and are realistic about what it can and cannot do, it can actually help us address those issues so we have fewer problems, but it isnít going to solve them for us. And that is the critical thing to understand. It isnít going to solve anything for you.

The second thing to really do in this process is identify the right people. I have a feeling that it is not these guys. I have a feeling I do not want these guys on a team selecting a content management with me. They seem awfully proud of their little invention here, but I have a feeling theyíre not what I really want. So, in selecting the people to be involved in this process, the first time around when we did it, it was basically just an IT group. We had a bunch a people together and looked at features and stuff. The second time around, we made a point of including a much wider range of people. The first thing we did was included administrators on campus. And so itís very important that they at least are aware of whatís going on and have some say in it, because they have expectations and sometime you just have to set what those explanations are and do a lot of educating. We had administrators who thought that a content management system was going to solve every problem on the planet. You know, that it was just everything plus the kitchen sink. And so there was a lot of education on our part to get them on board. And then obviously tech staff. I donít think I need to belabor that point. And then another critical thingóthis is where I get in troubleóyou need to have your content contributors on board as well. Somebody said when they saw this, before WCMSÖ after WCMSÖ right? I hate to say this about our wonderful content contributors on campus, but sometimes itís inevitable that you feel this way about them. And you need a campus-wide buy in. I canít stress this enough. The first time around, we didnít have buy in, and when things didnít work out well there was a lot of finger pointing and it was all at us. And rightly so, because people said, "Well, you picked a crappy product because you didnít ask us." Well, that actually probably wasnít true; we didnít pick a crappy product because we didnít ask them. But because we didnít ask them, I couldnít point the finger back and say, "Yeah, well you were part of this process, so you have to take the blame as well." It is really important to get as much buy in as possible. If you donít have buy in from a wide range of people on campus, you are going to have trouble down the line. Unless itís a huge success and everything goes great, then everybody will take credit for it.

The next step is to identify the real issues. This is what our website looks like; we just post it up outside campus every morning. So, identifying real issues. One of the things that we encountered was that we would have people say things like, "We need a web content management system to manage our content." But when we started asking questions, we realized that what they meant was that their sites were full of outdated content. They thought that a WCMS was a solution to their problem, but they hadnít really identified what their problem was. So their site is full of outdated content. Ok, why? Well, the real problem is people donít keep their content updated because they donít have the staff to do it, they donít have the expertise to do it, orótrust me, how many have this one?ówe just donít care about our website. Right? Oh, I canít tell you how manyÖ But itís your website!

So it is really important to identify what the real problems are. Sometimes you have to ask a lot of questions of people. We had a lot of people coming to us saying, "We need to have this WCSÖ blah blahÖ" Why? "Well itís going to solve our problems." What problems? "UhhhÖ" Whatever. So you have to ask these types of questions to get down to the real issue. Whatís the real question? If this is your problem, will a WCMS solve that problem? The answer to this one, I can tell you already, is no. If people donít have the expertise or the staff or the time, it doesnít matter what tool theyíre using; theyíre not going to do it. Another one is, "We need a web content management system to manage our siteís look and feel." Why? Whatís the real problem? After talking to them, we realize that they think their site is ugly. Well the real issue here is maybe this person just doesnít like the look of our website. Or maybe there is a dozen different broken and old designs scattered around the site, and thatís what theyíre complaining about, that thereís no consistency and thereís no design standard. So you have to ask the question: will WCMS solve these problems? It kind of depends on which one of these problems is the real issue. I mean, if thereís no design standard, can a WCMS solve these problems? It can help. Can it help if the person just doesnít like the way the website looks? Not going to help with that one. So really spending the time to ask the questions of people: what is the real problem we are trying to solve here? And is a web content management system going to be able to do that for us?

Here are some issues that could be real issues. The web has become increasingly important that we need standard processes for managing our content. Okay, Iíll go along with that. Maybe youíre going to get that and maybe not; with a web content management system, it depends on how you implement that. Timely, rapidly changing content is important to us, and we need tools that will help us manage news announcements and calendars. Will a web content management system do that? It depends on which one you get and how you implement it. We are starting a new branding initiative and need a better way to manage the look and feel. Certainly you donít need a web content management system to do that, but could it help with the process? It could help. And notice I am not hugely endorsing web content management systems as a solution; theyíre just a tool. They arenít going to solve a lot of your problems. If you have dysfunctional processes, they are not going to change with a web content management system. It may not be the solution to your problems, and it may make things worse. If this is you, and this is the WCMS, and you have not identified your actual issues and donít understand your content processes, it might make your life a lot worse then it already is. That is something to keep in mind. Before you jump in to a content management system as a solution, you really need to understand what it is going to do and not do for you.

I love this picture; I assume thatís real. One of the things that we got out of going through this process was that we learned a lot about our content processes. We really didnít have a clear idea going into this how content was managed on campus. But after we did the Serena Collage, we had a much better idea of how content was managed on campus because of all the complaints we got about what Serena Collage made people do that they didnít want to do. Here is a generic content process. This is my personal content process. I get a phone call or my boss says something, "We need a page on our website that says blah blah blah." Okay. Somebody says we need a piece of content, so I sit down and wax something out. I play around with it and maybe send it to my boss or maybe I just look at it and go, "Yeah, this is ready for prime time or not ready for prime time." Edit it some more. Then I goóafter Iíve written itóthen I go, "Where does this really go on the website? Well, Iíll just stick it here." And then I publish it, and then we go around and around and around. So thatís a content process. Is it the best content process? I donít know. Realistically, itís the one that I use when I am doing stuff. You may have a different content process, but if you donít know what the content processes are, then youíre not going to be able to find a product that works with those. And thatís critical. We found that out through painful experiences. You have to find a product thatís a good fit for your processes. And this is the thing you have to realize, which was hard for me to accept: logic, in content processes, is not as prevalent as you would like it to be. People have content processes, different clients on campus, different people on campus do things in different ways, and they donít want to change that. So you have to have a product that is going to accommodate that. If you force what they see as a needless change on them that is not a value add, theyíll say, "Oh, I am willing to give this up because I am getting something so much better." If they donít see that, theyíll say, "Why the hell do I have to do this when I can go into Dreamweaver and do whatever I wanted before." And youíll say, "Well, itís the content management system," and theyíre going to say, "Bologna!" They are not going to be happy, so thatís not a win. So what we had to realize was that it didnít matter how logical the process was in Serena Collage or whatever product, if people didnít like it and it didnít accommodate the way they worked, they werenít going to use it. So our goal was to try to lower the bar to people updating the content. That was one of our goals. So if you force needed changes to their workflow on them, that raises the bar on them and thatís the opposite of what we wanted to accomplish. So regardless of what we thought made sense, we had to stick to our goal, which was lower the bar. Ok. If thatís the way you want it, weíll accommodate that.

And understanding your content architecture. Now, we got lucky with the product we selected, in that, we did a lot of testing, but we did not really understand how the product addressed certain elements of content architectureóin this specific case, sub domains. The product that we bought doesnít understand sub domains. So if you have like biology.college.edu and chemistry.college.edu, you can set those up as sites, but you canít let them know that the other exists in the product, because if you have a link from biology.college.edu to chemistry, then hereís a piece of content in a different but related site and it needs to be published too because it is being linked to. And so it tries to publish the biology.college.edu site to the chemistry.college.edu server. Turns out, we got lucky because 98% of our sites are under www.csuchica.edu so we are like, ehh, thatís not a big problem for us. One of our sister campusesóI wont give away their name, except itís something like Cal Polyóthey also bought the same product, and they do everything in sub domains, so every department has their own sub domain. They are in hell. With the same product. So you need to understand how your content is put together and you need to make sure that the product you select works with even the architecture of your hardware. Event that fundamentally can make a big difference between going, "Yeah, this is great. We love it. We can set up and do all this great stuff," and talking to my cohort at another university who says, "we hate life, we hate existing" with the same product. You need to be aware that your content processes and architecture are going to make a huge difference.

Then you need to develop a selection process that works for you. Yours may be different than ours. I am going to go over ours, but Iíll tell you the three main points to do are: 1) look at a lot of products, 2) youíve got to do hands-on testing. You have to do hands-on testing. Donít just do Web X demos, and 3) you have to have a clear criteria. So I am going to go over our process real quick and give you an idea of what we went through and what we came up with. Talk a little bit about why we came up with our process. And again, yours is going to be different, but it should encompass a lot of the same components.

We had two years of experience with Serena Collage, so we had a lot of experience with what didnít work, and that really helped us. What we learned is a lot of the limitations with a WCMS. We didnít really have realistic expectations when we went in, we didnít know a lot of how this product worked, and we didnít understand our own processes, so we learned a lot about how people use a WCMS. And that really helped us. Somebody, last time I gave this presentation, asked "What would be the number one thing that made you a success this time?" and Iíd say, "Failure the first time was the number one thing that made us a success the second time." And Iíd hate to recommend to all you guys need to go out and just pick a WCMS , install it, have a huge failure with it, and trust me, the next time around, youíll learn a lot. I donít want to recommend that but hopefully you can learn from our experience and take away some stuff from here and do a better job. Our experience was not a good one; interestingly enough, Serena Collage is no more. There are no tears on our college because of that. The support was horrible for one thing, but anywayÖ enough about Serena Collage.

The first thing we did was we said that we need buy in. We need to get input from the campus as a whole, so we created a WCMS committeeódifferent from the CMS committee and different from the LMS committee. You donít want to confuse any of these committees. And this was the representation; we had people from various colleges, academic publications, enrollment managementówhich would be admissions, rightó university housingóI donít know why they were there, but what the heck, the more the merrierópublic affairs, the library, IT, provost office. We tried to get a lot of people involved so that people would know what was coming and felt that they could have some input in the process. These people were not involved in the day to day testing. We had, for that, a WCMS technical team, which basically consisted of the people who were dealing with Serena Collage. There was the CMS technical lead (me), our system administrator, one CMS developers, and an advanced user. Interestingly enough, this person was an administrative assistant, and when we got into the provost, she became the executive assistant to the provost, so we had an in with the provost office when the new system came on board. These were the people who sat through all the demos, did all the hands-on testing, and everything. Then we reported back to the committee at large.

The next thing that we did once we got the players in place was we said, "Well what are the issues that we are trying to solve?" And some of them were issues that you might not think of as a WCMS. One of the important issues that our CIO identified was: the reasons why we are doing this, and the reason why we are spending more money coming back, is that we really need to get ahead of the proliferation of these one-off CMSís that people are buying. Weíve got people doing dot CMS over here, and people with this locally grown piece of Ö trash Ö that somebody had written, that were just horrible products. And so then it was like, "Ok, the campus is fragmenting, and everybody is getting their own content management system and that isnít helping some of the underlying problems with our website, such as standards and branding." So we need to get ahead of that and offer something to the campus that is going to help them. They donít have to spend a lot of money, we donít have to spend a lot of money, and that will help. We also need to find a better way to manage the look, feel, and brand of our site, and we knew that a WCMS wasnít going to solve our problem, but it was going to give us a tool to help manage it, so we still had to get people on board. At Chico State, the culture is: web came into existence and nobody really cared, so everybody did their own thing, and now we have a culture of fifteen years of everybody doing their own thing and nobody saying, "You have to do this!" because theyíre just going to go, "No I donít." And thereís nobody to wine to, or to say that they have to do that. Thereís no daddy figure. The thing is we had to make it a win/win, had to entice people into it. So it can help us manage that, but only if we can sell it. We knew we couldnít sell Serena Collage the day we got it; we were like, "Big mistake."

And this is the same kind of thing: increase design structure throughout the site. Is it going to help us with structure? Eh. It depends on what people do with it. And address accessibility issues. Big if youíre familiar at all with the CSU system, is that several CSUísónot ours thank goodnessógot sued for web accessibility issues. So the chancellorís office, being the head of the whole system, sent out a memo saying "Though shalt make all web pages accessible." Itís like, "Do you know how many web pages there are on our website?" So we are in the middle of what is called ATI. This was sold. Now, do I think that the content management system is a great tool in dealing with accessibility? No, I donít. But politically, that was a way to get money from the president and the provost to help pay for it. "Ooo, this is going to help us with ATI." That was a selling point. The most critical one was to lower the bar for users to keep their content up-to-date. That was issue number one. Whatever we did with this system, it came back to: how do I make it easier for people to keep their content system up-to-date? I canít make them want to do it, but how do I make it easier? And a real critical point, people: when it comes to change in the way people do their job, they donít want it. People donít want to have to change the way they work. Now going from Dreamweaver to a content management system, depending on the content management system, itís not as traumatic as you might think, particularly if you have been able to sell that you donít need to know every HTML, itís going to help you do all this stuff, and it will make it easier to manage your content. If you can sell that and not be lying through your teeth, youíll be ok, because theyíll say, "Iím willing to try this if itís going to make my job easier." So you have to be able to sell that, but it also has to be able to come through. One thing we discovered is that if you make people do stuff that they donít think they should have to do, or it makes them do weird work-arounds, like the whole thing with uploading multiple files. What we did, once we discovered that we said, "Thatís it. We are not going any farther with this product." We just couldnít roll it out to people because everyone that we rolled it out to said they wanted to do this and we just could not make them an administrator. And they go, "Well, this sucks. I hate this thing. I have to upload one file at a time." You know itís not making anybodyís job easier to do that. Another thing we discovered is that no matter what you think of work flows, people hate them. How many of you are using workflows with your WCMS? Ok, now how many of your people like them? They donít like them, ok? You know we have a few clients on campus who are really uptight and want to control everything, so they deal with it. But most of the clients that we have dealt with on campus go, "Ooo, workflows. Oh we get approval and stuff." And the first time their department chair comes to work and thereíre twenty emails in their inbox saying "You have to approve this! You have to approve this!" and they go, "Turn that crap off!" The process on our campus, and again, this is knowing your content processes; the department chair goes to the department secretary and says, "Put this on the website." Itís pre-approved! They donít want to get an email that says "the department secretary has uploaded this to the website. Please approve it." Theyíre going, "I already did. I gave it to her. It was ready to go." So everybody is use to having that, what we call a trust model. Itís that people who are uploading things to the website are trusted by the people who are in charge. We donít need to impose anything extra on them. What we discovered was: if the thing makes you do a work flow, donít get it. Thatís for us. Maybe for you, thatís ok, but we needed a product that had optional work flows.

Ok, letís go through this pretty fast. We started out with a three phase process. The first thing we did was initial review. We basically came up with a list of features and technical requirements. A good example: Serena Collage would hang all the time. Well how would you like, at three in the morning, getting a phone call saying, "Our website is down because the WCMS hung"? FAIL. We didnít want our web presence to beholden on some crappy piece of WCMS software. So we needed something that would publish batch publish. We didnít want dynamically generated pages from the WMCS. So the products that I actually looked at and likedólike Paper Thin; not saying that itís a bad product, but it used a dynamic publishing modelófailed right away. They got marked off the checklist right away. So we came out and looked at a lot of products and came up with a list of features and technical requirements that were just pass / fail. We went to CMS matrix; if you havenít been there go there. They have a lot of stuff there. We sent off questionnaires and picked out the ones we liked and didnít like. We sent out a detailed questionnaire to some of these places. What is it like? What does it run on? What does it do? Does it do this? And so we got those back and filtered those down. We started with over thirty products and, based on that, we filtered it down to six that we wanted to see. And there were some grey ones, but we had a solid set of six that we could look at. And then we contacted the vendors and we gave them a demonstration agenda. We said, "Ok, step two is a Web X demo, and this is what we want you to do. And if you donít pass this, then you donít get to go on to the next step in the process." Now I have all these files and stuff. If you send me an email, Iíll give you my business card and give all these files to you. This may at least give you a starting point.

So we had this whole demonstration agenda, and we had a checklist. As we watched the Web X demo, we said, "Ok, so how easy is it to move back and forth between different projects in the WCMS? Oh, one click. Check! It passes. Uh oh, you have to log out and log back in? Doesnít pass. "And that was kind of how we rated them. And then we said, "Which ones do we like best based on what we saw?" Then the next phase was that we got hands-on testing. One of the things that we learned from the first time around was that if a vendor will not give you sand box to play in from scratch, that isnít managed and all set up for you, than donít buy the product. You donít know how the product really works until you use it. You can sit through a million years of Web X demos, and until you use the product, you wonít know how it works with your content processes. We learned so much from doing this. So we developed a task list. What are we going to do? L-Dapt integration was important to us, so we got to make it work with L-Dapt. So vendors gave us an install, we installed it, built up templates. And the next thing we said was, "Ok, letís go a little more real world. Letís do user training." And so, you know, we actually sat down and got people from current WCMS users using Serena Collage. We actually did a two-hour user training with some of the products we were thinking about. So we made an investment on this to make sure we were getting the right one. And we got their feedback on a real project. Then we went through and evaluated all the products and everything, and then picked the one that we liked. We sent it to the main WCMS committee and then the CIO for approval. This is what we recommend. This is the process we went through, and this is why we recommend it. And we did a full demo of the final selection to the WCMS committee and anybody who wanted to come. And we got approval from the CIO and then we bought it. And we lived happily ever after. Even though we did all those things, we still got lucky on the product with a few things and it worked. But I canít stress enough doing things like hands-on testing.

So take-aways. I love this. Understand what a WCMS will and wonít do. If you donít know what itís going to do and what problems itís going to solve, you wonít know if it will work. Youíre going to have to be realistic with what it is going to help you with. It isnít going to solve everything. Understand your content processes and architecture. Thatís what killed us with Serena Collage, and thatís how we got lucky with our current product. A) We did a lot of good homework, and B) we just got lucky. So you have to understand this stuff or itís not going to work for you. Again, we talked to another college that absolutely hates the same product we have now and thatís because it doesnít work for them. Every product does different stuff and has different capabilities. Hands-on testing is not optional. Donít ever go out of here and buy or get an open source WCMS or anything without using it first. Take the time. It is totally worth it. We came down to two products that we thought were very similar. We did an install of both of them. One of them we thought, "This is great! We love it." The other one we thought, "Oh my gosh! This is a Hollywood movie set."You do the Web X demo, it does everything. But when you actually get it yourself, for example, images can only be uploaded by an administrator. And images all go into the same folder on a website. And only an administrator can put an image on a page. So when youíre on in the Web X demo, the guyís logged on as an administrator and youíre not getting too picky about where the images are. So you know, it was things like that made us go, "Oh my gosh, this thingís not ready for primetime." Because we were actually leaning toward this one product until we got hands-on testing, and we were like, "No doubt." So features do matter if they fit your needs and processes. So donít go away with here saying features donít matter, because they do.

Ok, I want to thank Pat Berry, our systems administrator. I canít do this without him because heís the one that makes sure stuff works. Even though I am that one who does all the building, he makes sure the servers are good. And if you saw those little things, yes, Iím that guy that does Tales from Redesign Land for the three of you in here that actually do read my blog. How many people are familiar with this? Ok. Well a fair amount. So I am that guy, but I do have to warn you that meeting me is like meeting the inventor of LOL-CAPS; itís not going to be as cool as you expected. I have just a minute or two left. Any questions, and I would be happy to talk to you offline after the session.

[Applause]

Announcer:  For more presentations from the 2008 HighEdWeb Conference visit HighEdWeb.org/2008 or sign up for our podcast and feed at HighEdWeb.org/podcast.xml

[End of Music]