So I often get questions for others in the Connecticut library community about what to do with their own websites. I can definitely say that there is no library website that should remain on the old static html webpage built in Dreamweaver/Microsoft Expression Web/Other HTML editor. In other words, you definitely need a web content management system to run a website in the 21st-century. There are a lot of deep reasons for that. Probably the easiest one for me to explain is that it allows many people to easily work together on / contribute to the website. It also makes it easier for you to output the information you're providing on your website to your users in a way that they want to use it (for example, on their mobile phones vs. on a computer screen).
There's a whole array of options for web content management systems. The commercial, heavy-duty (often dubbed "enterprise-level") web CMS', can be extraordinarily expensive. I won't even bother talking about them for libraries.
There's also an array of options for open-source web CMS'. Many of them don't require you to commit to any licensing fees - in other words, using them doesn't cost you anything for the software. What you end up paying for, in comparison, is for human resources - the people to take the time to put into making the open-source system work. You may use your in-house webmaster/systems librarian or, more likely, you'll seek out a consultant with expertise in setting up one of these solutions for your library.
Often the documentation on open-source projects is less than ideal. On the other hand, at least you can Google for answers to your open-source problems (contrast this to seeking Google-ing for solutions to errors in proprietary commercial products like many Microsoft, IBM, Oracle, or SUN-based products - these companies tend to keep their troubleshooting tips behind a login/password-customer-only system so that the competition can't learn about their weaknesses). Someone somewhere's blogged about the issues they've faced with open-source products. It's part of the open source spirit to contribute your work back into the community. Publishing online about the problems you faced & how you overcame them is an easy way to do this.
So what are your options & what are their relative advantages & disadvantages? I'll go over only the ones that I have more than a passing familiarity with:
- Wordpress - though it was initially conceived of as a blogging solution, it can now easily be used as a regular website content management system.
- Drupal
Wordpress can be used in its fully hosted/3rd-party managed form at www.wordpress.com. It's free to set up an account, but you can also use (for a really small added annual fee - used to be $25/year) an account add-on that allows you to point your library's domain name to that site. You can also use a web hosting provider's hosted Wordpress installation (in many cases, you'll have to keep the Wordpress software updated yourself, but some web hosts even handle this for you) or a Wordpress installation that you run on your own server. You can download the Wordpress software & run it for free on your own web server (you'll also need to run PHP & MySQL on that server - get the download & how-tos from www.wordpress.org). Though it's slightly easier to run Wordpress (& other open-source web software) on an Apache web server than an IIS server, you can run it on either. Apache is easier to deal with and can run on a server that has Mac, Windows, or Linux operating systems.
Drupal can be used in several ways. It used to be that there wasn't really a wordpress.com-type option for Drupal, but recently, sites like Drupal Gardens sprang up to make it easy for anyone to quickly get up and running with a fresh site on Drupal (yes, migrating existing sites is always WAY harder than starting with a blank slate, but don't forget to do some information architecture/sketching/planning before you begin - identify your site's goals, what content you'll have & figure out how users will move through that content before just building willy-nilly if you want to ensure a decent website). Besides that, you can use a web hosting provider to run your Drupal site (ideally find one that other Drupal folks have recommended - because Drupal has needs that some web hosting providers don't serve well without a serious investment - e.g., getting at least a virtual private server, which can be very expensive). Or run Drupal on your own web server. It, too, requires PHP & MySQL and runs best on the Apache web server (though it can, with work, be made to function on IIS). Drupal tends to prefer a Linux (or Mac-based) operating system though - again, depending on how much of its functionality you want to leverage and how much work you want to do - you can make it work on the Windows operating system.
Side-by-side comparison of installed (not hosted) versions of these web content management systems: Wordpress offers more user-friendly functionality out of the box. Drupal 7 just went live and improves the out-of-the-box Drupal experience (compared to Drupal 6, which has been the standard for several years), but still lacks both the immediate elegance and user-friendliness (e.g., for editing content with a what-you-see-is-what-you-get (WYSIWYG) editor) of a Wordpress install. But the moment you want to start integrating web resources at any deeper level, the advantage goes to Drupal. Wordpress goes from 60 to 0 at this point. You have to get deeply into PHP if there isn't already a plugin created for the system integration you're seeking in Wordpress (admittedly, though, there are lots of great Wordpress plugins now - you can only use those plugins with your own Wordpress install, not with the hosted Wordpress.com version of your site/blog). Additionally, Drupal can be implemented in some really flexible ways, accommodating lots of different needs - more so than Wordpress. But you really need a web professional for this type of Drupal usage. Custom themes in Drupal require someone who's comfortable with Drupal at what I would call a pretty deep level. The flip side of this challenge is that Drupal will "professionalize" your library systems/web people in that it can take them deeper and deeper into the core technologies driving the web today. You could "get by" without a web pro for Wordpress though, again, if you want to deeply customize the template that alters the way your information and navigation is provided, you'll need to get into the PHP (which, of course, you can't do on Wordpress.com). PHP itself is not a ridiculous challenge for a library systems person to take on - however if you're intimidated by html code, you'll find PHP almost impossible (at first). I should also reiterate that if you just need a quickly-put together, highly templated site (like a "website tonight" type thing), you can use either Wordpress.com or Drupal Gardens.
A final option for dealing with your libraries' web presence: you could go the "small pieces, loosely joined" route & cobble together a web presence using some combination of your:
- blog (for example, at Blogger.com or Wordpress.com)
- Facebook page
- Catalog
- Other web2.0 tools - like Slideshare for presentations/tutorials, Scribd for documents, Flickr or Picasa for photos & so on
- You will need to point a domain name to a specific web-based page that will pull everything together - most likely that would be your blog page, but it could also be a Google Pages page or something else
- 3rd-party free Web2.0 tools / social sites like Facebook, Slideshare, Flickr, Scribd may compromise your commitment to privacy for your patrons. They can also change their terms at any time and you may or may not learn about the changes enough ahead of time to migrate your content elsewhere (think about Yahoo's decision to rid itself of del.icio.us after years of its seemingly stable existence). Remember, when you rely on these types of tools exclusively instead of running your own site, your content is not 100% under your control, nor are the interactions people have with your site. This may or may not work out for your organization, but recognize that it's the reality. I usually recommend that organizations use Web2.0 tools to redirect users back into web-based resources that they actually control - like their own website/blog.
- Brand consistency. It may be sacrificed by use of many disparate tools.
- Ease of management. Having to log into many different sites to do different things with your web presence can become a burden. Make sure that you have at least a couple of people who work for your library who know what all of those sites (& their logins) are.
- Advertising. Another issue that can come up when you're using another organization's technology is that they may underwrite your "free" access to their service by offering up ads alongside your content. In many cases, you won't have a choice about this.
No comments:
Post a Comment