Tag Archives: wikis

Our wiki celebrates it 1st anniversary

We celebrated the passing of our wiki’s  first anniversary by making it available to all Halifax Public Library staff.  We call the “public” side of our wiki, CataWiki. 

This has been a work in progress for over 8 months.  It began to take shape in my mind when our department continually received the same questions about the catalogue.  So, I began soliciting questions for a FAQ for our catalogue and our department.  For example, what constitutes a 3 day v. 7 day loan for feature DVDs? Why is there no item information in the public display of the catalogue but the staff side has the item information?  What items get what stickers? What do I do if I accidently delete an item from the catalogue? and so on. Rather than preparing a static document that would become outdated within weeks, I wanted a live document that could continue be used as a resource and always be in a constant state of improvement and growth.  And, as Oprah would say, that was my “Ahah” moment.  Why not put this FAQ on the wiki, where staff can bookmark it and refer to it.  They can even subscribe to an RSS feed on the wiki (this feature is forthcoming).

Of course, my immediate concern was security.  I have experience with a wiki on a public domain which was spammed beyond repair.  My concerns in that regard were put to rest at the inception of our wiki – which is housed on our local server and only available through the library’s intranet.  But what about keeping department information private and inaccessible to branch staff?  What about editing privileges?

So began my collaboration with our IT manager.  Brainstorming, we came up with the idea of two wikis – linked by providing a URL on each wiki.  The wiki with our department information, which includes minutes to meetings, project proposals and in-depth information on cataloguing practices, procedures and decisions was protected by a login page.  The login page prevents access to anyone who doesn’t have an approved account.  As the system operator of the wiki, I have final approval of the users and am able to block unwanted users or accounts from being created.  As a result, no one outside of our department can view or edit our department information. 

Once that security was in place and URLS were provided on each wiki for easy navigation between the two (for ease in editing for our department), I began protecting the “public” side of our wiki.  Again, while I wanted to make this information accessible to the branch staff, I didn’t want them to have editing privileges.  At this point, some of you may groan and say I’ve missed the point of the wiki.  Not at all.  I understanding the concept of collaborating and user-generated information.  But there are specific purposes for everything and in this case, our wiki is, in a way, a marketing tool to help us come out of the backroom.  It is a window into the cataloguing department which, I hope, will remove some of the mystique and negative attitudes often directed our way. 

Allowing all of the library staff access to our latest fiction genre headings, changes in subject heading usages and FAQ will provide staff with a glimpse into what cataloguers do.  It will also assist in providing staff with the knowledge to better use our catalogue, and as a result, better serve our patrons.  We’re also including access to lists that may be “hidden” in the catalogue when off season or if they’ve been popular in the past.  For instance, Best of lists, holiday lists or topical lists that we just don’t have room to feature on our catalogue will shortly become available for staff to view.  This will become an incredible resource for patrons because staff will be aware of lists that are generally forgotten about.  Each list will have a link directly into the catalogue so that staff can work directly with patrons to help them find items to borrow. 

Given that this launch only occured this past Monday, I’ll have more to report down the road.  However, the initial feedback has been incredibly positive.  I know there is still a long road (and perhaps a steep hill or two) to travel before this idea really takes off and the wiki is used to its full potential but, we have to start somewhere.


Filed under In the Cataloguing Department, The Cataloguer

Using Social Software to Build a Collection and Create a Community

Recently, a colleague of mine stumbled across North Cumberland Historical Society’s webpage while cataloguing.  Rather than a static website, they’ve decided to use Wetpaint, one of the many options for wikis.  I think this is a very clever idea.  What really grabbed my attention is that, right on the front page, they announce that this is a website that can be built together – by the community and the members of the historical society.

I’ve always been an active member in my local historical society, and I’ve found that while there is a plethora of knowledge among its members, there are others in the town who also have stories, knowledge and mementos that contribute to our town’s collective history.  By creating a website that allows the community to contribute to it, they have opened the historical society to the entire community.

Students can contribute while working on class projects, inviduals working on their family’s geneology, and citizens who remember the town as it was “back when” will have a venue for contributing to this website.

This is a terrific example of social software being used to build a community, and making it the community’s organization, rather than an organization for its members.  I applaud the historical society’s ability to let go of the reigns and loosen the control that many organizations have trouble with.

This same concept can easily be applied to our own library websites and catalogues.  And, I know that many of you are attempting to do just that.

Leave a comment

Filed under Discovery tool platforms, Social catalogue

Collections Access Wiki

It occurred to me that many of you may want to see what our cataloguing wiki looks like and the kind of content that we are adding. Although the “official” wiki is housed on our local intranet, my “training” wiki* is not. Please feel free to view it and navigate around.

The content and layout of this wiki* are almost an exact replica of the wiki we are now using. I have added a logo and am considering a new “skin”, but that’s cosmetic. Not only do I want you to see the potential for your own departments, I welcome feedback. I’m sure there are things I can add, resources I am missing, or something I completely overlooked.

As a bit of a promotion for wikis – I highly suggest downloading and playing with wiki software. This is how the training wiki was born. I was able to play and really develop an understanding of how to use the software, the type of training that would be involved for staff and its usefulness prior to pitching it to management.

Here are a list of wikis you may also be interested in:

Smithsonian Library Wiki
Administrator: Mario Rups

University of Minnesota Libraries Wiki

Library Success: A Best Practices Wiki

Vanderbilt University Library Staff Wiki

Radical Reference Wiki

Nancy Pearl’s Booklust Wiki

Subject Guides Wiki

*The training wiki is no longer available via the internet.  I apologize for any inconvenience this causes.  However, please feel free to contanct me with your thoughts and questions.

Leave a comment

Filed under In the Cataloguing Department

Using our in-house Wiki to keep cataloguers aware of subject heading changes

We recently received our hard copy of the Cataloging Service Bulletin from the Library of Congress. Our usual practice is to circulate this bulletin among all of the cataloguers so that they can make changes or add new subject headings in our own catalogue. In addition to the new subject headings that may or may not be adopted, there are subject headings that we alter or change. It is important to let all of the cataloguers know about these changes so that we maintain uniformity in our catalogue. Our practice in the past has been to send out group emails to advise everyone about these changes once all the decisions have been made.

Earlier this week, I had some great suggestions from two of my cataloguers. Rather than having a meeting to discuss the changes or additions, as we have in the past, one of the cataloguers suggested we add this information to the wiki. As each cataloguer has a chance to read the bulletin, they can add to the list of new, changed or old subject headings. Another cataloguer also suggested linking the pdfs of the Bulletin to the wiki. This will allow everyone to revisit decision made by LC, and in essence, everyone will then have a copy of the bulletin at their fingertips for reference.

Both of these are excellent ideas. Because of the format of the wiki, the entire department can also enter into discussions, or read the comments from the other cataloguers regarding any changes.

I’m looking forward to implementing these ideas.

1 Comment

Filed under Authority Work, In the Cataloguing Department, Subject Headings

Wikis and Cataloguers: Success for the First Step

Our new wiki was installed in the beginning of December. I was both nervous and excited. This is the first “big” project that could have a huge impact not only in the cataloguing department, but also throughout the rest of the library. If this pilot project works, I can write a report that recommends wikis for other departments throughout the library system, analyzing the strengths and weaknesses that I have encountered, as well as the learning curves, training challenges and staff participation.

The First Step
Although not fully implemented, my first step with our Wiki was to introduce the cataloguers to its possible functions and uses. I put up many of our cataloguing “cheat sheets”, links to relevant cataloguing sites, department announcements and recent cataloguing decisions from LC and LAC. Sending them the link to the Wiki, I asked them to have a look around, get use to the navigating aspects and layouts. Upon reviewing the site, I asked for their feedback: What did they like? Dislike? Ideas for adding new content?

With my excitement in this project and by taking the time to answer questions and explain the possibilities of the Wiki, all of the cataloguers began suggesting ideas or providing me with feedback. One of the most rewarding moments was when one of the cataloguers suggested we put our “working” New Lists on the Wiki.

Collaborative Lists
New Lists are created as we catalogue items. Like most cataloguing departments, each cataloguer is in charge of cataloguing specific materials (DVDs, CD, Fiction, Talking books, Non-fiction, Children’s Non-fiction, etc). As we catalogue, items published or released within the last two years are added to “New” lists which are provided to the public and are constantly being edited and updated. Each cataloguer is responsible for their list, which reflects the items they catalogue. However, when backlogs occur, several cataloguers may be assigned to a specific collection to reduce the backlog.

With several cataloguers contributing to these New lists, it was becoming difficult for the main cataloguer in charge of the list to keep track of the item, how long they had been on the list, and when they should be removed. In addition, many cataloguers have their own system for keeping track of the lists (I.e. Word documents, Excel Charts, Handwritten notes). The time to organize these lists when multiple cataloguers were contributing was becoming a concern.

Our solution was to place the New lists on the Wiki. Presently, we are actively contributing to the New! Latest CDs list. This is an internal list that can be seen and edited by all cataloguers.

Because of the backlog, there can be up to four cataloguers contributing to this list at once. Because of the Wiki, there is one master list for each collection and the items are sorted by date. The cataloguer in charge of the list can then see when the item was added, how long it has been on the list and who added the item. This makes editing the live list in the cataloguer much easier. The amount of time that this has saved is equivalent to a couple of hours a week. As a result of the hours being saved organizing and editing the lists, more time can be spent cataloguing and reducing backlogs in other areas.

This is the first of many steps that I hope to take in the department. My next step is to set up a tutorial to allow cataloguers to create a group page and to collaborate on a project, using the features a Wiki has to offer. Once they have completed this tutorial, they should have the skills and knowledge to jump in to using the Wiki on a regular basis.


Filed under In the Cataloguing Department, The Cataloguer

A Wiki in our cataloguing department

You won’t find any Star Wars characters in our department, but you will soon find a Wiki.

When you enter your cataloguing department every day, you bring with you information that cannot be found in AACR2 or MARC. In addition to the many tools we use such as DDC, Bookwhere, Cutter tables, Validator, LC and so on, there are internal cataloguing rules that many of us have not bothered to write down because we just “know it”. But, when I first started my position, I didn’t “know it” because I was new to the system.

After creating two handwritten binders full of notes and collecting “cheat sheets” from all of my cataloguers, I began to think that there had to be an easier way to organize this information. There are rules based on rules that were based on a meeting three years ago. This is the type of information that only exists as long as there is no turnover or retirement within the department. However, this information is vital to retain when people leave the department because we will no longer have them as our resource.

Having experienced this “cataloguer’s knowledge” firsthand, I began exploring different options to organize and retain this information. How can we have a shared space where the department can access “cheat sheets” and other resources? Can I create a space where we can collaborate as well? At first I considered creating a simple database. Then, I thought about having all of the documents typed up and creating one master binder for the department. All of these just didn’t feel right. I looked at blogs but wasn’t really sure that it was right for our department and then I stumbled upon wikis.

Wikis are free, open-source software created for the purpose of sharing information. This really grabbed my attention the first time I saw it. After further reading, I found myself attracted to the real-time factor and potential of the Wiki. The real-time factor means that I can spend less time fielding emails and sending around internal cataloguing rules in draft. Instead, I can post one draft and collaboratively have all of the cataloguers critique and edit it until it works. I like the idea of having the cataloguers play a role in creating internal rules and accessing them immediately. In addition to storing all of our in-house cataloguing rules, I plan on including minutes from our meetings, announcements from LC, SirsiDynix, other vendors and links to all of our online resources. I can even include a professional development element.

Currently, I am in the beginning stages of setting up a Wiki for our department. I have had the opportunity to “play” with the software and get a feel for its potential. I have also been speaking with staff, seeking their input and really pushing the buy-in factor. I’m fortunate because my cataloguing department is full of people who are really keen on new technology and are always willing to at least try something new. At the present time, I am organizing all of the information that we want on the Wiki. This is a bit labour intensive. Sorting through old meeting notes and cheat sheets is time consuming. Once I have chosen the base information for the Wiki, I still need to type it, organize it and assign access points to it. I need to design not only the content of the Wiki, but its general layout.

There are also privacy issues and editing restrictions that need to be addressed. Because it is open source software, I need to be careful who can edit the Wiki and who can see it. Should we store it on a web server or on our own intranet? Should all the cataloguers have editing access? Who should monitor the edits in addition to myself?

As this project goes on, I’ll be able to share my experiences with you. Overall, I see this as a very good thing for our cataloguing department. There are so many steps ahead and I am not naive about the time that it will take to create the Wiki. Once the Wiki is finally in place, there is always the staff training and evaluation. However, I am optimistic that this will be a great asset to our department.


Filed under The Cataloguer