Users App (UXPROD-784)

[UXPROD-3988] LC Reader Registration Data Flow Created: 25/Jan/23  Updated: 31/Jan/24

Status: Draft
Project: UX Product
Components: None
Affects versions: None
Fix versions: Sunflower (R3 2024)
Parent: Users App

Type: New Feature Priority: P2
Reporter: Khalilah Gambrell Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: LC-priority2, SolutionArchitecture, loc, patronreg, usermanagement
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: Microsoft Word Reader Registration App. (draft mock-up) 3-2023.docx     PNG File Reader Registration App. Contact Info (draft) - 3-2023 (1).png     PNG File Reader Registration App. Custom Fields (draft) - 3-2023.png     PNG File Reader Registration App. Header (draft) - 3-2023 (1).png     PNG File Reader Registration App. User Information (draft) 3-2023 (1).png    
Issue links:
Defines
defines UXPROD-4663 LC User Registration record in User app Open
Relates
relates to MODUSERS-416 Spike: Investigate hardware / softwar... Blocked
relates to UXPROD-4070 Reading Room Access Open
relates to UXPROD-4492 Users - LC integrations Blocked
Epic Link: Users App
Front End Estimate: XXXL: 30-45 days
Front End Estimator: Cate Boerema (Inactive)
Front-End Confidence factor: 10%
Back End Estimate: XXXL: 30-45 days
Back End Estimator: Cate Boerema (Inactive)
Development Team: Volaris
PO Rank: 0
Rank: Cornell (Full Sum 2021): R3

 Description   

Context: Library of Congress needs to ensure patron registration data flows to FOLIO from a web-based patron registration form into the Users app. to create new User records for some patrons. These Users will be considered distance patrons and will have no or limited circulation privileges. When these patrons come onsite, their patron group may change, enabling access to circulation privileges, Reading Rooms, and physical card issuing that features a profile picture.

Current situation or problem: For the general public, getting a library account starts with "reader registration".  The first step is filling out this online form: current form - https://reader-registration.loc.gov/readerreg/remote/. FOLIO needs to collect the data from this form or a future similar form and create limited User records for new patrons. Too, many people (from researchers to tourists) want a physical Library of Congress library card.  A card is not required to visit the Library, but it is needed to enter the public reading rooms and is a souvenir. FOLIO needs to be able to ensure secure data flow of patron information to LC software and hardware that manages physical library card printing.

In scope:
*Repository for storing reader registrations, likely Users App.
*Ensure LC staff permissions meet workflows (e.g., LC staff working with these User records have only limited access to some User record information)
*Ability to transmit data to LC printing software and hardware (purchasing of new equipment pending (ETA up to early 2025), and LC prefers to implement feature work related to card printing after new equipment and software is in place.)
*Ensure data flow from web registration form
*Ensure coordination with patron discovery

Use case(s):
**When patron arrives at library, find their library account record (search, filter, view results, sort)
**Important to be able to search by multiple criteria at once to ensure correct patron record is addressed
**Check if any have been banned (in current, internal ReaderManager, "deactivated" is the status used for banned)
**Staff should be able to indicate via note if User is banned
**Check if there are multiples that need to be consolidated (sometimes people create new registration record when they lose a card)
**Process registration record and create a physical library card (new physical card equipment and software purchase pending)
**Collect photo
**Collect ID data (may will no longer be collecting the ID number - only the type and issuing location)

    • Issue card (NOTE: can be up to 350 cards issued per day (between 8am and 8pm))
      ***Assign barcode that is printed on the card - These currently aren't pre-printed on the card so need auto-generator
      ***Set other statuses - e.g., change patron group and add / edit access to Reading Rooms
      ***View action log (create card, modify reader data, add photo, add signature)
  • Other?

Solution should also -

**Renew library cards
**Coordinate to reprint lost library cards

Proposed solution/stories:
*Patron registration data flows to FOLIO from a web-based patron registration form into the Users app. to create new User records for patrons
*These Users will be considered distance patrons and will have no to limited circulation privileges
*When these patrons come onsite, their patron group may change, enabling access to circulation privileges, Reading Rooms, and physical card issuing that features a profile picture.

Links to additional info:

Questions:

Additional Notes:

 

 

**Original context, situation, and proposed solution below- **
Context: Library of Congress need this feature but it will likely be useful for other libraries (especially public and national).  The solution should be designed in such a way that it would be useful to any library with this need

Current situation or problem:  Many people (from researchers to tourists) want a Library of Congress library card.  A card is not required to visit the library, but it is needed to enter the public reading rooms and makes a great souvenir!  For the general public, getting a library card starts with "reader registration".  The first step is filling out this online form: https://reader-registration.loc.gov/readerreg/remote/ FOLIO needs to collect and store these pre-registration forms so they can be processed when the applicant arrives at the library to get their photos taken and receive their card.  

In scope

  • Respository for storing reader registrations.  Current thinking is that this would be a new Reader Registration app.  Why not load directly into Users app with a separate status?
    • Many of those who apply for a card never show up to get their card and become library patrons
    • Library staff who work with reader registration records should not have access to all user records.  Since FOLIO doesn't currently have record-based permissioning in Users app, this suggests a separate app makes more sense. NOTE: This may be an artifact of current systems rather than a hard requirement.
    • We don't want to bloat the Users app with a bunch of new features to support a workflow only some libraries need.  
  • Ability to convert reader registration records into FOLIO patron (User) records
  • Edge-API for connecting with patron interface

Out of scope

  • Patron interface for registration (may be a custom built form on website or built into discovery)
  • Library card formatting

Use case(s)

  • When patron arrives at library, find their registration record (search, filter, view results, sort)
    • Important to be able to search by multiple criteria at once
  • Confirm whether there are multiple records and what to do with them/which to use
    • Check if any have been banned (in ReaderManager, "deactivated" is the status used for banned - they should be taking notes to indicate banned as well)
    • Check if there are multiples that need to be consolidated (sometimes people create new pre-reg record when they lose a card)
  • Process registration record and create library card
    • Collect photo
    • Collect ID data (may will no longer be collecting the ID number - only the type and issueing location)
    • Collect signature (going away)
    • Issue card (NOTE: can be up to 350 cards issued per day (between 8am and 8pm))
      • Create a user record from pre-reg record
      • Assign barcode that is printed on the card - These aren't pre-printed on the card so need auto-generator
  • Set other statuses
  • Delete old reader registrations?  LC doesn't currently do this but, going forward, we could have a time limit after conversion to user records after which the pre-reg record could be deleted.
  • Create user records based on pre-registrations (should have a setting for which patron group will be used)
  • Renewing library cards
  • Lost library cards
  • View action log (create card, modify reader data, add photo, add signature)
  • Other?

Edge cases 

  • Staffer already has User account but wants to get a library card with their parents
    • This suggests that creating a user record from a reader registration record should be optional
    • In this case, perhaps the user record is manually linked to the reader registration record?
  • LC doesn't currently print library cards for staff (they use their staff ID which don't have barcodes) but they might someday want to change that and print library cards for staff (with or without barcodes)
    • This suggests that it should be possible to print a library card from the User record as well as the Reader Reg record
  • View history of every time an account was looked up.  Examples of when accounts are looked up include:
    • At reading room
    • If staff calls Sara to see if someone was banned
    • Lookup of record as part of a demonstration. 
    • Sara hasn't needed to consult this log in her time at the library...  Ann has also never been asked to report on this. This is supported in Reader Manager but doesn't seem like it's  heavily used/needed by LC. 
    • Law enforcement has asked Sara if somehone has visited a reading room but these logs don't provide that.  FOLIO may be able to support that, but it seems out of scope for this feature and potentially in scope for https://folio-org.atlassian.net/browse/UXPROD-4070 

Proposed solution/stories

  • To keep the solution generic and simplify conversion to User records, the reader registration record in FOLIO should largely replicate the Users record minus any fields that aren't needed for RR.  The patron interface, on the other hand, could potentially be customized to provide the experience LC wants for their patrons:
    • To require that certain fields be populated (LC requires name, email, phone and address to be populated while FOLIO backend only requires name and email (plus patron group))
    • To have basic validation of fields that are prone to error such as email (FOLIO itself doesn't do this kind of validation)
  • It's unclear at this point if different institutions will need to collect different data elements in RR.  To handle this, some configurability may be needed in FOLIO or the patron UI.
  • Additional data elements that need to be collected in the reader registration app that aren't in Users could they be handled as custom fields.  For example, the existing LC form includes an acknowledgement plus some opt-ins for marketing emails, for example.  There is also a place to record the Identification type, jurisdiction and number.  Current thinking is that custom fields should work for this, but anything in RR that isn't in Users will be left behind when user record is created. Still needs thought:
    • LC says they definitely need to make one of the email opt-ins functional for patron notices in FOLIO.  We'll need to figure that out (out of scope for this feature).
    • LC currently collects signatures for library cards but they may be phasing them out.  If they do need to continue to collect them, we might need to extend custom fields to support image uploads.
  • When a patron receives library card, the RR record will be copied to create the User record.  The records will exist in both app's storage, but they could be subsequently deleted from either/both.  They will not remain in sync.
  • Patron photos should exist in both RR and Users because they are needed for the creation of library cards (likely driven off RR data) and for display in FOLIO (e.g. when patron arrives (to check in?) at a reading room).  This feature is old, but should be extended to indicate what is needed: UXPROD-36 

Links to additional info

Questions

  • Is there a use case for having an RR record and a Users record at the same time?  Current design thinking is that they will coexist but curious if there's a use case for it.
  • Do we need to auto-generate barcodes? 
  • The Library of Congress currently maintains their reading room access data in the Reader registration system.  It seems like this should move out of the RR record in FOLIO (as those records may be short-lived) and should be tracked as an add-on to the User record for institutions who need it.  Need to talk through the workflow to see if this would work (e.g. when is the initial reading room access determined?  Has the user record been created by that point?)
  • Where does library card formatting and printing functionality live?  Currently seems to be hard coded into the ReaderManager app.  Need to better understand the options.  Out of scope for this feature.
  • What statuses should there be for the reader registration records (should they be configurable)?
  • What is "reader lookup log" in LC's custom app?  We think this is a history of when and who viewed the record.  Need to ask SMEs how important this is.

Additional Notes:

*If we can just clone the Users app code for a lot of this, we might be able to save on some effort here. But even still, there are a lot of unknowns and this is an entirely new app.



 Comments   
Comment by Thomas Trutt [ 08/Feb/23 ]

Reading this over I find the idea very interesting and it may be useful for university libraries like Cornell that offer resident and library cards.

I wonder though if a new module is needed or if this could be done using the current users module. There was plans to store patron images in the User record, which could be brought back and extended to allow for 'supporting documents'. An edge API could be added but you can also use the current user APIs to push a record to FOLIO. Finally you could add a new 'Status', something like 'Pending' or 'Not Approved'.

As for additional field the user's app already has the capability of custom fields that could be used. There is a ticket open for user templates that woudl probably help here as well.  

Doing it this way would change the workflow to searching for the user in the the Users app, updating any fields required and flipping the status to 'Active'.  

Generated at Fri Feb 09 00:36:23 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.