Idea I hope will become trends: ask for what you want

In the final installment of my ALA Annual faux-cap, I want to talk about asking for what you want.

The previous installments: user stories, communication, and assessment.

The last session I went to in Anaheim was a panel discussion about how ILS vendors were planning on dealing with the challenges and changes that RDA's implementation would inevitably cause.

When the moderator opened the floor for Q&A, a very different discussion erupted. Basically, the audience called the vendors out on their shenanigans.

Because, while the vendors had, indeed, made provisions for new MARC tags, it didn't seems as if they had really given much consideration to what a post-MARC world might look like. And that's a problem.

The discussion was...lively. Catalogers want tools and mock-ups of what a RDA-driven, post-MARC catalog might look like. ILS vendors don't seem to want to create even a beta version of such a catalog until the landscape is more stable.

What seemed most shocking to the catalogers in the room was that vendors seemed surprised that catalogers were even interested in such mock-ups. And their defense seemed to be that until and unless catalogers make their wishes known, vendors can't create the tools that catalogers want.

It seems to me like ILS vendors and libraries are having a stand-off. It's like they're playing chicken about how metadata will be represented in this post-AACR2, post-MARC world. Libraries are waiting on vendors who are waiting on libraries.

My observation about this stand-off is that if you want to affect real and lasting change when it comes to vendors, convince the people in your organization who sign-off on paying the bills that what you value is worthwhile.

So, my last and final takeaway is to ask for what you want.

At your own institution, talk to your Systems staff and UL about what you want users to be able to do with the metadata you're creating. Find products or dream up solutions to make these dreams a reality. Talk about what makes this metadata so important for users--for searching and retrieving items and for serendipitous discovery--and what would be so devastating for your users about outsourcing cataloging or accepting sub-par vendor-generated MARC records.

At conferences, visit the vendors your library works with. Ask them tough questions about what they're doing to move toward a post-AACR2, post-MARC world. Tell them what you want your users to be able to do with the metadata you're creating and ask them how they plan to make that happen. Talk to them about task forces and committees you know exist where libraries and vendors intersect and ask them what they're contributing to them.

Find your tribe and get involved. Join your state's library association or ALA. Or both. Join a committee or an interest group that's tackling these issues and get to work. Start learning to code and come up with your own solutions to these problems. Use social media to find like-minded folks and start learning about the issues.

To quote Rage Against The Machine:
"It has to start somewhere
It has to start sometime
What better place than here?
What better time than now?"

Be visible. Be proactive. Be awesome.

Ideas I hope will become trends: assessment

This series is, at its core, a recap of my trip to ALA's Annual Conference in Anaheim. But I prefer talking about the practical applications of what I learned to simply recapping programs.

The first installment was about user stories and the second was about communication.

The third installment is about assessment.

I was not planning on attending LITA's Top Tech Trends panel. But, I returned back from an off-campus lunch too late to attend the session I'd hoped to catch and too early for the next round of programs.Having found myself with a few minutes on my hand, I decided to catch a few minutes of the program.

Meredith Farkas was one of the panelists and I found myself nodding in agreement when she talked about how academic libraries can't really stand on the assertion that the library is the center of the academic community anymore. Instead, academic libraries are being asked to justify their impact on those they serve.

Farkas suggested that assessment tracking tools were a good way of managing data that would help libraries build stories of user impact.

But this isn't so much about what Farkas had to say as it is about what people had to say about what she had to say.

It seemed like the Twitter backchannel was musing about how difficult it was to cultivate the kind of organizational culture that breeds an interest in assessment. Basically--nobody teaches this kind of stuff in library school.

The thing is, I couldn't agree more with the notion that academic libraries are being asked to justify their impact on those they serve. It's no longer enough for them to say that they're the center of the academic community. Researchers, both novice and expert, are finding other sources for information than traditional library resources. And many academic libraries grapple with how to stay at the center of the campus community--a completely different challenge.

And I also couldn't agree more with the idea that data helps libraries build stories about their impact on the lives of users.

And, while we're at it, I also couldn't agree more with the idea that creating that kind of organizational culture is really, really hard.

But it's not impossible.

So, how do we do it? How do we create organizational cultures in our libraries that embrace assessment and the data it generates?

I think we start by shifting our focus toward things that are measurable. Which means that every project or program needs to have outcomes built into it during the design phase. How else will we know if the project is successful? And, in the case of programs, how will we know if the audience has learned what we'd like for them to learn?

Academic libraries need to think critically about how adopting this kind of culture could affect them for the better. What would it look like to have data supporting your assertions about how bibliographic instruction sessions have prepared student researchers for upper-level research? It's one thing to consider gate count (which is valuable data, indeed), but it's another to show how you've created good consumers and stewards of information.

I think it's equally important for user-centered back room folks to generate, synthesize, and store data as well. If it's true that academic libraries are being asked to justify their impact on the academic community, it's equally as true that many units performing back-room functions are being asked to do the same. And, when the day comes that you have to advocate for your job, it's much easier to do so using data.

So, try gathering some usage statistics after you finish a cataloging project. Did usage of a hidden collection go up after you added it to the catalog? Did analyzing that serial prompt more people to use it? This kind of data collection can help justify some of the most important work you're doing.

Alternately, though, data of this kind can help you decide what to let go of when budgets are tight and time is fleeting. You can see what your users value most and what they can live without and make decisions about resource allocation accordingly.

So...start with an outcome and measure your success accordingly. And let the data do the talking.

Be visible. Be proactive. Be awesome.

Ideas that I hope will become trends: communication

If you missed the first post in this short series, you can catch up here. The first post was about user stories and focused on a presentation that I saw at the Heads of Technical Services IG meeting.

The second idea that I hope becomes a trend is open dialogue between catalogers and, well, everyone else. The genesis of this was a bullet point from the presentation that Scott Piepenburg gave at the Competencies and Education for a Career in Cataloging IG meeting.Piepenburg's presentation was about what Catalogers would need to be able to do in a post-AACR2, post-MARC world. One thing that he suggested is a must is that Catalogers need to not only understand what their ILS can (and cannot) do, but they must also be able to communicate these limitations to others.

It took everything I had not to jump for joy or to stand on my chair and cheer. I didn't, though. It was a small room and kind of crowded.

I think that catalogers do a pretty decent job of understanding the limitations of our ILSs. We spend a lot of time working with them and, as a general rule, get what they do both well and poorly. Where it breaks down, sometimes, is communicating this information to our colleagues. Whether it's our colleagues in IT or our colleagues staffing the front lines, it is our job to communicate well with them.

Having a basic knowledge of coding can help us communicate more effectively with IT staff. We don't have to be coding wizards, but we should be able to talk about how our systems do parse out data in MARC records and, perhaps more importantly, how we wish they did.

Having a basic understanding of how users search for information can help us communicate more effectively with front line staff. We don't have to spend a lot of time on the Reference Desk (though it wouldn't hurt), but we should be able to talk about how users can do more effective searching.

So, how do we become better at communication with others? I have a couple of ideas:

• If you want to learn the basics of coding, Codeacademy can help. They even have a program called Code Year which will walk you through the basics of languages like Javascript. And if you're looking for support, there's a CatCode wiki whose function is to support dialogue between coders and catalogers. In this case, I suspect it's a lot like learning the language when you visit another country. You don't have to be proficient in it, but the natives appreciate that you're trying to speak their language.

• Attend (open) meetings in departments other than your own. At my former place of work, there was a monthly meeting of subject librarians that was open to all interested staff. I didn't go every month, but I tried to go fairly regularly. Attending this meeting helped me understand the challenges that subject specialists faced when helping users which, in turn, helped me think differently about the work I was doing. This meeting was also sometimes the only way that I learned about issues that I could help solve but that nobody thought to tell me about--not because they were trying to leave me out of the loop, but because they didn't realize that the problem could be solved.

• Get your hands dirty in projects that involve other departments. Though the bulk of my job duties involved cataloging, I taught in my former place of work's Freshman Writing Seminar. I also worked with our Digital Library Services unit and our Web 2.0 initiatives. I made valuable contacts and learned a lot about what other people the organization do. 

I think the moral of the story is that it's all about relationships and empathy. Learn to speak the language of the people you work with. Be friendly and empathetic and take the time to answer questions that your colleagues have about the work that you do. 

What are your suggestions about developing rapport with other units? How have you opened the lines of communication?

Be visible. Be proactive. Be awesome.

Ideas that I hope will become trends: User stories

One thing I have learned after attending ALA's midwinter and annual conferences is that, if you pay attention, you can spot the beginning of trends. Is there more than one program on a particular topic? Consider it a trend. Is it an idea you've heard at multiple programs? Consider it a trend.

And one thing I've preached is that after you spot a trend, you have to figure out how your library is going to deal with this trend. Maybe you find a way to implement a trend into your library's operations. Or, maybe you consider a trend and decide it's not for you. But either way, you have to consider it.

At ALA's Annual Conference, I noticed a few interesting trends that are worth considering. Over the next couple of days, I'll write about these trends--starting with the idea of user stories.

Okay, so let's talk about user stories.

If you're familiar with software development, you're probably familiar with user stories. Essentially, you interview users to find out what they need a piece of software to do. These stories inform the software's design process. It's an opposite way of thinking than the usual business of most libraries which is to offer solutions that they think will meet a user's needs.

I attended the Head of Technical Services IG and heard about how the University of Chicago used user stories to inform the catalog design they worked on. They conducted 20 interviews and, from those interviews, they identified 200 unique stories. These stories fell into categories like browsing, composition of full records, and integration with other tools.

I like the idea of integrating user stories into any major design or redesign of a library resource. Libraries often believe that they know what their users want a piece of technology to do. Whether it's a citation manager or the library catalog, we think that we know how users work. And many times, we can bring anecdotal evidence to support that. Sometimes we even do usability testing to choose between options we've identified. But none of these things give users a voice during the initial phase of designing a resource or deciding which resource to purchase. Often, by the time we ask our users for their $0.02, the decision has already been made. And we try to do our best to help users live with the decisions we made by training them on how to use the resource we've purchased. But how many times have you taught a class on a piece of technology and had to tell someone that it doesn't do what they really want it to do?

How would things be different if we let the users tell their own stories and then found ways to solve those problems for them?

We might make different choices about the technology we decide to purchase and we might find open source solutions that meet our users' needs better than vendor-supplied solutions. 

We also might start asking for more from our vendors in the way of flexible implementations. Rather than purchasing the solution that comes the closest to doing what we think our users need it to do, we can approach vendors with evidence that we need them to provide implementations of solutions that do what our users actually need them to do.

So...now that you know what a user story is and have heard about someone doing it well, how will you integrate this trend into your library? 

Be visible. Be proactive. Be awesome.

A thought about novice researchers

This is a post that has nothing to do with cataloging. I hope that you will read it anyway.

I don't spend a lot of time working with end users or doing instruction, but I do teach one library instruction session per semester to several sections of our Freshman Writing Seminar. And that experience has taught me a lot about how students handle research problems. When I pulled "'The Rolls Royce of the Library Reference Collection:' the subject encyclopedia in the age of Wikipedia" by John W. East out of my to-be-read pile, it opened an interesting rabbit hole down which I currently find myself.

The main assignment that our Freshman Writing Seminar students are given--the one that all of their small assignments build toward--is a final paper that analyzes a primary text through a discipline-specific lens (e.g., sociology).

One thing that has become painfully clear to me over time is that these novice researchers aren't often equipped to synthesize the discipline-specific material through which they are supposed to be viewing their primary text. The concepts and jargon are often unfamiliar to them and they are not always willing to do the leg work to figure out what they need to know.

Two important facts about the course:
1. It is required of all Freshmen
2. It cannot be tested out of.

Though the students (again...generally speaking) in these classes are conscientious learners and want to get good grades, the stakes simply aren't high enough to warrant a lot of extra work to understand the concepts.

The point of the course is to acclimate Freshmen to collegiate-level writing and the shift from regurgitation of facts to the synthesis of information. The research process does factor into this shift, but learning how to use the library is only one part of that process. I can show a class how to use an article database to find scholarly articles on a topic, but it is up to them to synthesize that material. And part of that synthesis process is understanding the concepts and terminology used in the articles.

In walks the subject encyclopedia, waving it's arms and yelling 'I can help! Hey...pick me!'

Subject encyclopedias are a great way to expose researchers to basic information about a concept. What's not to love? They cover all of the basics on a topic and provide a bibliography for finding more information.

But if I'm honest with myself, I realize that this isn't how I do research. I don't come across a concept I don't know and then refer to a subject encyclopedia to better understand it.

I go to Wikipedia.

East's article juxtaposes the quick-and-easy nature of finding information against the authority of the subject encyclopedia. And I think he makes a good point. Wikipedia is easy to access, but it isn't the most academic of sources. And he's right to point out that many instructors are nonplussed when their students cite Wikipedia as a source.

But if all a student needs is to quickly understand a concept, what's so wrong with offering Wikipedia as a way to do that?

As a librarian, I struggle with the answer to that question. I understand that you can't trust everything you find online. And I understand that the subject encyclopedia is probably better suited to give researchers the kind of support they need.

But for Freshman researchers who are often balancing a full course load against the challenges of navigating life away from home for the first time, the leg work it takes to find a subject encyclopedia to learn about a concept is often not worth the payoff they get.

I think that in this semester of Writing 1, I'm going to talk about subject encyclopedias. And I'll probably put links to a few of them on my course guide. But I also think that I'll be more conscious of telling students that context, wherever one finds it, is a valuable tool for researchers.

Be visible. Be proactive. Be awesome.

Citation:
East, John W. "'The Rolls Royce of the Library Reference Collection:' the subject encyclopedia in the age of Wikipedia" Reference & User Services Quarterly 50.2 (2010): 162-169.

Fixing the PR problem

I tweeted this yesterday:
I've come to the conclusion that libraries, generally speaking, have a PR problem. We do a crap job of explaining to users the how and why.

The problem with our inability to explain the how and way leads to feedback from users that makes us feel especially uncomfortable. We react defensively or want to dismiss it and often our response is more ham-fisted than anything else.

There seem to be two kinds of feedback that we get that speak to this PR problem:
1. Users ask us to develop services we've already developed but haven't done a good job of marketing. Or, users ask us to better market something that we've been trying really hard (but failing) to connect with users on.

2. Users balk at a reality (usually a policy) that can't be changed because of the way we've negotiated a contract or a law that exists.

I think there are two ways to solve this problem.
1. Be transparent in all things--even the unpleasant ones.
Sometimes the response to the requests that your users make is not the one they want to hear. But, as a general rule, people want to be heard and they want to feel like their voice matters. Explain your policies clearly and without jargon. And when you have to say no, explain why in an empathetic way. Log the suggestions and complaints your users give you and respond to them in a public way. Don't make people feel ashamed to ask for what they want, even if you can't give it to them.

2. Be where your users are...not where you think they are.
If you're trying to promote a service, put up fliers in your students' dorms. If you're trying to get more people through the doors of your library, step outside your library and find out why more people aren't there. Or, even better, take your services on the road to where people do spend their time.

It's hard to get out of the echo chamber and learn to tell the stories of your users and their experiences. But part of fixing the PR problem is seeing your users face-to-face, listening to their feedback, and responding to it swiftly. Sometimes that response is a tweak to your services to make them easier to use, but sometimes the response is to explain those services (and their limitations) in language that your users can understand.

Be visible. Be proactive. Be awesome.

What "fix the catalog" might really mean

I often wonder what users mean when they say that we should "fix" the library catalog.

I think that there are a lot of folks who find the catalog difficult to use. It is true that our catalogs have user un-friendly interfaces. It is true that our jargon makes the barrier to entry pretty steep.

These are real issues that require much consideration and better answers than the ones we've come up with so far.

But I have come to the conclusion that "fix the catalog" can also mean one of two things:
1. I don't know how to use the library catalog.
2. The library catalog gave me wrong information (e.g., that book was supposed to be on the shelf, but it's not there).

I feel like libraries confuse these two issues with the idea that people find the catalog difficult to use. They buy discovery layers and web-scale discovery systems. They design and re-design their websites. All of this time and money, and we still hear about how we need to "fix" the library catalog.

All of this has led me to two conclusions:

1. We need to educate our users on how to get from the catalog to the stacks and what to do if the information in the catalog isn't right. A reference librarian at MPOW had a brilliant idea--teach a workshop that is aimed at Freshmen about how to find a book in the catalog and then locate it on the shelves in the library. We've created many video tutorials on how to come up with keywords, how to search the catalog, and how to request books from other libraries. Make your users good at using your catalog is more difficult than buying a new ILS add-on to make your catalog user-friendly. But it also pays rich rewards.

2. Allocate more resources for circulation services like shelf-reading or circulation inventory. One of my first job duties as a library page in a public library was to shelf-read the sections that I was responsible for shelving. It was amazing how many books we had decided were lost that were actually hiding out in another area. When I worked at a middle school library, we did circulation inventory at the end of every school year. We found many books on the shelf that we'd either considered lost or still checked out.

I think that we need to be mindful of the ways in which our catalogs work. But I also think we need to listen to our users and really figure out what they're trying to tell us about our resources. It's wise to remember that the quickest (and easiest) fix isn't always the best one.

Be visible. Be proactive. Be awesome.