Cliff Landis is the Web Services librarian at Georgia State University Library. He is also the Interim Department Head of Digital Library Services at Georgia State. He was kind enough to answer a few questions about the content management system used by Georgia State University Library.
• Are we using a content management system for the library’s website and if so, which one?
Currently the library uses the campus-wide CMS, OpenText (formerly RedDot) for its website. Additionally, we manage about 50 different web-based applications that tie in together to provide a seamless user experience of the library’s resources (such as LibGuides for research guides, Kurogo for our mobile website, OpenRooms for group study room reservation, LabStats for computer availability maps, etc.)
• How and where did the library hear about the CMS?
Other units on campus had been using RedDot since before I came to GSU. In 2009/2010, IS&T (Information Systems and Technology, the central campus IT department) started to require all units on campus to move to RedDot (prior to that we were using a home-grown CMS system). We transitioned over from our home-grown system to RedDot in August of 2010
.
• What were the library’s motivations for adopting this CMS for its current use (library website or any other purpose)?
We were mandated by central IS&T.
• What were the decision making criteria?
The decision was made by central IS&T because it was the system that they had been using and developing in for a long time – they did not want to move out of their existing system. As it was told to me, they solicited feedback from other units on campus but made their own decision to move forward with RedDot despite complaints.
• What are the important benefits or advantages of this CMS over the old system or another CMS system the library (or you) has used in the past?
There is only one benefit that I can think of: RedDot is set up to separate editing, publishing and display on separate servers. So, for example, we edit our work on one server, which is then passed to the publishing server, which then pushes out the work onto the display server. This way, if either the editing server or publishing server go down (which happens regularly) it does not take our public website down. However this also means that seeing changes often takes several minutes, depending on the health of the other two servers.
• Are there any disadvantages and if so, how did you overcome them? There are a lot of disadvantages:
1. The software is extremely flexible, which means that you basically get an empty box and a development framework, so you have to code all of the tools yourself. This is great if you’re running everything centrally, but unfortunately IS&T was coding all of the tools but not documenting them. Instruction was done in classes by Employee Development folks who did not work on the tool itself, so they often were unable to answer questions and had to throw their hands up when things went wrong. As a result, we (the library) had to figure stuff out on our own and write our own documentation. See the “hide and reveal framework” for an example of the complexity involved.
2. The software’s labeling and user interface is practically impossible to decipher. Standard behavior on other tools (locations of menus and options) are not in place in this software. There was no way to overcome this other than to learn the cryptic labels and document them internally.
3. Simple actions take dozens of steps to complete (uploading a file takes 10-15 steps). There is no way to overcome this.
4. Finding a single element to edit can take a long time if you don’t already know where it is located. Internal documentation is the only way to overcome this.
5. Publishing a page is tedious and takes several steps. Even when those steps are complete, there’s no guarantee how long it will take to publish out to the public website. Again, we can only document and try to be patient.
• How was the learning curve?
Because the tool is overly complex and difficult to use, the learning curve is extremely high. As a result, I (the Web Services Librarian) am the only person who deals extensively with RedDot – it would be a waste of other folks’ time to try to teach them all the ins and outs of this system. We have a “Web Group” in the library who collectively does simple editing, but for complex editing the work falls to me. After the ongoing complaints from the whole campus over the last two years, IS&T is going to provide WordPress as an alternative to RedDot later this summer. Right now they are working with a consultant to develop a migration tool to help units move their content from RedDot to WordPress. In the library we have a lot of experience with WordPress since we use it for both our public and intranet blogs, so this will be an excellent development when it finally becomes available!
Before this interview I did not know what content management system was being used by the library and Georgia State University at large. I also did not take into account the problems having one central system for multiple departments could cause. From the readings I gained this simplistic view that the biggest problem when dealing with a CMS would be having enough programming expertise. From this interview I learned that you sometimes have to work within existing systems and existing policies that make the job that much harder. I have not used RedDot/OpenText before but it seems to have a number issues which lead me to one of the most important pieces of advice I gleaned from this interview: document everything! Cliff mentioned it several times while explaining how he dealt with the system. A lack of documentation on the part of the central IS&T increased the confusion of the different departments dealing with this software.
No comments:
Post a Comment