[OPEN-ILS-GENERAL] Reading History opt in on patron application

[Diane Disbro]

Good morning –

 

I think Elaine’s recommendation is spot on. We should give patrons information about this function and leave it up to them to enable, by themselves or with our coaching. Accessing the patron’s side of her account sort of defeats the purpose of having a “patron’s side.”

 

Diane Disbro

Circulation Coordinator/Branch Manager

Union Branch

Scenic Regional Library

308 Hawthorne Drive

Union, MO     63084

636-583-3224

 <mailto:ddisbro at scenicregional.org> ddisbro at scenicregional.org

www.scenicregional.org

 

 

From: Open-ils-general [mailto:open-ils-general-bounces at list.georgialibraries.org] On Behalf Of Elaine Hardy
Sent: Thursday, October 19, 2017 7:54 AM
To: Evergreen Discussion Group
Subject: Re: [OPEN-ILS-GENERAL] Reading History opt in on patron application

 

​

​​

​From ALA's statement on privacy:

 

 

"In all areas of librarianship, best practice leaves the user in control of as many choices as possible. These include decisions about the selection of, access to, and use of information. Lack of privacy and confidentiality has a chilling effect on users’ choices. All users have a right to be free from any unreasonable intrusion into or surveillance of their lawful library use."  http://www.ala.org/advocacy/intfreedom/librarybill/interpretations/privacy

 

There may also be local and state laws that govern how a patron opts out of something that effects their privacy. 

 

Rather than creating a potential avenue that would compromise patron confidentiality, I think it more appropriate to train front line staff to inform patrons of this functionality and give them instructions on how to utilize it. If the patron then needs further assistance, it can be given.​




 

 

J. Elaine Hardy

PINES & Collaborative Projects Manager

Georgia Public Library Service/PINES

1800 Century Place, Ste. 150

Atlanta, GA 30045

404.235.7128 Office

404.548.4241 Cell

404.235.7201 FAX

 

On Wed, Oct 18, 2017 at 6:05 PM, Rogan Hamby <rhamby at equinoxinitiative.org> wrote:

There's a lot to think about here.  I do like the idea of the setting being on the patron registration page so that staff can turn it on and off for patrons as an assistance.  Actually, I think we should have had that for a long time now.  If you're doing this as a local hack how you do it is certainly up to you but if it's an actual change to Evergreen code the idea of tying it to a nightly cron job unnecessary.  There is a question about if older circs should get fed in but that might be tangential here and more about how the reading history works.  

 

I'm not fond of giving staff access to the history though.  Staff trusted with reporter permissions can do that anyway, to the extent that you haven't aged out circulations anyway.  It feels like an unnecessary threshold to cross or at least one that we shouldn't cross, on principle.  It does mean that patrons that want staff to see their reading history have to go to the step of giving it in some form to the staff but I feel like that's an acceptable price to pay for privacy.  But I know that some communities will probably see me as paranoid in that regard.  

 

If it was implemented I feel library options, patron toggling, protection for patron toggles, etc... would be needed.  It would be it's own viper nest of issues to sort through.  

 

 




 

Rogan Hamby

Data and Project Analyst 

Equinox Open Library Initiative

phone:  1-877-OPEN-ILS (673-6457)

email:  rogan at EquinoxInitiative.org

web:  http://EquinoxInitiative.org

 

On Wed, Oct 18, 2017 at 2:44 PM, Josh Stompro <stomproj at exchange.larl.org> wrote:

Hello, we are running into the fact that many of our patrons that want to make use of a reading history, don’t find out about it until long after they sign up for an account. Many of these patrons are also non computer/online catalog users, so there is no chance that they would ever find the option to enable it themselves, and even if they knew about it, they wouldn’t be able to set it themselves.  So they find out about it after talking with staff, and then get mad when they find out that it will only have their history starting at the point they sign up.  Since they don’t use computers, they need staff to walk them through (do it for them) logging into their account and finding the option, so it would be handy if staff could just do it for them.

 

We could set the library setting to default the checkout history to being enabled, but we really don’t want to make that decision for everyone, and then put the onus on them to figure out how to use the catalog to turn it off.

 

So we are considering adding an opt in checkbox to the patron application, along with a user setting that staff can check, to allow staff to enable the circ history at patron registration time.  The user setting being checked or unchecked would trigger a nightly process that would enable/disable the reading history for that account.

 

In theory, this could result in a customer saying that they never signed up for the feature, saying that staff did it on their own.  But since it is already trivially easy for staff to log into the catalog as a customer, it seems like that would already be a problem.  (staff know what the default pin numbers are based on, or could just change the pin, a customer that never uses the catalog would never know that the pin was changed)

 

Has anyone else done this or something like this?  Is this a horrible idea?

 

I think staff would also like to be able to access the patrons history from their staff stations, which would make readers advisory easier.  “Which Louis L’Amour titles haven’t I read yet”.

 

We have had problems in the past with patrons physically marking books that they have read before, to make it easier for them to find the ones they haven’t read.

 

Josh

 

Lake Agassiz Regional Library - Moorhead MN larl.org

Josh Stompro     | Office 218.233.3757 EXT-139 <tel:(218)%20233-3757> 

LARL IT Director | Cell 218.790.2110 <tel:(218)%20790-2110>   

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20171019/f75b4ac8/attachment.html>