Beth’s Blog

I need to ask for a moment of silence in remembrance of the URSA brothers, Alleycat and iBorrow.  (Pause…)  And now it’s time to move on. 

Our FLIN Project officially began on October 1, but nothing really exciting happened then.  We have been working on some parts of the new project for months, while others can’t begin until people who don’t actually report to us do some things that we’d like to see happen.  So, work just flowed around that October 1 date without even noticing it.

Here’s a brief update:  The FLIN Project has a staff component and a public component.  Each one is a complex bundle of goals, objectives, and activities.  The main goal of the staff component is to make staff work easier and less time consuming by letting automation do the tasks whenever possible.  Some of that will involve making automation do things it doesn’t yet do.  And a lot of it will involve training (i.e. TBLC Continuing Education) to show library staff how to get the biggest bang for the buck out of tools that are already out there.  More on  that in future posts.

The public component’s main goal is to make it easy for patrons to initiate their own ILL requests from anywhere.  Just like Alleycat and iBorrow, but with the whole state as the ‘group’.  We’ve been building the early parts of that for several weeks, and a couple of libraries are already using our prototype tools.  Our successes so far tell us that we’re on the right track.  And the problems we’ve run into so far tell us this will be no stroll in the park.

I love analogies–OK, I’m addicted to them–and to me this is like the early days of the space program, when we knew we wanted land a man on the moon, but we weren’t sure exactly how to do that.

IBorrow is going away at the end  of this month.  You know that.  And you know that its replacement will have some kind of OCLC flavor to it.  But it gets kind of fuzzy after that.  Will our patrons be using FirstSearch?  WorldCat?  FloridaCat?  Or that new Navigator thingy?  And what about the staff side?  How much of what iBorrow did automatically will still get done that way?
 
The deeper you dig in to this, the more complicated it gets, so let’s start at a nice, shallow simple level.  To allow your patrons to continue to place their own request, you will need to give them access to FloridaCat through your web site and authenticate them, as they move from your system to OCLC.  Read that again.  Lock it in.  As it gets more complicated, it all comes back to that.
 
Let’s complicate “access to FloridaCat” first.  OCLC is a huge organization.  They offer many services.  One of them is an Interlibrary Loan management tool called FirstSearch.  FirstSearch can be used with a number of ‘databases’  The best known of these is WorldCat.  FloridaCat is also a database.  It is a subset of WorldCat, composed of–Surprise!–titles owned by libraries in Florida.  The Admin section of FirstSearch lets you specify which databases various kinds of users will see.  You want your staff to see the sophisticated FirstSearch screen.  You want to pass your patrons on to the simpler and more appropriate FloridaCat search screen.  Both of these–and other OCLC services–are web sites that you reach through a browser.  Since you control your own web site, you would put in the link that goes to FloridaCat.
 
Your ILL staff authenticate in FirstSearch by logging in.  OCLC doesn’t recognize them as individuals through this login.  But it knows what library they are coming from.  You don’t want your patrons to log in as staff.  But you do want OCLC to know what their home library is.  No mystery as to why.  When they request a title, you want the copy that is captured to come to you, not to Boise, Idaho, or somewhere.
 
So, how do we tell the OCLC FirstSearch system what the patron’s home library is?  Two ways.  We’ll do the easy one first:  IP address.
 
Each of your library buildings has unique IP address, and OCLC knows what it is.  If a patron is in one of your library buildings, when he makes a request, the IP address he comes from tells OCLC which library system he’s coming from.

In ‘the old days’ that would have been plenty.  Now it’s not.  Lots and lots of patrons do their library shopping from home.  They don’t have access to your staff’s login, and OCLC does not recognize their home PC’s IP address.  What’s the solution?  There are two.  Let’s call them Plan A and Plan B.
 
Plan A is to use whatever tool you currently use to let your patrons connect to your online subscription resources from home.  If it can take patrons to a ’success URL” for those resources, it can probably do the same for OCLC’s FloridaCat.  When your patrons use Gale tools or Ebsco tools from home, the vendors know they’re your patrons, and you get the usage stats.  So, you may already have the tool you need to let OCLC recognize your patrons.  But if you don’t, we go to Plan B.
 
Plan B is RPA.  We have it at TBLC, and we know it is pretty versatile, because we’ve used it with many libraries in the past.  So, RPA would become the middleman between your system and FloridaCat.  Here’s the short version.  The FloridaCat link on your web site takes the patron to RPA at TBLC.  RPA gets his barcode, looks him up in your patron database, and–if he really is your patron–sends him to FloridaCat with a note pinned to his shirt that tells OCLC what library he started at.
 
This is Plan B and not Plan A, because there are some complications in authenticating patrons from multiple library systems to the same database.  If you use your own authentication system, it is easier to make sure OCLC knows what the patron’s home library is.
 
Now, go back to my original statement of what it will take to let your patrons continue to make their own ILL requests.  I hope the ‘long version’ fleshed out the details of the short version without messing up its clarity.
 
Now, where is Navigator in all this?  As I write this on September 1, we don’t know for sure.  OCLC and The State Library have not yet cut their deal on its cost to the state and its availability to us.  If we get access to it later this year or early next year, it should reduce staff work at many libraries, and it may offer a better interface to search FloridaCat than we can get with the other potential OCLC interfaces.  But it won’t help anyone in September, and probably not October. 
 
Until Navigator steps up to automate staff tasks. the staff side of the new world will look a whole lot like traditional OCLC ILL.  But with one big difference.  A big, big part of our grant is helping all libraries–including yours–wring every possible drop of labor savings out of OCLC and the FirstSearch software.  Again, though, those classes start in October.

Please take this as a starting point for planning your transition out of iBorrow and into the FLIN project.  I’ll be putting out more stuff in more detail, but I didn’t want to put you to sleep so early in the project.  Please contact me with any specific or general questions you have at this time.

–Al Carlson

The URSA products–Alleycat and iBorrow–were great ideas, when they came along.  So was the League of Nations.  And the Apple Newton.  Unfortunately, none of them was able to live up to their expectations.  The necessary environment wasn’t there to support them.

We can’t do much about the Newton or the League, but we do have a plan to enable Florida libraries to continue doing cost effective, patron initiated resource sharing, after we close the door on iBorrow at the end of this fiscal year.  The plan involves assembling a number of “tools” that already exist and combining them in a new way.  Think “MacGyver”.  We’ve submitted a grant proposal to the State, and we expect to hear their decision by the end of July.  Assuming they give us the green light, we’ll launch the FLIN project in October.

You’d probably like to know more about it before it starts.  And you can.  Beth and I have a road show that we’ll be happy to present to you and your staff.  It takes about an hour, and that includes time for your questions.  There’s no charge, but having some bagels in the room would be a nice gesture on your part.

If you’re interested–and you should be–contact Beth or me to make an appointment.  I’m carlsoa@tblc.org and Beth is farmerb@tblc.org.   Want to call us?  Dial 813-622-8252.  Enter 237 for me and 228 for Beth.

–Al Carlson

But don’t delay! Ms. Has-it-all-but-wants-more keeps calling us back to ask why she hasn’t gotten hers yet.  And she can’t even spell iBorrow.

 –Al Carlson

The latest build of iBorrow was installed on our server in Provo Friday evening, and we tested it over the weekend.  Our assessment so far is that it passes the test nicely.  Here’s some detail.

Java 1.6 compliance:  Yes.  No problems at all.

Faster “Edit Request” response:  Well, maybe.  A little faster, I think.  It’s not yet what you would call ’speedy’, but if you can set up a three way race with MS Vista and a glacier as the other two competitors, you can bet on URSA.

Proxy Request Improvements:  The patron’s barcode is now readable as you type it in.  Yayyy!

Incoming Loan to Fill Loan:  This one is lovely.  It is still true that URSA can’t place a hold on your local system, if it can’t give your server a single unique bib record to request.  That is why ISBN’s are so important.  But there are several other things that can drop a request into your Incoming Loan box, even if it has an ISBN.  Most of these are transient.  So, if you could try again, the hold would take.  The new build lets you do that.  If you go to your Incoming Loan space and find requests there with ISBN’s, you can right click on each request, choose Process Request, and watch it go to Fill Loan.  That’s not the important part, though.  The important part takes place in your server, where a Hold gets placed, and a copy will show up on someone’s pick list tomorrow morning.

More Detail in History:  I’ll send this out to you as Email and attach a spreadsheet Holly gave us.  When you edit an item now and look at its History, you (and SirsiDynix Support) will see a lot more information.

Availability Rules and LOLR Issues:  These weren’t really testable over one weekend.  Time will tell us how much closer to ‘perfect’ iBorrow/URSA is at following the Availability Rules and properly routing requests that run into LOLR issues.

As we learn more, we’ll share it with you.  And I trust you to tell me when you find something that doesn’t work.

–Al Carlson

It is Saturday evening, and so far the new build looks good.  Very, very good.  It has been well behaved in all the tests I’ve done so far, and the new features just add to the good feeling.  Like having the vinyl in your car replaced by hand sewn leather.

The neatest trick is being able to go into the Incoming Loan work space in the client, find a request there with an ISBN, right click and ‘process’ it, and have it show up in Fill Loan.  With a hold placed in the local system.

I used this a lot on Friday evening, because both Hillsborough County and Sunline have been ‘resistant’ to iBorrow requests for the past week.  Both issues were resolved Friday afternoon, just before the new build was loaded, so there were LOTS of requests hanging around, eager for a chance to create a real Hold.

It also runs nicely with Java 1.6.

We’ll keep testing and keep you informed.

–Al Carlson

Hernando County has been using iBorrow for a few months now, but only as a Reference tool. That is, when a patron came to the desk needing help locating a title, and the Librarian concluded it was not something Hernando County could provide, she or he would call up iBorrow and use that.

But as of Monday, April 21, that changed!  Now, Hernando patrons who can’t find what they want in the Library’s online catalog can click on—are you ready?—”Can’t Find It?”   That takes them to a page with a couple choices, and one of those takes them to an iBorrow link.

This is sort of a soft launch for now. They plan to do some classes in May and bring in the brass band from River City in June.

It’s been days—possibly weeks—since we threw anything new at you.  And we don’t want you to get complacent.  So, here’s another opportunity for change and excitement. 

As you may have heard, the Statewide Delivery Service is getting an upgrade.  On Monday, January 14, we’ll begin Beta Testing barcodes on orange Delivery bags using print-on-demand labels. (The TBLC and Ft. Myers hubs will be the participants in the Beta Test.)   Several of you have contacted TBLC to ask how you should integrate these new high tech labels with your existing procedures for AlleyCat and iBorrow materials, when you become part of the action.  Here’s the plan. 

If you currently use AlleyCat labels, use the new barcoded labels, but whack them with the iBorrow rubber stamp before you put the label into the orange bag pocket.  This will alert anyone with 20-80 vision or better that these are AlleyCat/iBorrow items and should be handled accordingly.  If you don’t have an iBorrow stamp, contact Vickie Frost at frostv@tblc.org, and she will send you one.  If you don’t currently use AlleyCat labels, you may ignore this message. 

And if your palms are feeling sweaty, because this is the first time you’ve even heard of the whole idea of barcoding Delivery bags, visit www.tblc.org/delivery.  All your questions will be answered.

After some scary moments Friday evening, the second load of our new build passed its tests and is now up and running.

Whew!

For a partial list of new features, see the article below called “Early Christmas Gift”.

–Al Carlson

Users who jumped in early Monday morning and opened up the new iBorrow build that was loaded on Friday evening were heard to mutter to themselves, “This new build sure looks a lot like the old build.”

That’s because it was the old build.  Our weekend testing revealed a deal breaker, so we had SirsiDynix restore the old build Sunday evening.

We’d hoped that our testing would be just a formality, and that we’d sign off on the new version by Saturday noon and go back to Christmas shopping.  But we ran into a problem Friday night that the SirsiDynix engineers were not able to diagnose and fix.  Not that they didn’t try.  We caught Holly at the SirsiDynix Christmas party Friday evening, and she had Keith Poole in on the problems before the first round of canapés was gone.  We all continued testing the next day, but by Saturday afternoon, it was clear that this was not a trivial coding issue.  Peter Fripp restored the build we’ve been using late on Sunday afternoon.

The problem we ran into was a variation on one we’ve seen before:  declining requests.  About a third of the time, we would get a rude and cryptic error message, when we tried to decline a request.  We hoped to find the pattern behind the problem.  Maybe something like, “When the requesting library is their own Lender Of Last Resort and they are set to unmediated, declining will fail.”  Nahh!  Nothing that easy.  I had three requests from the same library lined up in Fill Loan in the iBorrow Training database.  The first declined fine.  The second failed.  The third worked.  Go figure.

So, Holly, Keith, Peter, and Aaron will put the new build up on the rack (Think mechanic, not inquisition) this morning, tear it apart, and see if they can find the cause of this nasty bug.  You will keep using the build you know and have grown to love.  And we’ll let you know when we’re ready to try again.

–Al Carlson