This week, we got to start playing with Omeka. It reminded me a lot of our Drupal unit. The themes and plugins seemed very similarly structured. A little searching dug up this post in which an Omeka developer commented that the code bases are structured very differently, but from an initial user perspective, it had a similar front-end feel.
I think that approachable feel is really important. For example, although we didn’t look at Joomla or WordPress in this class, making the experience easy and visually appealing is part of why those tools are so successful. One thing I’ve noticed in comparing the different platforms in this class is that things that are visually appealing and approachable on the back end tend to be so on the front end when implemented, too. Okay, that wasn’t the greatest sentence in the world, but hopefully you’ll get what I mean: something like Drupal that has a really slick, intuitive, and approachable interface just tends to power better sites than something old and clunky-feeling like DSpace.
Since this week’s blog assignment is open-ended, I decided to look into something I was curious about: how DSpace’s Manakin themes compare to Drupal’s themes.
Here’s an example of some very attractive DSpace themes utilizing the xmlui interface: http://staff.lib.muohio.edu/~tzocea/files/dspace/
However, unlike with Drupal, there seems to be much more of a “roll your own” emphasis on this from the web developer’s perspective. Yes, there are some themes on GitHub and some how-tos that one can Google, but there isn’t that same plug-and-play experience you get with Drupal, where someone can change the theme without really getting into any of that back-end stuff.
This week has been a bit gentler-paced, which I appreciated! I enjoyed using Drupal to enter my initial items in my digital collection. I found it to be pretty similar to what I did last week. Although one of my classmates found it too “bloggy” for her collection, I actually find my particular collection (my personal writing files) to be well-suited to a blog format. Since I had just been using a (different) WordPress blog for (some) of those files in the past, categorizing them and deciding where different items fit on the taxonomy wasn’t too hard of a task. I could see it being more difficult with multiple users, though. On the other hand, the nice thing about Drupal is that even if users disagreed on, say, where certain content should be located on the site, it is possible to just have the same information show up in multiple places at once, and there’s only one version that can get edited and updated as needed. That seems to be a big problem with large sites — too many things are in multiple places, and when something gets changed in one place, whoever’s updating that content in that place might not even know about the other place.
The only thing that was a bit tedious was, again, because there’s a lot of information that seems redundant to me since it’s just my stuff (like putting my name as author over and over again). But as we’ve been learning in the management readings, doing the bare minimum of metadata on a collection makes it less interoperable with other collections, so there is a fair amount of data entry work. Another thing I really like about Drupal is that someone without any web design background can do this work: it is very successful in divorcing the form from the content. It also has mechanisms to allow review by someone who’s in charge of content before new content goes live, gets deleted, etc., which again are a bit redundant when it’s just me working with my own stuff, but is definitely a useful feature in the real world.
This week’s assignments were an interesting mix of theory regarding managing digital content, and practical readings and assignments focused on JHOVE (JSTOR/Harvard Object Validation Environment: pronounced “jove”), which is a framework for format validation, and Drupal, an open source content management system (CMS). I’d gotten to play with Drupal a little bit in the past, so it’s been interesting learning more about it, and although I knew absolutely nothing about JHOVE, I imagine I’ve used it unawares when I’ve searched, say, the JSTOR database.
One of our reading assignments was to skim the 2006 Library Hi Tech issue (Issue 1) focusing on CMS issues in the library world. The article that I chose to read in-depth and discuss on this here blog post was “Beyond HTML: Developing and re-imagining library web guides in a content management system” by Doug Goans, Guy Leach, and Teri M. Vogel.
I found this article especially pertinent to my volunteer project last semester, helping with the CCP’s website redesign. Previous incarnations of that website had suffered similar problems to the ones described by the authors, of each author of a particular page (especially the online exhibits) simply creating their own page, with its own unique (and more- or less- usable) fonts, color schemes, and pathways, rather than making sure that everything cohered to a style for the site as a whole. The CCP was eventually redesigned using Drupal, but reading about GSU’s choice to use a custom CMS based on ASP and MYSQL was very interesting to me, since their concerns with integration with Microsoft products, like IIS, would definitely be shared by the team who develops the website for my library system, the Pima County Public Library. Just because the open source solution worked for the CCP does not necessarily mean it would play nicely if PCPL decided to migrate to Drupal. (Although, and perhaps this is something that will be covered in future classes, I believe that Drupal 7 does integrate better into non-open-source environments than previous verisons did.)
In any case, it was clear that GSU’s decision to use a CMS led to greater consistency and usability across their site, as well as making the content editable by a variety of people who would not have had the skills necessary to manage the form.