Unit 13: Playing with Servers and Some Thoughts on the Course

Downloading a preinstalled VM would be appropriate if the main learning objectives of the course are related to experimenting with various applications that can be installed on servers like the various content management systems (Drupal, Wordpress), collection management systems (Omeka, DSpace, EPrints, Fedora), and other tools like harvesters. However, if the course is focusing on managing digital collections, I think that the server aspects are as important as the software. I think that both this course and IRLS 672 mention that the important thing in technology courses is not learning one way to do things or memorizing a set of practices that will always work—it’s about learning how to learn technology—how things work in a general sense, what the various pieces of the LAMP server do, etc. So just learning the applications user to manage collections is not very valuable if you can’t explain how they fit in with the LAMP architecture and the various financial and managerial issues that accompany server maintenance protection.

I suppose that preconfigured solutions would provide more time for developing the collection and the metadata elements and application profile that describe the collection. However, we already had to build and describe collections in our IRLS 515 Organization of Information course. I would argue that the experience of using the various software packages to implement some items from the collection for the purpose of comparing the various options for hosting digital collections is more valuable than working harder to develop the digital collection itself. I would almost prefer that each student had to describe and enter the same digital collection (or choose from 5 practice collection options or something), because deciding what to put in my collection was stressful for me. I understand the value of reading about what makes a good digital collection and then trying to follow those principles when developing your own collection, but, it seems like most post-school projects I would engage with would involve making a collection of pre-selected materials accessible digitally.

In terms of computer skills, I had no trouble conceptually or in practice with any of the exercises we did in this course. I really appreciated the opportunity to cement my knowledge and skills with LAMP servers and navigating using the command line that I developed in IRLS 672.

I think that the course’s balance of hands-on server configuration, hands-on collection management system administration, and management thinking and writing was pretty ideal for my learning needs. The secondary management set of readings and the accompanying Botticelli lectures felt out of place to me—we already have to take a management course to get the DigIn certificate, and IRLS 671 and 674 also encompass management topics, and this course talks about management in the tech portion, so why is there also a standalone management aspect to this course? Taking out the server configuration aspects would give students more time to complete this management portion, but I think that the hands-on experience that would be lost would not make this trade worth it.

Unit 4: Drupal and my collection

Drupal is somewhat suitable for my collection. As we have learned, Drupal is very customizable. While writing out all the necessary categories and refinements to accurately describe my collection took time, I really like the dropdown controlled vocabulary menu, and once the work of creating the framework is done, entering the collection items themselves is not too time consuming.

I think that the customizability of Drupal makes it a great choice for unusual digital collections that don’t fit the traditional Dublin Core Metadata Elements or that aren’t suited to the text-heavy item records that some collection management systems use. Since Drupal is open source, anyone can develop modules to customize the system to their needs. Luckily, you don’t need to be a programmer to customize Drupal—many useful modules already exist. According to the discussion posts by my fellow classmates, there are modules for Drupal that allow you to create an image gallery, to play videos or sound clips, and for almost any other task you can imagine.

A weakness of Drupal is that since it is primarily a web development content management system, it does not have a focus on preserving the resources stored within a Drupal digital collection. 

I also felt like Drupal had a pretty pronounced learning curve. Much like the case study of implementing a web CMS I looked at in Unit 2, I felt like I had plenty of information about installing Drupal, but to actually learn Drupal I would need more time to poke around and figure out how things work for my specific needs.

I have seen some Drupal sites that are very visually appealing. However, the initial build of Drupal looks pretty blog-ish and simple, even when a different theme is installed. I think that there are some collection management systems we are going to look at that produce more “digital collection” looking pages automatically, instead of all the reconfiguring within menus and plugins I would have to mess with to get Drupal to look how I want it to look for my collection.

Some criteria that I think are important for evaluating a CMS are: whether or not it is open source, what kind of support is there for users (both paid services and more informal community services on forums), is the community active, how does the resulting digital collection look to users, how easy is the CMS to use as an administrator, and is the CMS preserving the materials it stores.

Unit 2: Case Study in Choosing and Implementing a CMS

I chose to discuss Huttenlock et al.’s article, “Untangling a tangled web: a case study in choosing and implementing a CMS.” The three person Systems and Technological Services department at Wheaton College began experimenting with more complex webpages in the early 2000’s. While they developed an in-house CMS that worked for a short period, in 2003 they decided to use a commercial product.

In order to evaluate the various CMSs, the department developed a rubric. They wanted the CMS to be open source, allow data from the old website to migrate to the new CMS, secure, established (not a first version release), and easy to use from a development and management perspective (Huttenlock et al. 63). I found it pretty amusing that, “many of the products started to look the same. No matter which CMS one chose, one could easily create the same boxy site with approximately the same amount of work” (63). Maybe it’s because we are working on our digital collections more than a decade after Huttenlock et al. looked at CMSs, but I would not say that the various collection management software we have tried in this course creates the same looking sites with the same amount of work. It could also be that the curated introduction to these systems we are receiving in this class already eliminated products that are very similar to one another.

Eventually the folks at Wheaton College decided that a CMS that could use their existing database structure was the best option, so they chose one called WebGUI. Interestingly, WebGUI had not been a frontrunner during the first part of the selection process because it did not initially seem as user friendly as some of the other CMSs (64).

While there were guides about installing WebGUI, the team found that learning how to actually use the CMS (which modules work together, how to set up pages, etc) tool the most time. The team found assistance in the WebGUI community—both at the annual WebGUI conference and on the WebGUI forums. I thought that this commentary brought up a very important element of choosing a CMS—the community. A tool with an active and robust community using it and talking about it is superior to a tool that doesn’t have that informal support network.

It seems like the biggest takeaway from this experience for the team at Wheaton was that allowing enough time to choose, install, and learn a CMS is essential. They had initially budgeted one summer as enough time to complete this project, but it ended up taking longer. Huttenlock ends by saying, “Usability is more that just how easy a system is to use, it is based on the context of the actual tasks that someone will need to use it for” (68). This is an apt observation for this case study since the team initially didn’t think WebGUI would be a good CMS judging by its look, but its functionality suited their needs best.

Works Cited

Terry L. Huttenlock Jeff W. Beaird Ronald W. Fordham, (2006),";\

Untangling a tangled web: a case study in choosing and implementing a CMS", Library Hi Tech, Vol. 24 Iss 1 pp. 61 - 68 Permanent link to this document: http://dx.doi.org/10.1108/07378830610652112