Balance Tech Resources with Tech Needs

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.

In our case, we were limited to using javascript, style sheets, and HTML.  This has a significant drawback.  If I can use PHP or ASP or whatever language, I can control the experience better.  Let’s say a lawyer visits a site running on PHP.  If that lawyer is not in the library, they will not see the links.  With PHP, they can’t even see the links if they look at the source code of our pages.  It’s the benefit of server-side options.

Javascript runs on the client.  So our solution was only a security through obscurity sort of hack.  We wouldn’t have been able to achieve it if security was a goal.  But it’s not.  The links are unusable unless the click occurs in our library – we use IP authentication for getting to the resource – or the user has her own license or account.  Since our focus was just to declutter the page, the fact a user can right click on the page, View Source, and see the links, doesn’t matter.

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.

I’d highly recommend that any librarian who has even a hint of curiosity take the Codecademy or similar javascript tutorial.  It’s a great way to just understand the lay of the land.  But that’ll only get you so far.  My other frequent tools are tech web sites and web search engines.  Between the two of those, I soon found:

Stir that all together, and I ended up with this:

#hiddenLinks { display: none; }



<script type="text/javascript">
window.onload = function () {  //load script when page runs
var script = document.createElement("script");
script.type = "text/javascript";
script.src = "";  //get IP from remote service
function DisplayIP(response) {
var visitorIP = response.ip;  //converts IP into variable to use below
var firstOctets = visitorIP.slice(0,7);  //grabs first 7 of IP variable
if (firstOctets == "11.11.1") { //tests to see if first 7 match our internal IP or not
document.getElementById("hiddenLinks").style.display = "block";  //change CSS to show block of text, otherwise stays hidden

<div id="visibleText">
<p>This is the visible text.</p>
<div id="hiddenLinks">
<p><a href="">First Hidden Link</a></p>

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:

  • the basics of the technology (HTML, or CSS, or Javascript) that I was working with, enough to knit together pieces of it
  • 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.