When you’re asked to talk about solving library problems with technology, there’s just so much to say you have to be selective without standing on your soap box.
We’re in the industry of solving problems and continue to move with the pace of technological change. But Part of solving the right problems is asking the right questions.
We need to think about what we want from these technological advances. Before diving in, know your end goal and be able to answer what problem will this solve and *is* it worth solving? Do libraries want this solved?
Give it context. What approaches have you already tried? What have others done? Are there constraints on the solution?
Do some collaborative problem solving – send a non-librarian in to observe and do part of a librarian’s job, you will then begin to understand the focus and priorities of librarians and libraries. No really, partner with libraries (public, academic, special, etc) and work together to learn what the *real* problems are.
The affect of asking the right question is statistically profound. Research shows asking the right question increased the odds of someone’s work having a positive affect on others by 4.1 times. It made the outcome 3.1 times more likely to be deemed important, 2.8 times more likely to create passion in the doer
Think about the people. Who will the work or the product benefit? What are they trying to do? What do they value? What do they hope for? I love the question Clayton Christensen posed in The Innovator’s Solution, “what is the job this [product] is being hired to do?” What is hoped for, what outcome is desired, and what benefit will this solution provide to the beneficiary of your work?
Part of asking the right question is asking the right person. Talk to librarians, not library admin, not library directors but those in the trenches, using your technology to do their work. They probably know it better than you do.
Part of knowing your users, is understanding your relation with them, how you co-exist with each other.
One thing to realize is a major challenge you have as the vendor – imagine, creating something you think will solve a problem. Now, imagine that YOU have the pressure to create something to make a profit, by selling it to a group of people who spend their careers solving problems (through creation) for others, for FREE. Who are passionate about open access and equal access to information. Libraries run on currency of good feelings and resource usage.
You have to convince, this group of people to buy your product, the one that will solve their problem. This group of people who have the mindset of equal access to information for everyone and who willingly (usually…) volunteer their time (free of charge) to share information to help other people solve their problems.
Leverage your social capital, connect with your users, and think critically about what you are building.
What difference would people LOVE? What would the beneficiary of your work really love? Not just like. Not just feel better about. But what difference would they love? That question in particular seems to activate a deeply human power of creative energy inside us. It seems to open our minds beyond the ordinariness of what “is” in favor of what “could be”.
[Story about buying my mini]
Asking the right question can give you all the information you need to solve the problem.
We can solve yesterday’s problems with today’s thinking. Focus on how you can use the knowledge you have now and the resources you have now to fix the problems from yesterday’s innovation.
Technology needs to solve a problem, and it’s up to us, together, to determine what the problem is and if it is worth solving.
We are surrounded by innovation. Living in a world of technology, we are often pushed to do the next big thing, and end up getting ahead of ourselves and problems that really need fixing get put on the back burner or forgotten. Librarians are incredible critical thinkers. We are innately problem solvers and in our profession we are also often in situations where we need to do more with less, so we figure out how to make something work the way we need it too because often the tool we need doesn’t exist.
We all know not every idea that comes to mind is a good idea, not always a bad idea either but often not the right idea.
I want to talk about technology solved by having the right idea, the idea that focused on solving a problem. Created by librarians (some with funding and some without, some with teams, some built by an individual) to solve a REAL library problem, problems that plague us on a daily basis.
MARCEdit - -this software is a prime example of using technology to solve a library problem. Almost 2 decades ago, Oregon State University library was undergoing a major database clean-up due to thousands of MARC records that needed to be fixed. Terry Reese, an OSU library employee, developed MARCEdit to make the process of fixing those record a much more manageable task. No one paid him to do this, he just saw a problem that needed fixing, and access to technology to build something to solve it. It is an incredible tool for database maintenance, that allows for very precise customization of records, using batch tools, APIs, Regular expressions, text editing, record conversion tools, and many other functions that libraries need because data is messy and the functionality we have in our ILS’ often doesn’t allow the precision of bulk change in a simple fashion that MARCEdit does. It’s two decades old, and it is still used heavily, data librarians still LOVE it AND there was even money raised through crowdfunding to continue its development. If you ever want to learn a thing or two about phenomenal customer service, might I highly recommend reaching out to Terry. He’s got it on point. Terry maintains it on his own time, often updating and adding new features, he converses with librarians about things they want to see and functions they could live without, and works to develop the software with those things in mine. With the continued rise in electronic records, the need to manipulate large quantities of MARC records is necessary, along with the need to convert them to other formats for other repositories and systems, that *ahem* do not work with MARC. WHAT?!
So yes, MarcEdit is a fantastic example of a tool that solved a necessary problem that exists in libraries and will continue to exist, the need to mass edit records and clean up data. One that has saved me hours of time and something I’d gladly pay for.
Another project that is solving a current library problem is the Measure the Future project by Jason Griffey (and his team) which was funded by the Knight Foundation. Measure the Future is aimed to solve a long standing library problem. That problem being that we currently have no real means to measure the use of our physical spaces in a quantitative way so we can make better decisions on what we do with our spaces.
On the Measure the future website, the project is described as follows “Imagine having a Google-Analytics-style dashboard for your library building: number of visits, what patrons browsed, what parts of the library were busy during which parts of the day, and more.”
When asked where the idea for Measure the Future came about, Jason stated, “ it comes down to realizing that the things that we measured when I was doing stats for the Library were mostly useless. Size of collection and circulation stats really are just terrible stats overall, and don't reflect how we were being used by the patrons. So I tried to imagine what would be useful stats to have, what would allow us to make predictive, forward-facing decisions, and demystifying the building usage seemed like an obvious thing to try and do. “
*That*, y’all, is using technology to solve a library problem.
Talk about how the app came to be and also talk about the results of the space built that was not matching it’s assigned space use.
Another example I want to talk about is a mobile application I’ve personally been working on, it doesn’t have a name yet… but we call it the Acoustic Spaces App – working with colleagues in university engineering departments, we’re using echolocation technology to help libraries more easily assess the acoustics of their spaces. Think of your mobile device as a bat, sending out sound waves and analyzing the waves reflected back. Bats use echolocation for sight, we’re using the technology to analyze the received data to tell us how reflective a space is. The app will allow users to analyze their space to determine whether its acoustic profile is appropriate to how the space is intended to be used.. The design of good acoustics in libraries, contrary to popular belief, is not to lower noise levels, but rather to enable effective communication in areas where it is required, and reduce disruption in areas where concentration and quiet contemplation are needed.
THIS is technology to solve library problems.
Those are some really great ways problems in libraries are being addressed and solved. But not every idea goes as planned or is as great as those are. I want to talk about technology that isn’t solving problems but raising significant concerns, especially related to privacy, it’s important to look at the failures and to learn from them. Ask the right questions: What did they do wrong?
In 2014 Samsung released a smart refrigerator that syncs with your Google Calendar. A digital calendar on your fridge seems quite useful, replacing traditional calendars stuck to the fridge with magnetic clips. The software that brought the Google Calendar to your smart fridge had a software bug that led to incredibly messy consequences. This bug caused a glitch that if your fridge powers off for any reason, when it reboots after a power outage, it reboots in demo mode with the cooling compressor off and thus a lot of spoiled goods. The problem is digital calendars run on software and the thing with computer software (or anything that connects to the internet) is it needs constant upgrades, it has bugs and requires patches, throughout it’s entire lifetime. Problems like the reboot into demo mode will happen, it’s the life of software. These are problems we have to think about as we approach the internet of things, when analog technology breaks you replace a part, when digital technology has software issues you go and change all of your passwords…
Not only is there concern with the privacy of connecting everything in our lives to the internet, the lifespan of devices like the refrigerator, shorten drastically with smart technology. Typical life of a fridge is roughly 15 years, in software world that’s an eternity and most companies won’t support software that old.
This next one -- to say it left me gobsmacked and shaking my head would be an accurate description.
Bluetooth pregnancy test --
LIKE WT actual EFF?!
Yes you heard me correctly, a test for what can be one of the scariest and most heart-wrenching experiences a woman can go through. There is an app for this that connects to the stick we pee on. An app that lets you know you’ve provided enough urine and then gives you a timer to wait out the agonizing 3 minutes, it provides entertaining options to help you pass those 3 minutes a little bit quicker. Then based on the results more information and tips. and really none of this is necessary. It overcomplicates something that works just fine as is, pee on the stick, stick reads urine hormone levels and either you’re pregnant or you’re not... It doesn’t solve a problem that needs solving; in fact it opens up a door for a handful of other unnecessary future problems, a lot of ethical ones that I don’t think anyone really is in a position to address. Might I also add the incredibly personal data that is being shared across the network, that may or may not be adequately secured.
The point to both of these examples is, not everything in our lives needs to be connected. However, in libraries – there are things that need to communicate cross platforms for us to do better.
Right now the primary focus should be to solve the problems that already exist with current software, these ones are easy to predict because they EXIST and we know about them, there isn’t hypotheticals. Clean up the existing mess before you make a new one.
Since I have the mic which means I have the power, I want to talk about problems in libraries we’d like to see vendors focusing on.
Look at these libraries from all over the world – they are very different than the library 10 years ago. More digital technology, very little physical books, modular spaces that users can adjust to their needs – like our physical spaces our virtual needs are changing. To solve a problem, you need to know what that problem is.
I touched on this briefly earlier but it’d be really nice to have an ILS in the form of Micro Services – Not an all-in-one option but instead an ecosystem that is interoperable and customizable and plays nicely with other ecosystems.
EBSCO sits in a really good position given their recent commitment to the open source ILS OLE. They’ve previously not been contenders to enable change in one of the core fundamental tools of libraries and now committed to continue development on a tool that has been developed by librarians for libraries.
You’re new to a game that’s been a round for a while, there’s a lot of knowledge about how we want the game to change.
Really what is comes down to it is that MARC and the ILS have been the primary focus of our concerns for years and we need to move beyond that and work towards building systems that can evolve as the needs of libraries and librarians evolve.
I propose that you move away the idea of an all in one fully integrated library system and focus more on developing a modular system that is fluid and evolves with the rest of library technologies.
Conceptually OLE is supposed to achieve this, whether that continues to progress in that direction is up to you. We’ve spent the last several years building repositories of data and content and cataloging metadata, do we need to continue to have a conventional ILS modules, like acquisitions or cataloging? or can we leverage the resources we have, to move beyond the traditional modules.
At one point MARC was incredible, it was innovative, and we loved it. It allowed us to create records that could be read by computers, which is a bit ironic since now it is a very restrictive language for working across the universal web interface... and being read by the global computer.
We all want to move forward with linked data and connectivity but in order to do this we REALLY need library systems that allows us to work with records that aren’t bound by MARC– formats that are universal to the web. We need our core library tools to have the ability to work with data that can be transmitted, manipulated and arranged relatively easily by programmers -- like XML or RDF.
Doing any form of linked data with MARC… we might as well be trying to send a text message from a rotary phone. We won’t be able to progress in the direction we need to with this still being the standard format of library records.
Work on that. You want to use technology to solve library problems? Start with that. When you solve that, we can talk some more.
As a Systems Librarian, I will tell you straight up, it’d be great to have an the ability to hook our library systems into our Help Desk software to get accurate data on the what, when, where the system broke for the user. I spend a decent amount of time gathering basic level information about the system before I can even begin to start trying to fix the problem, we can call this the IT style reference interview if you will, the part that’s incredibly important but takes up precious time. I’m sure you can sympathize with me. There are many different pieces grinding gears in the library ecosystem, sometimes staff don’t even know what part of the system they are in OR what system they are using. This isn’t new, at all. Being able to connect our help desk software application to library systems would save a lot of time and confusion, and as far as I know, no vendor created library system has this functionality. HINT HINT.
A friend of mine works for Caltech in Pasadena, California. Their library was doing a major shifting project, when 7,000 uncatalogued items emerged and needed to be accounted for. Most of these items were high potentials to be deaccessioned so cataloging them wasn’t a good use of librarians’ time. Fortunately the material had been accounted for in a survey OCLC had done a year earlier and that data had a large amount of standard numbers… problem was but they needed to have call numbers so they could be classified and assigned to the correct liaison for review on whether to keep the item or not.
Thanks to having access to the data from the survey AND access to OCLC’s classify API they were able to write a simple bash script to assign call numbers based on the OCLC number.
Had they not had access to the data and an useful API did not exist they were looking at MONTHS of work, where instead it took about a week for the team to figure out the script and hours to process.
As our resources continue to move digital, our data is sitting in multiple formats across multiple platforms, the need to link related data together is becoming increasingly important.
The amount of information added to the semantic web daily, hourly, every minute, is astounding. Never before have we been able to collect so much data. But what truly magnifies the effects of data collection is making that data freely available to users in useable formats (not MARC….), without restriction or charge for its use by others.
We are collecting so much data, and data on its own without context, is fairly useless. The Web enables us to link related documents. Similarly it enables us to link related data. Library metadata should be a part of this endeavor to hook together resources, related resources to help make new resources that lead to new discoveries and development of resources that can be crucial to bettering communities.
With data also comes the need for privacy protection. One of the core values of the American Library profession, stated in the ALA Policy Manual and Library Bill of Rights “Protecting user privacy and confidentiality is necessary for intellectual freedom and fundamental to the ethics and practice of librarianship.” So obviously this is something we care about. An RFP issued in 2014 for library systems or databases from Minitex (a tri-state library consortium across Minnesota, North Dakota and South Dakota) asked vendors on the RFP to state “Password storage. Indicate how passwords are stored” 6 of the 9 vendor responses said passwords are stored in plain text. Only one vendor was storing passwords via salted hash aka actually secured encryption, it wasn’t EBSCO. It’s not a secret that libraries are dedicated and concerned with privacy, why Vendors are not spending time to encrypt passwords sent over the network to access their content is beyond me. If passwords aren’t encrypted, it’s a safe bet other data isn’t also being secured. We deal with a lot of information, a lot of data and connecting everything through technology brings in more data this is great for analysis and understanding usage, but unless we step up our security game to encrypt and anonymize that data… we’re stepping into a pot of boiling water. Librarians want access, unadulterated access, to our data but we also want to continue to uphold privacy policies for our patrons. Solve THIS problem, and we’ll all have a little bit less to complain about. Not just through encryption of user login information but through the ability to anonymize data and retain data integrity so it is still useful. Give us data and give us encryption!
Physical spaces in libraries are incredibly important, we’ve just recently started focusing on our spaces and how we can gather better statistics to leverage better forward facing decisions.
Our digital spaces are just as important. Are our applications, websites, databases intuitive to use? How are our using navigating them? We need better reporting options, we’re still interested in measuring usage but we are now more than ever interested in better user experiences of our digital content.
Search terms are great for building our collections and making those decisions but understanding how our filters are being used (or not being used) tell us if our users actually understand how to use these tools.
So, how we can be better equipped to develop technology to solve the problems libraries need solving
Build and develop technology with the Unix Philosophy in mind, develop technology that does one thing and does it well. Build systems to work together. Develop technology to handle information that is part of the universal interface.
Eric S. Raymond’s 17 17 rules that UNIX was designed to follow. Surprisingly, these rules make sense for library systems too. Here are some of those rules, I think you’ll see what I mean.
Modularity - design simple parts, that are easy to evolve and replace Composition - develop programs that can communicate easily with other programs Least Surprise - design programs that build on top of the potential users' expected knowledge Diversity - design programs to be flexible and open Extensibility - design for the future by making protocols extensible, allowing for easy plugins without modification to the program's architecture by other developers, Simplicity - design for simplicity by looking for ways to break up program systems into small, straightforward cooperating pieces Parsimony - Developers should avoid writing big programs. This rule aims to prevent overinvestment of development time in failed or suboptimal approaches Repair - design programs that fail in a manner that is easy to localize and diagnose or in other words “fail noisily”
Build systems that question your own assumptions. The systems we build need to not be systems we own but open systems we give and that can evolve in ways we cannot predict.
It’s a tough gig to have but it’s not impossible. Librarians are eager to share, partner with them. Learn about your users. It’s not always about digital technology, especially now where 2 years is the farthest we can see in business model forecasting. Leverage your social capital, connect with your users, and think critically about what you are building. Strive to gain insight into their perspective, what is it to work in the trenches of the library profession. To think like a librarian you need to know how a librarian view themselves in relation to the profession. How can you understand their perspective? Less talking and more listening. Listen to understand, not to respond. Work to build up your social capital, invest your time in building your connections with your users.
This all sounds a bit rough but being asked to talk about developing technology to solve library problems, it’s a tough subject and it’s not a nice pretty package, where I get to pat you on the back and say “You’re doing a great job!” There are a lot of problems, ones we’ve been living with for long enough that we’ve developed solid workarounds for, to the point that we forget at the core it really is still a problem. Surprise us, actually fix some of these problems. To fix the problems you need to ask the right questions, the problems are there, I’ve just talked about a series of them. We need to build and develop with the Unix philosophy in mind, we don’t need one system that does it all, we need individual systems that each do one thing REALLY well. That are open and able to communicate with other systems, interoperable. Systems that are simple, that work with the universal web interface. We need to build library systems that are fluid. You’re the vendor, creating a product for librarians to use, know what they want, really. We aren’t quiet, we voice our concerns and frustrations, look for them and when you find them, I hope you listen or at least give half an arse to contemplate what is being said. We need to get off the hamster wheel and stop trying to do the same thing over and over again. New and shiny isn’t what we need anymore. We need to solve the problems that have been around for years that currently exist, we can tell you about them. I mean I just did… solve those ones first.
Solve the Problem of Now
Problem (n) : a
situation, person, or
thing that needs
attention and needs to
be dealt with or solved.
IF I HAD AN HOUR TO SOLVE A PROBLEM AND MY LIFE
DEPENDED ON IT, I WOULD USE THE FIRST 55 MINUTES
DETERMINING THE PROPER QUESTION TO ASK FOR
ONCE I KNOW THE PROPER QUESTION, I COULD SOLVE THE
PROBLEM IN LESS THAN FIVE MINUTES.
I FOUND THAT I COULD NO LONGER
USE THEIR SOFTWARE. SO I STARTED
TO DEVELOP MY OWN UTILITY TO SUIT
MY NEEDS. –TERRY REESE
IT CAME DOWN TO REALIZING THAT THE THINGS WE MEASURED FOR LIBRARY
STATS WERE MOSTLY USELESS. I TRIED TO IMAGINE WHAT WOULD BE
USEFUL STATS TO HAVE AND DEMYSTIFYING THE BUILDING USAGE SEEMED
LIKE AN OBVIOUS THING TO TRY AND DO. – JASON GRIFFEY
BUILD SYSTEMS THAT DO ONE
THING AND DO IT WELL.
BUILD SYSTEMS TO WORK
BUILD SYSTEMS TO HANDLE DATA
FORMATS THAT ARE PART OF THE
A take on The Unix Philosophy according to Doug McIlroy
Eric Raymond’s 17 Unix Rules