As all law libraries do, we try to thread that needle of being efficient and doing things with the resources at hand. We’ve slowly been moving towards delivering e-resources with OCLC’s EZProxy. Like many libraries, our internal and externals users overlap, and we have competing goals or needs:
- we only want to show users links they can interact with. Showing a link that requires they be physically in the library, when they’re sitting in their office, is not good.
- we want to support the fewest number of pages or resources possible. If there’s no need for an internal and external list of resources – two web pages or what have you – then that’s fewer pages our staff has to administer.
So the focus became how to use some form of scripting language to hide links for those visitors who were not sitting in the library.
Low Technology Bar
That’s not too difficult if you have the technical chops AND the access. But if a law library is running without strong IT support or integration, or outsources a function, it can be challenging. At a previous law library, I was able to rely on the Microsoft Internet Information Server (IIS) and active server pages (ASP). If a lawyer logged in to the extranet, they were served links if they had agreed to a terms of service.
If caselaw = “x” and qTOS = “Agreed” Then
Response.Write(“<dd><a href=verify2.asp?username=” + username + “&password=” + password + “&TOSValidation=agreed>Search 50 state and Federal case law</a></dd>”)
Not pretty but it served its purpose.
If you’re not running your own systems though, the vendor may not allow you to program what are essentially mini web apps. I’m not sure all of my code would stand the scrutiny of proper web development team, although it served the needs of a small law library.
Stitch a Fix Together
This is one of those things that may exist already but, if you don’t know what it’s called or where to find it, it might as well not. In my case, I needed to figure out a couple technical things:
- I needed to know how to get a user’s IP address. I was going to test for internal IP users (our library has a static IP with a fixed range)
- I needed to know how to test that IP address
- I needed to know how to change whether some HTML was displayed
Some of this was already familiar ground to me. I knew I could use CSS and the display:none and display:block options. But much of the rest was new or so old I couldn’t remember.
- Tim Penner’s post talking about how to use https://ipify.org to get an IP quickly and easily
- Andrew Bedford’s post about how to convert the IP captured with ipify into text
- A W3Schools page on slicing a string; I can never remember things to do with strings
Stir that all together, and I ended up with this:
This is the (half-baked, perhaps) final cake. But I used a couple of lines to print the IP address onto the page, so that I could that the script was actually working. Real coders would do this in a console or with a tool that would show the code. As a workaround, I just printed the variables to the page.
There are better, cleaner ways to do this. So if you take away anything, don’t take away the idea that I am any sort of coder.
Instead, what struck me as I was working on this was how little I needed to know to be able to create a simple workaround. I needed to know:
- where to find other people who would have done some or all of the same type of work
In other words, typical librarian stuff. Not everyone needs to know how to code, although solo librarians can benefit perhaps more than any other from having a passing understanding. I’m still not entirely clear on why certain parts of my Frankenstein’s monster code are the way they are.
It’s an example of where a librarian can do something on their own. We all have to cut according to our cloth, and not everyone has the same access to skills or resources as other libraries. Perhaps most importantly, it appears to have achieved the balance of technical skill, technical access, and small goals that will hopefully improve our researchers’ experiences with our site.