If you use Google Analytics, do you ever wonder what the “Search Terms” in the dashboard could mean? One library-centric (and probably highly contentious) use is to capture search terms used in online databases. In the broad sense, these databases are any search entity you may have such as journal finders, discovery layers, ILS catalogs, etc. If you can add Google Analytics code to the website and the search terms are retained in the url, you can almost definitely capture search terms. (Note: there are most definitely other ways to gather search terms, but I’m sticking to this version for now).
In your Google Analytics account, go to the Admin for the account/website you want to capture search terms for. Under View, click View Settings. This is where you can adjust the basic settings regarding what you want captured. You’ll need:
- the website’s base url (most likely everything before a question mark)
- your current timezone
- parameters you want to exclude like session id (look at the url and/or any documention to determine what parameters you don’t want to be analyzing)
- turn “Site search Tracking” on
- the query parameter(s) (again investigate that url for your search term and enter the identifier used to signify what is the search term)
Don’t forget to click Save.
Enjoy watching the search terms roll in and perhaps you’ll discover the need to purchase items in a different subject area or the need make it easier to find certain resources.
After a long hiatus from tinkering with library technology due to chairing a classroom renovation committee and doing the backend work of a book inventory project, I finally got to some of my sidelined to-do lists.
Google Analytics (GA) is one popular tool used for tracking website usage, however, the default setup only tracks usage within the domain listed in the settings. For a library with lots of links to external resources like catalogs, journal finders, databases, etc. the default setting can feel lacking. It’s also only so interesting to know x number of people visited your site, spent at most a few minutes on your homepage and left. Event Tracking solves that dilemma.
Right now, I’ve added outboundFormTracker to track our LibAnswer search box, eventTracker to track our EDS search box (it wasn’t acting like a form for autotrack, so I did have to add a small amount of code to the submit input item), outboundLinkTracker to track everything else. So far, the heaviest usage from our homepage is EDS and our database list. I look forward to seeing what is and isn’t really used over the summer and into the fall semester.
While working on an upgrade to ILLiad 8.6 from 8.5 I was reminded that the tabindex attribute is not necessary and that I haven’t yet completely removed this code from our ILLiad webpages. I’ve removed some of the references, but at first glance, I’ve assumed this task would be daunting, after all, there are dozens of webpage files that would need to be checked.
Not so much! With about 5-10 minutes of thinking/work, I was able to remove over 400 instances of tabindex in all of our ILLiad webpages!
After some testing on a small batch of files I settled on the following process:
- First, I created a regular expression to match our tabindex instances: (tabindex=”)\d+(“)
- Then, I opened all of my local ILLiad webpage copies in Notepad++
- Using the Replace feature (Search->Replace), enter the regular expression in Find What
- Under Search Mode, select Regular Expression
- Click Replace All in All Opened Documents
- Then click File -> Save All
- Finally copy the local files to the server
I was recently asked this question at a campus event and immediately wondered why I never asked that question before. The inquirer managed a website for a research network that has several pages containing a bunch of relevant publications to the research topic. They wanted to combine all the citations onto one page yet still allow for the different subject areas to be searchable. “Could a citation manager do this within the college’s website architecture?” I was asked.
The user was already familiar with Zotero so I chose to focus on possibly using this tool as the backend and dynamically displaying the results on a webpage…and there was success. Zotero lists plugins on its support pages including several designed for website integration.
Example of BibBase within institutional website.
Consequently, BibBase is my recommendation for anyone who is willing to use Zotero and may not know a lot about coding. Note: I didn’t look at integrating into WordPress or content management systems and would re-evaluate if those platforms were involved.
There were two other options that looked interesting and could be worth pursuing if you had the knowledge and/or patience to learn.
Zot_bib_web – Displays the publications and has a nifty search box. The catch for some is that it involves running python scripts and the script can only be updated once a day. The directions looks straight forward but if mentioning python scripts scares you, this probably isn’t the tool for you.
RefBase – This one also has potential and it has the sought after search box. However, I chose not to pursue it for this request because of the need to run php and create additional tables to a database. Doing this within the institutional website is just not an option at this time.
The default ILLiad webpages tend to leave users questioning whether their renewal request went through or their request was cancelled… or you get the idea. The small status alert under the institution’s name, just wasn’t noticeable enough.
Submitting, renewing, and cancelling requests takes you from the detailed item / request screen to the main entry page and the status of your request is located at the top of this screen.
Then along came ILLiad 8.5 and the ability to clone requests. We decided to leave the cloning functionality available to users and see what happened. Well, some students tried to renew their items and upon failing to notice the renewal request was successful submitted a “Clone” request in addition to their renewal. Some of our requests are automated using IDS Logic and we failed to catch some of these duplicate requests until the student came to pick up the item.
We still have valid reasons for keeping the cloning feature available, so I took a cue from Logan Rath at SUNY Brockport, and used jQuery to create a pop-up like alert message for some of the status lines (Thanks Logan for the awesome idea!).
Here’s what happens when someone clicks “Cancel Request”
The background is greyed out and a message appears that displays the status. When you click ok, the message goes away and the page’s original color returns.
Super awesome! Plus, it’s not really a pop-up, so it works great on mobile devices.
The jQuery code itself was wicked easy and there are plenty of examples online if you search jQuery and dialog (It’s called a dialog box). The trick for ILLiad was to add a div with an id field to the status line within ILLiad’s Customization Manager (Web Interface -> Status Lines). That way only some of the status lines behave like this and the others continue to appear like they always have.
Our library serves several remote field stations that have small unstaffed reading rooms and we occasionally get interlibrary loan requests from researchers at these sites. We generally choose to mail physical items to these users and wanted a way to differentiate and catch these unique requests so they aren’t cancelled or just placed on the hold shelf. Our current solution is to include a “Primary Location” on the user registration form that populates the user “Site” field in ILLiad. This involved several steps.
First, I added these values to the CustomDropDown menu in the Customization Manager (System -> General -> CustomDropDown).
The new user registration and change user information webpages were updated to include the following code:
<span class=”field”><span><b>Primary Location:</b></span></span>
<select id=”Site” name=”Site” size=”1″ class=”f-name” tabindex=”4″>
<#OPTION name=”custom” groupname=”Site” selectedValue=”<#PARAM name=Site>” defaultValue=”MC” defaultName=”Main Campus” />
Once the webpages are edited, the LabelName ultimately displays to users on user registration/information pages.
The LabelValue displays in the user information under “Site.”
Finally, I created a custom queue and a routing rule to send all requests not coming from users on the main campus to their own queue.
The new custom queue is:
QueueName = Remote Site ILL Requests
ProcessTye = Borrowing
NVTGC = ILL
The new routing rule is:
RuleNo = (Pick a number useful to you. It’s actually our last rule because we want the electronic requests to automatically go to the user.)RuleActive = Yes
ProcessType = Borrowing
TransactionStatus = Awaiting Request Processing
MatchString = (u.Site = ‘RS’ or u.Site=’AEC’ or u.Site=’OT’) = Essentially the LabelValues that you want to go into their own queue.
So far this solution has really helped the ILL staff easily identify the few requests that need to be mailed to the remote sites and process them accordingly.
As part of our campus delivery implementation, two ILLiad webpages (New User Registration and Change User Information) were updated to incorporate the new user information needed.
When users register for an ILL account, they are now given the option to opt into campus delivery as well as provide their delivery location.
New Options on User Account Pages
- The first field, “Would you like books and other physical items delivered to you?” corresponds with LoanDeliveryGroup in ILLiad. Choosing “Yes” selects “Mail to Address” on the backend while choosing “No” selects “Hold for Pickup.”
- The second field, “If yes, Enter your Main Campus Office / Mailbox Location” corresponds with the secondary address field in ILLiad.
- Another field (not shown in the image above) labeled “Primary Location” was added as a dropdown option higher up in the form to capture what campus / research station users were located at. This field corresponds with “Site” in ILLiad and the values were created in the Customization Manager.
- If you are interested in the html code:
<fieldset><h4>Campus Delivery – Faculty/Staff/Graduate Students</h4><label for=”LoanDeliveryGroup”><span class=”field”><span class=”<#ERROR name=”ERRORLoanDeliveryGroup”>”><b>Would you like books and other physical items delivered to you?* </b></span><br /><span class=”note”>* Limited to Main Campus Only</span></span> <input type=”radio” id=”DeliveryGroup” name=”LoanDeliveryGroup” size=”1″ class=”f-radio” value=”Mail to Address” > Yes <input type=”radio” id=”DeliveryGroup” name=”LoanDeliveryGroup” size=”1″ class=”f-radio” value=”Hold for Pickup” checked> No<br /></label><label for=”SAddress”><span class=”field”><span>If Yes, Enter your Main Campus Office / Mailbox Location</span></span><input id=”SAddress” name=”SAddress” type=”text” size=”40″ class=”f-name” value=”<#PARAM name=”SAddress”>”><br /> </label></fieldset>
As you may have noticed in the first image, the service is currently only available to faculty, staff, and graduate students who are located on our main campus. This meant that we needed to create status specific pages for users to update their user information. We created one for undergraduates and left out the campus delivery option. Then we created a page for all other statuses that included the same code found on the new user registration form except for one key difference: the default selection to opt into campus delivery is “Yes” instead of “No.” The reasoning behind this was varied. One, it might encourage users to use the service. Two, if users don’t change the option to “No” but don’t include a delivery location, we’ll catch the inconsistency when the pull slips are printed. Third, and most important, I couldn’t have this field populate with users previous preferences like the other fields do on the page. This inability to populate the information is related to our choice to display “Yes” or “No” to the users as radio buttons as opposed to ILLiad’s values “Mail to Address” and “Hold for Pickup” as drop down menus. Thus far, this minor detail has not been an issue.