A year ago or so, when I decided to take on redesigning our library website*, I immediately decided to use WordPress. Although I’ve never actually installed WordPress by myself, I run two blogs that use it. I’d seen a gorgeous implementation of it at the Thomas Ford Memorial Library. I understood more or less how it worked and what you could do with it, which is not something I could (or can) say for Drupal or Joomla or a lot of wiki software. So I dove in: I did a sample site on wordpress.com; I got our IT guy to install the real thing for me; I mucked around with the markup till I figured out how to change colors and get rid of some of the bloggier elements, such as dates on pages, and in the process screwed up a lot of other things that, happily, my friends were able to fix.
These days the site is looking pretty good, I think, and I’ve taught seven or eight other people to add content to it, which I think is awesome. But there are some things that I never considered when I was starting out on this lark (most of my projects start as larks), and while I don’t think I made a bad decision, I thought I’d enumerate some of the difficulties, too.
WordPress is blogging software, not content management software. If you don’t want to do anything too complicated, it works well enough, but there are compromises I’ve had to make. Although the Park County Library System is a system, in consists of three very different libraries that are a long way away from one another. It’s 32 miles from my library to the main library in Cody, and it’s 26 miles beyond that to get to the other branch in Powell, and unless you can fly, there’s no way to make those journeys any shorter. I was torn, and still am, by how to represent those differences while still creating a unified website. I chose to make separate pages for each library instead of (as Thomas Ford does) making separate pages for each group we serve. That means that we don’t have a central kids’ place: we have a Cody kids’ place, a Powell kids’ place, and a Meeteetse kids’ place. That means I can’t just say, “Hey, want to know what the library is doing for young people? Go to parkcountylibrary.org/kids.” I’m not completely sure that balancing those two things is something a real CMS could do better, but I imagine that it might.
This one really threw me for a loop. I have done WordPress upgrades before (all by myself! though with fear and trepidation and many, many backups), but I was not at all prepared for the whole new look of the backend that came with the move from 2.3 to 2.5. A different look for the backend isn’t a big deal for me, and it may not be for you, but for a lot of my website contributors, it’s going to be a big hurdle. I’ve created training materials [Word doc] with circles and arrows and paragraphs explaining what each thing is, and while you might think you could say, “Hey, just look around — the categories are still there, they’re just in a different place,” for some people, it’s a big change, and I’ll need to redo all my circles and arrow for the new format — and that’s a significant time investment
I’ve been ignoring the upgrade because of the time and effort that will be involved, but I sort of know I can’t do it forever. (If someone can explain to me what exactly the security threat of running old software is, I’d appreciate it greatly. I know it’s a threat; I just don’t know why or what sorts of bad things could happen because of the holes in the software.)
Things people want to do that the software just won’t do
I gave up on getting our library card signup form fit into WordPress, which I think is basically okay. But I’ve had people want to create all sorts of things — forms, tables, exactly positioned images — that, for various reasons, just don’t quite work with WordPress, or don’t work with it without them learning some HTML. I love that I can get pretty much anyone who can use Word putting stuff on the website, but it’s hard to know exactly what to tell them when they start to get irked with the limits of WYSIWYG editing. Again, to us learning a few HTML tags may not seem like a big deal, but it’s a leap for people who just want to update the children’s section quickly and get back to their work as very busy children’s librarians.
For these reasons and others, I’ve been trying to create a little community of practice for people using WordPress in libraries. Jessamyn has blogged about it already, but even though I think my mom is the only person who reads this who doesn’t read librarian.net, I thought I’d repeat it. If you’re at all interested in using WordPress in a library context, from Scriblio to a teen blog space, please join us!
- a wiki I have always used pbwiki as a free wiki service in the past and would have used it for this, too, but their latest upgrade, I got a little irritated at them, so after shopping around, I chose bluwiki instead. It’s free; it’s ad-free; it’s decent looking, but it’s not as familiar as pbwiki, and I wonder if that means that it will be harder for some people to use.
- a WebJunction group The new WebJunction has some nice new social features, and a WJ group allows you to set up both a discussion forum and a place to upload documents, so I thought we’d give it a whirl.
- an email list Well, sort of an email list. I’ve run any number of lists in the past, but there’s something going on with this one that I don’t quite get, wherein messages only seem to go out if you send them from the site. If we don’t get this figured out soon, we may migrate to a different provider. I feel incredibly dumb for not being able to make this work better, which just goes to show you that even if you think you’re thinking about it, software can come back to bite you when you least expect it.
*Our old site, for the curious, looked kind of like this (although significantly better in IE than in Firefox).