Minutes for 10/11/2016
ASC Meeting: 11 October 2016
Agenda:
1) Discuss ShoutBomb testing thus far
Many have signed up and tested ShoutBomb since the previous meeting. Thoughts?
- Amy (CMC Quigley) – CMC is generally favorable. The texts actually have titles provided, you can renew directly from phone, and – of course – the price is better.
- Nina (Bud Werner) – Generally favorable, but they have a few questions/concerns.
- One patron got a sad face emoji (while another didn’t) for not being able to renew and thought that this wasn’t necessary.
- Can we adjust the timing of when notices go out, especially for hold pickup notices? The texts go out as soon as item is checked in, but the item isn’t always ready to be picked up – might take several hours to be put on hold shelf. Is there a way to delay these texts or have specific message: “Item will be ready after 5pm” etc.
- This currently works with 3 separate servers at the Marmot office. They run SQL queries which pull out renew, hold pickup, and overdue. They are set on an auto-job. Renew/overdue runs once in the morning (circa 4am); hold pickup runs every hour at the top of the hour. ShoutBomb doesn’t currently have a way to differentiate between times; it only looks for status change. Timing depends on when item comes in for when the job is sent.
- Jimmy & Brandon have discussed, with ShoutBomb’s agility, whether they could possibly use APIs to determine automatically when statuses change as opposed to a set job with a certain text. This would allow more freedom. Another option may be to split out certain libraries in the script job, so one library could send them out on a different time frame.
- Any possibility of not having a standard notice? Can it be changed per library?
- Currently they all have to be the same message. Marmot is not sure what ShoutBomb’s abilities are with this. Could they look for patron home library?
- Jimmy noted that the problem is still that something could have come available a minute before the list is run. This is a valid concern at this time: shelving delay. Need to check with George @ ShoutBomb.
- What is needed is to figure out an average time to hold shelf across consortium. We could then have the text message say that there would be an average delay for all libraries/patrons. Average times to hold shelf: Amanda (Salida) – 1 hr., Amy (CMC) – instantaneous, Becky (CMU) – soon, Karen (CCU) – 15 min., Diane (EVLD) – ½ hr., MCPLD – approx. 1 hr., Nina (Bud) – 2-3 hrs., Liz (Vail) – quick, easy to grab, Amenza – within an hr.
- Other issues:
- Jimmy came up with renew not working.
- Brandon is monitoring this now and it seems to be fixed. Jimmy’s tests were Prospector items though.
- There is no appearance of these working differently from Marmot items.
- Originally it was looking for a certain number of days overdue, not a range of dates, and may have missed them this way.
- Fort Lewis – Question about Library Card number with signup; what is it pointing to in Sierra? Just the barcode field, so if there are more than one barcode, either should work.
- Karen (CCU) has several patrons for whom the iii SMS fails. These patrons can be tested now via ShoutBomb to make sure that the messages will work. This is a good time to test any patrons experiencing problems.
- Be aware that the patron’s phone must be able to send texts to an email address (arrive as SMS from an email). This may cause conflict for people using older phones, but most smart phones are able to do this.
- Sign-up Methods:
- If you have a load of patrons to signup, ShoutBomb can also do a batch signup instead of people doing it individually from their phones. So perhaps students could opt in at the beginning of the semester. (But not really feasible.) Marmot would also put it on Pika like the iii SMS.
- So, patrons could still signup on Pika, signup via phone, or perhaps do a ShoutBomb batch. The second is “way cool,” to quote Jimmy.
- Maybe do batch load of those already using SMS.
- If you have a load of patrons to signup, ShoutBomb can also do a batch signup instead of people doing it individually from their phones. So perhaps students could opt in at the beginning of the semester. (But not really feasible.) Marmot would also put it on Pika like the iii SMS.
- Good to know:
- There is a new FERPA agreement, which will require ShoutBomb and Marmot to list how they will protect patron identity and privacy.
- The most difficult part of this new legislature is what Marmot would need to do if there were a breach.
- The ShoutBomb process ends up with some information being housed at both the Marmot server and the ShoutBomb server. This is a complication to be aware of.
- Marmot did sign non-disclosure agreements with ShoutBomb before this test even began. This augments our Patron Privacy policies.
- Jimmy – Does anybody object to switching from current iii SMS to ShoutBomb? The evidence it that this is better, faster, and cheaper.
- No objections for the ASC, as long as current users can be seamlessly switched.
- Next step:
- Brandon will work on an implementation plan.
- We have iii SMS through Feb., but Jimmy needs to let iii know by December.
- Marmot will do a widespread webinar (All Points?) for everyone.
- The next ASC meeting will be the town hall for the ShoutBomb kickoff, including: an overview, quick demo, calendar of rollout dates, etc.
- Optimal start time? Pitkin – off season, not at beginning of semesters, before beginning of spring semester, not during the holidays, beginning of December.
- We can pull out the patrons already using SMS individually per site and send ShoutBomb separate batches and have everyone work on a signup when convenient.
- With batch loads, we’d need to let patrons know that there would be a difference in where this is coming from (the email address), etc.
- We would want to see if the Pika signup info can be turned off for certain sites. Karen (CCU) says that this is possible. But there will need to be a date for when Pika will stop “talking” to SMS and start interacting with ShoutBomb.
- Broadcast notices – Could we use this to let patrons know about this switch? “Watch for changes” etc. This could potentially include library specific information in this. Maybe do one or two from ShoutBomb, but not have these patrons be permanently signed up.
Meeting Date:
Tuesday, 2016, October 11
Documentation Type:
Meeting Minutes
Upload File:
Committees:
Access Services Committee