As a member of a small team of librarians and staff at the Hurst Library of Northwest University, I gained a variety of experiences that impacted and benefitted the staff.  In one project I learned through the migration of staff manuals from a combination of print and electronic files to a central wiki, hosted on the library intranet. I spent time researching, implementing, providing training, and evaluating the use of the wiki software, as well as creating the initial hierarchy and layout. In choosing the wiki software, the systems librarian and I looked into several options, including some hosted options. None of these provided low cost with enough storage to accommodate the projected file types and sizes, although they generally seemed fairly easy to use.

We settled somewhat unhappily on MediWiki and later added the FCKeditor to make it easier for all staff to create and edit pages. The systems librarian installed the software and we got to work refining the layout and first page hierarchy. Then I familiarized myself with the setup by entering the information for my position and much of the circulation student assistant procedural material as well. This way, when we presented the wiki to the staff and trained them, there would be some content for them to view as well as an example of how they might want to set up their department’s sections. I struggled at first with the use of the software and found wrapping my mind around the way a database driven setup can work to be a difficult endeavor. Many of us non-systems people in the library seemed to be comfortable with the idea of static web-pages, but less sure what to make of content that doesn’t have a set location, yet can exist on many pages in various places. Previously, individual departments might create separate documents covering the same information, but now it could all be in one place, so some dialog needed to occur to streamline and mesh redundant information.

Through this project I learned many interesting concepts about wiki software, content management systems, and other arcane techy topics. I learned how trade-offs are inevitable when choosing technology solutions and that those trade-offs can become hindrances to staff take-up of a product. I realize now that even though the upfront time spent researching and testing out various solutions may seem excessive, it is extremely important. I learned that a technology can impact the way data is created, with implications for information that crosses departmental lines. Since the same information that exists in a database can display in multiple places, it can be a good idea to rethink how some processes are documented. I also learned that things don’t always go as planned (sometimes they go better). Some very valuable uses may become apparent only after the technology is out and in use, and that some of these uses, if discovered early enough, may dictate changes to the architecture of a site or workflow of a process.

As I go out into the library world, I know that bringing more people in earlier on a project can expand the support base for when it is rolled out. If people are more involved in the process, they may be better prepared for the necessary changes in procedures as those come down the pipe. I see the value of teams since important considerations that may be overlooked by too small a group can come to light if representatives from many parts of the library have input into a project. Because of this experience I have a tangible reminder that without ease of use, a good solution may encounter resistance. The tool shouldn’t be a barrier, but should make a process work better. Also, we need to look beyond processes for their own sake when a new tool allows us to do something differently.  I have confidence that there are technology solutions to many problems libraries face and tasks in which staff engage. The trick will be selecting the correct tools and preparing people for the inevitable changes associated with them.