O neal columbia

Electronic Resource Reminders in Google Calendar

Nada O’Neal, Systems Engineer nco2104@columbia.edu

Columbia University Libraries ENUG 10/28/2011

Specifics…

Specifics…

Columbia’s Problem

Some background: •  Columbia Libraries = big, federation of many libraries •  Electronic subscription resources = lots, expensive •  Assessment of subscription e-resources is hard

The problem: •  Assessment of electronic subscription resources was great in some libraries, less

great in others •  There wasn’t much guidance for assessors who wanted it •  Data is available for assessors, but they must proactively get it themselves The solution: •  Some push technology that enforced a 5- and 3-month pre-renewal assessment

schedule.

Wait. Why push?

Push (instead of “pull”) means the data goes to the people, instead of people needing to go to the data. Fantastic! Email, pop-ups, etc, are examples of push technology. Oh. Note that push technology can backfire because it can be very annoying, in which case people will block/ignore it. It works best when it fits into existing workflow, and when users get exactly what they want.

Columbia’s Pick

•  The Libraries had just completed a transition to Google Calendar.

•  Available to all staff •  Staff were already using heavily to manage schedules

•  This made ninja-push possible •  Staff had been recently trained •  IT Staff were (somewhat) experienced with the API •  Cheap! (free)

gCal Caveats

•  Reminders at most 4 weeks in advance •  The http API is slow •  The API is limited •  http requests can be interrupted •  Google is “in the cloud”, man •  Data privacy! Understand: Columbia is using “Google Apps for your Domain”, Education edition, which is different from a consumer Google account, especially in terms of privacy. Is gCal the best choice for you? Maybe.

!

Our App in GCal

•  Each fund code is its own calendar •  These are secondary calendars under the “_backup”

service account, so they must be added to the global address book

•  Any Columbia Libraries staff can view any fund calendar •  A user begins typing “Fund Code …” and the calendar pops

up •  A user can subscribe themselves to receive email or pop-up

reminders for a code/calendar or a resource/event •  Assessment working group members receive a monthly

emailed report on who is subscribing to what

Expenditure = 3 events

•  Each fund may have hundreds of expenditures! •  Each expenditure is entered once, on the day it happened •  5-month and 3-month renewal reminders (for non-negative expenditures) •  (There is no expiration event.) Sample calendar event: On 10/27/2011: Title: renew Asian philosophy $XXX by 01/26/2012 Event data: (three months reminder) 2035E 1AEM2727 20110126 Asian philosophy.

1 Abingdon, Oxfordshire : enk expenditure $XXX 9123215 ags1 EBS29 USD $XXX CUL 11 EBSCO [1: 20(01/11)-21(12/11) - PRINT + ONLINE] [Start Date:

2011-01-01] [End Date: 2011-12-31]

Finding A Fund…

Viewing Funds…

Email/Popup Reminders…

On fund… On event…

Subscriber Report…

Subject: Fundcode Calendar Subscribers (30 total) From: nco2104@columbia.edu Here's the latest list of people subscribed to at least one fund calendar. This is an automated message. 1. Xxxxx Xxxxxx (2038E, 4317E) 2. Xxxxx Xxxxxx (2235E, 2235EO, 2242E, 2248E, 2248EO, 2464E) 3. Xxxxxx Xxxxxx (2011E, 2029EO, 2462E, 2462EO, 2464E, 2465E, 2564E) 4. Xxxxxx Xxxxxx (2040E, 2462E, 2462EO, 2463E, 2465E, 6255E) 5. […]

Data into Google

•  Choice of python somewhat arbitrary: Google has good, well-supported APIs for: •  python •  .NET •  Java

•  And other APIs for: •  php •  javascript •  ruby

•  See http://code.google.com/apis/calendar/

Data from Voyager

•  I opted to keep the current perl scripts that were producing “Excel” reports from Voyager’s Oracle backend, and to extract the data from those.

$sql = "SELECT DISTINCT FUND_TRANSACTION.TRANS_TYPE, FUND_TRANSACTION.AMOUNT, TO_CHAR(FUND_TRANSACTION.TRANS_DATE,'yyyymmdd'), FUND_TRANSACTION.TRANS_DATE, FUND_TRANSACTION.OPERATOR_ID, FUND_TRANSACTION.REFERENCE_NO,FUND_TRANSACTION.NOTE, FUND.INSTITUTION_FUND_ID, FUND.FUND_NAME, FUND.FUND_CODE, FUND.FUND_ID, FUND.EXPENDITURES, LEDGER.LEDGER_NAME FROM $database.FUND_TRANSACTION, $database.FUND ,$database.LEDGER WHERE FUND.FUND_CODE = '$fundcode' AND FUND.FUND_ID = FUND_TRANSACTION.FUND_ID AND ( FUND.LEDGER_ID = '29' OR FUND.LEDGER_ID = '30') AND FUND.LEDGER_ID = FUND_TRANSACTION.LEDGER_ID AND FUND_TRANSACTION.LEDGER_ID = LEDGER.LEDGER_ID ORDER BY FUND.FUND_CODE,TO_CHAR(FUND_TRANSACTION.TRANS_DATE,'yyyymmddhhmiss')";

Why not?

•  customer service, support, history •  http API verses monolithic DB-to-xls dump

Script Structure

•  Find all current Fund Codes •  Create any new Fund Code calendars •  Add any new calendars to global address book •  Take new list of fund code calendars •  For each calendar,

•  download list of this fiscal year’s events •  compare to current cumulative file of transactions •  add any missing events and any missing reminders

… everything but the first item is an API call. The script is designed to expect to fail, and to be able to be run over and over.

Helper Scripts

•  For the times your script has made bad entries/duplicates: •  Address book cleaner •  Something to delete calendars matching criteria

•  For when the business logic changes: •  Something to empty calendars or selectively empty

calendars •  Something to list users subscribed to calendars

Other Resources

•  Email me at nco2104@columbia.edu!

Google Calendar as manual reminder app: •  http://www.libraryinnovation.org/article/view/23 Google APIs: http://code.google.com/apis/ Columbia’s renewal reminder application: •  See poster about renewal app at http://hdl.handle.net/

10022/AC:P:9978 (includes link to code) •  Article will be available in JERL Volume 24, Issue 2