18 Months of Web Services and Technology at Ryerson Library

It felt a lot longer than 18 months with the amount of stuff that happened. The list of activities and projects at for my one year review was definitely a lot longer than I expected. I’m not sure I even know where to begin, but maybe I should begin at the beginning.

Open to Discussion

I haven’t worked in many libraries, but based on both my experience and the stories I’ve heard, I can’t help but think Ryerson is a very welcoming and flexible environment. I’ve worked in welcoming environments before in terms of being collegiate/friendly, but it’s the flexibility or welcoming of change that really struck me. I made a lot of changes in my time. While in consultation with staff, it was still a lot of change to accept in about a year. Most of the changes revolved around the website, but also included some workflow changes.

At a previous place, making such drastic changes always produced some negative feedback. Rather than negative feedback, I got suggestions and constructive feedback. (If someone didn’t like it, I didn’t hear about it anyway.) Don’t get me wrong, some grumbling and confusion did ensue (inevitable), but rather than simply saying “I hate it”, I would hear “why did this happen? could we discuss reverting a couple of things?”. Who doesn’t prefer to discuss things rather than hitting a brick wall?

I did hear from a couple of staff that part of it was the way I handled communicating changes to staff, and maybe my style simply worked well in the particular setting. I’ll never be sure, but it was something I was very conscious of making sure changes were known and opportunities for feedback were available ahead of time.

Encouraging the “Newbies”

Somewhat related is the probationary librarians group. The group consists of all new librarians whether on contract or probation. Once a month, the group would get to meet with the chief librarian and usually hear a little bit from everyone. Collaborative projects between new librarians were also highly encouraged, and many very successful projects have come out of this group including the Summon evaluation project [PDF] and the ‘making institutional repository documents accessible’ initiative. A few of us also did a library presentation at the faculty conference both years I was present. We were also encouraged to attend conferences (obviously within a reasonable budget), which I was very grateful for.

Mostly, it was a great way to get a sense of what the chief librarian does (in general) and to hear about some higher level initiatives. Maybe it’s because I”m used to working in even larger organizations, but at previous places, I only ever saw the chief librarian (or whoever was in charge) when they did presentations.

The Usual Suspects

As to be expected in any academic library, my regular duties included working at the reference desk, and doing instructional workshops. What was definitely different was having another staff member working on the desk as well as an IT person (in the learning commons). Having another staff member to ask questions, particularly when I first started on the desk, was great. It also allowed me to get to know more of the staff I might not normally work with.

Except that it was in a dreadfully stuffy room, I enjoyed the usual instructional sessions. I mostly did RefWorks workshops, but also got to do some orientation tours and such.

I also got to do some staff training, mostly on WordPress, but including some other technology and information sessions.

The Unusual Suspects

Some of the duties I ended up with, I definitely didn’t expect when I started:

  • E-Resources & Serials Review Committee: admittedly, I volunteered, but I wasn’t sure that I’d be accepted since I don’t really do much in terms of e-resources or collection development in general. Nevertheless, I have a much better understanding of both now. I also got a better sense of budgeting through being on that committee.
  • SFX: updating any part of our link resolver was not something I expected I had to do, but that’s part of being web services I guess!
  • TRY Conference Committee & Code4Lib North: since I was originally on a 1 year contract, I didn’t think I’d get the chance to stay long enough to help organize a single local conference, let alone two!
  • Code4Lib Toronto Group: this was totally unplanned. I only started this because I was jealous of Ottawa (lol). It was a great way to get people together though, and some really great discussions happened.
  • Supervising students: I always thought this would come later, when I became a permanent person somewhere, but I ended up supervising a couple of UofT iSchool students. I also had to do a work/study application (though that didn’t pan out).
  • LadiesLearningCode: while not in any way linked to my work, because I was in Toronto, I got pulled into volunteering at LLC. I even got to attend as a learner once! I enjoyed it so much that I’m planning to continue now that there is a Vancouver chapter.

Bookfinder

Ever since the hackfest at Access 2011, I’ve been interested in how we might help students find physical items. I was lucky to get the chance while at Ryerson.

When I started, the web ‘app’ had been in development on and off for two years, mostly worked on by students. I was amazed that something existed but was never pushed out, so that’s what I did! I had to do a lot of digging to figure out all the different collections we had to consider and the various requirements. I also developed a basic maintenance plan, which meant getting staff outside our team involved.

While people asked for RFID real-time information (which we can’t do since the books aren’t RFID tagged), we still got a lot of positive feedback and students seemed to really like it. When I did some usability testing, students definitely found books a lot faster and felt less frustrated.

I won’t talk more on it here as I’ve blogged about it before, but I’m really glad I got to be part of the project and finally pushed it out.

Issue Tracker

When you have a small team, notes, in-person conversations, and emails work just fine, but for documentation, passing on knowledge, and accountability, frankly, it sucks. Settling on Redmine was a fairly easy decision, and thankfully easy to install and use. The biggest lesson was in how to get our staff to report issues, changing the way that they communicate with the team (more on implementing Redmine in a recent blog post).

Basically, it always comes down to having a communication strategy.

The Website

Anyone who has been reading my blog posts will know that my biggest project was moving the website to WordPress, then redesigning it one section at a time. (Somehow I never seem to get to the home page though.) While I was bringing in expertise (it was why I was hired after all), I also learnt a lot from the users and received invaluable feedback. It could be prettier, but I like what we’ve done with the website. I say ‘we’, because while I coordinated and provided the general design and information architecture, the content overhaul was done by a number of staff members, and I like the end result.

In particular, I was thrust into the world of web accessibility, but thanks to some great people and resources, I have at least some understanding of it now. I’m certain it will prove useful in the next website overhaul that I do. The website took longer to migrate to WordPress by making it accessible, but I hear the users who are affected, appreciate it.

It’s All About the People

Getting all those projects done was great and all. Participating in conferences and other events was a lot of fun. The thing I’ll never forget though was all the awesome people: their advice, encouragement, and support.

I’ll leave it at that, as the adventure doesn’t stop: