Unit 5: Contemplate

Well, I chose Contemplate as my self-selected Drupal module. According to the website, this module "was written to solve a need with the Content Construction Kit (CCK), where it had a tendency toward outputting content in a not-very-pretty way". Since I agree that the default Drupal presentation is really not attractive at all, I thought this module might help me to make some improvements. It also sounded like a good option because the website indicated that it "dovetails nicely with CCK" and required no additional modules. On the positive side, I was able to adjust previous directions and successfully download, unzip, and install the module! Yey me (or more accurately - yey Professor Fulton's detailed instructions)! On the downside, although the module description says it "makes it easy to rearrange fields" and other aspects of Drupal display, it seems to be "easy" only if you have a better understanding of php than I do. Or, maybe I am just doing something wrong, which is totally possible. Still, I feel confident now that I could explore the available modules in more detail and if I find one I like actually complete a successful installation, which I have to think is really one of the major goals here.

Unit 4: Drupal Impressions

I kind feel I am being unfair to Drupal. Our installation is straight out of the box with no customization at all. As is, it looks terrible! I would never choose it as a Digital Library & Archive solution if the best it could ever look is what we have up and running now. I have seen Drupal in action as a content management solution for a university website. I know at least when it comes to managing web content, it can function and look alot better than this. I have my doubts about its ability, at least without quite a significant amount of customization, to serve as a Digital Library & Archive solution. Several of the Drupal installations I have seen so far in exploring for this course have been working in tandem with ContentDM rather than relying solely on Drupal functionality. Some of my major concerns would be rights management and representation of archival hierarchy.

Unit 3 - Class Commentary

I am really excited about this semester's objective. I love the idea of installing multiple content management systems and experimenting with them as digital libraries and archives. In my experience, investigating, evaluating, testing, and selecting software is such a huge part of the responsibilities as a Digital Archivist. This is a great opportunity to get more experience with software I have not had the chance to explore before. In terms of the tech assignment, I actually wish there were a lot less reading and writing and more hands-on experimentation with the VM, MySQL, and the different software systems. In particular, it seems like two discussion assignments a week is unnecessary. The management portion of the course also doesn't feel integrated at all with the tech assignments.

Unit 2 - CMS Development and Design

I chose the theme article "LibData to LibCMS: One Library's Evolutionary Pathway to a Content Management System" by Paul F. Bramscher and John T. Butler from the Digital Library Development Lab at the University of Minnesota. The article describes there journey from a simple relational database for storing library related data to an increasingly more dynamic and flexible content management system. While the technical and functional details of the CMS they ultimately ended up with were somewhat interesting, I was really struck more by the strong commitment to both user-driven design and local, open-source development.

One of their overarching goals was that a CMS "should enable the organization to provide a high degree of customization for users so that key user communities feel that the site has been designed expressly for them." The authors were very honest about the trade-offs of a centralized CMS, especially concerns over loss of freedom and creative license for staff and individual departments. In exchange, however, the university was able to empower staff lacking HTML skills to take more direct control over the content of their own websites. To help off-set staff concerns, very careful attention was paid to understanding existing workflows and roles in practice (not ideally) prior to any technical development of the system itself. Moreover, increasing amounts of flexibility and multiple authoring mechanisms were built into the system throughout its evolution.

The authors also frankly discuss the pros and cons of local development and make it clear that the decision between that and purchasing proprietary software is really a decision unique to an individual institutional.  While like many organizations they were challenged by the gap between library and computer science knowledge and skills, ultimately they found the bonuses of local development to outweigh the drawbacks. Namely, they prioritized the complete technical control to design a system that met the specific individual needs of the university and integrated as seamlessly as possible with existing university systems while proving cheaper in the long-term and avoiding restrictive licensing agreements. Moreover, there was a hope that the open-source approach would eventually lead to shared community use and development in the future.

I do have one rather petty and insignificant criticism of the article. I generally think the purpose of an analogy is to compare one thing a person is likely to already have an understanding of to a similar thing a person perhaps is unfamiliar with as a means of helping a person more quickly or easily grasp a new concept. So please tell me, what is the purpose here of using this analogy: "This [system] approach may be roughly analogized to arranging DNA nucleotides in chains to produce an 'information molecule'." Did the authors forget who their target audience was momentarily or is it just me?