In Which a Web Guy Goes to an ILS Conference

480px-Polaris_system

Polaris

This article may seem a little late, given that my trip to the 2013 Polaris Users Group Conference (aka PUG 2013) happened back in October. I wanted to sit on my notes for a bit, look them over and come up with something useful and, hopefully, semi-entertaining. If your ILS vendor hosts a conference of some kind, no matter what brand you’re smoking, you should go and there are plenty of reasons for this.

  1. It’s smaller. Even if lots of libraries use your brand, it’s still going to be a smaller conference simply because only a select group of people will be there. Which leads us to…
  2. You already have something in common with everyone. Sure, you can go to the big ALA conferences and so on, but the fact is, at ALA and the bigger conferences, you only have your profession in common with everyone else. You’re a library person. That’s where it ends. That person over there is a youth services librarian, they’re talking to a web librarian who will have coffee with a Director later that day. That guy does library finance and that woman does story times. Yet, when you go to a ILS conference, you have two things in common right off the bat — you’re a library person and you all use the same product. That’s big.
  3. Since everyone is using the same product, that means that everyone is driving their libraries in similar ways. There’s no back and forth over “does Triple I do such-and-such, because Sirsi does? You all know what you’re using, what it looks like, what its strengths and weaknesses are, and so on. That’s powerful because you can…
  4. Share ideas for using it differently. Any good ILS is a complex and robust ILS and what works for me may not work for you. Or, just maybe, it might work for you. It might work so much better for you, you’ll be happier to came to the conference because you learned a little something that will make your life easier and your patrons’ lives better.

What that amounts to is one of the best library conferences I’ve ever been to. I learned more per minute at PUG 2013 than I did per half hour at the last ALA. Sure, there were interesting and useful things at the last ALA conference I went to, but I could only use a percentage of them because, after all, my library is different than the originator of the idea. Since you and the other attendees know your system and know it well, you can got back and forth on ideas like never before.

“X isn’t working for us, what do you do?”

“X works fine on our end, we must be doing something different. Have you implemented Y and made sure Z was turned on?”

“Z?! You mean we have to enable Z? It doesn’t say that anywhere in the documentation!”

“I know, we found it by accident.”

So the funny thing is, I’ve only had one formal class on Polaris. It was years ago, in a cramped room with a bunch of people who feared computer mice. There was at least one staff member for whom the bar of soap was a forgotten stranger. We learned all about the patron services interface and that was all. Administrators feared our knowing more than needed because we might break something. Never mind that Admin themselves never took a class on Polaris. So almost everything I know about Polaris is auto-didactic. Manuals, training materials, poking the box, breaking things, fixing them – it’s hammer and tongs, but it will teach you a system.

Polaris

Polaris

My experience with the web side of Polaris is no different. The wonderful lady who was here when I was hired was a contract worker filling a position that needed filling. Before her, my predecessor had everything set up on the v3.x PAC because, you know, that’s what we were using.

Everything on the web changed with Polaris 4.x. My first job was, once again, learn fast and well. Things got dirty and, occasionally, ugly. Polaris broke our training server twice. To my knowledge, no one in the IT department speaks German at all and so it became my preference for swearing. In the end, it was good practice putting the training PAC back together three times in a month. Come the upgrade, I had everything in place in less than three hours. I took an extra one to make sure I hadn’t screwed up.

If I learned anything useful at the 2013 Polaris Users Group Conference, it was what we are doing wrong. Maybe “wrong” isn’t the correct term. “Inaccurate” is closer to the truth. We’ve plenty of things calling back to the days of PAC v3.x, which is okay, but it will all break and need to be replaced when we receive a major upgrade. I learned, in one class, how to avert that problem. Granted, it will take me around two weeks to fix things, but once it’s fixed we’re good for some time and the next upgrade should be smooth, at least on the web side of things.

Polaris

Polaris

Beyond the PAC Customization pre-conference class, I attended two classes with Aaron Schmidt. There are undoubtedly people in the world who know more about UX than Aaron, but I’ve never met them. He’s an entertaining and enlightening speaker. I learn more from him in twenty minutes than I would in three hours of reading books about UX. His philosophies of library service and web design mesh closely with my own. He spoke at a lunch where we were served an amazing stuffed chicken breast and later the same day where we covered web design in depth. Like Savoir-Faire, Arron seems to be everywhere. If you’ve got any interest in web stuff, and he’s speaking at a conference you’re attending?

Go. Just… just go. You can thank me in the comments or something.

PUG 2013 is easily the most useful library conference I’ve ever been to. I taught others some tricks and learned a few of my own. These are techniques that I can apply to my job now, like, as soon as I get back to my desk. I actually did implement a couple of minor things the day I got back. I’ve never done anything like that after a big library conference.

Take my advice, especially if you’re a newer librarian — beg, plead if you have to, to go to the ILS conference. It changes your job and alters your outlook.

Leave a Reply

Your email address will not be published. Required fields are marked *

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax