Using Univ. ID instead of “Library ID” in sul-requests and My Account

[dbranchini]

Context

See SearchWorks - Library ID UX document for problem statement, additional information and more context.

Solution

• Replace field label and instructions on the following screens:

-- https://mylibrary.stanford.edu/login -- https://requests.stanford.edu/pages/new?item_id=3440309&origin=SAL3&origin_location=SAL3-STACKS - Select option - "I don't have a SUNet ID."

• New label: University ID

• New instructions: This is a 9-digit number that serves as a replacement for the Library ID that was previously utilized.

• Validate input (See @saseestone 's comment below.) Input for ID should validate that the user entered 9 digits. Message: "Please enter a valid Stanford University ID."

Notes

• It might be prudent to scan the code base for other screens that might reference Library ID. The screens referenced above are believed to be the only screens.
• UnivID is placed in the “external system ID” field in FOLIO. NOTE: Lane is going to start creating FOLIO user accounts for hospital users and this move to using “external system ID” may cause them some issues. We need to stay in close contact with them as we make this switch. (From Buckets of Work, Bullet 5)
• [x] TODO @saseestone Verify the number format with the University ID office. Will the number always be 9 digits? Are there other criteria that might help in validating the number input?

[saseestone]

We're 99% sure that 9-digits is correct. Let's move forward. If we get a response from ID card office that 9-digit isn't correct, we can change the validator accordingly.

[saseestone]

Reviewing numbers input in the FOLIO "External System ID", it appears that we have user records with 8, 9 and 10 digits.

• Core community users (who presumably would be accessing our applications using auth and NOT inputting an ID) have 8 digits in the FOLIO External System ID field
• Courtesy card holders (the primary user group that we're trying to help gain access in sul-requests & My Account) have either 9 or 10 digits in FOLIO External System ID field.

We could:

• Set the validator to allow all (8, 9, or 10 digits)
• Rethink using number validation

The purpose behind number validation from my POV was to:

• help legitimate users understand if they've input the wrong information (e.g. an email address instead of a number), and provide an on-screen error message so that they can correct the mistake.
• (in the case of having multiple numbers on the physical card - which we're moving away from) help legitimate users understand which number they should input and again, show an on-screen error message to encourage them to correct the error.
• Reduce the number of requests being created by bots putting junk in this field.

Chris may remember other reasons.

[saseestone]

@dbranchini I don't think this discrepancy in the number of digits changes anything in design or instructions for the user. The number printed on the card (and that they will be instructed to use by Library staff) will be the number stored in the FOLIO External System ID field.

[saseestone]

One more thought: I don't know why we're not just validating on the FOLIO field in real time, and then displaying an error if we can't find a match. I suspect we weren't doing that with Symphony because of performance issues, but it's just a guess (and vague memory)

[dbranchini]

You're right, @saseestone , the number of digits doesn't change the design or the label, instructions, and/or validation error messaging. If it's possible to validate against the FOLIO field in real-time, that sounds like a better solution to me.

[saseestone]

Noting here that we need to coordinate with Lane Library & the SUL Privileges office before this change is rolled to Production.

Lane needs to know because they are using our Requests code in Lane Search. Privileges needs to know because they need to update instructional webpages for users, staff workflows, and deploy a change in the card type they use to print SUL Library cards.

[dbranchini]

Post discussion with @saseestone I'm summarizing the path forward on this work. The stakeholders are not ready for this yet. @cbeer suggested that we leave the backend wired up to accept University ID and continue to accept Library ID (last 10 digits of the barcode). So @mjgiarlo or another developer will change the backend logic to handle accepting both. The UI will revert back to the Library ID label though because no one has the new ID cards yet. For both requests and my account, we should use the following language:

Field label: Library ID Field hint: The last 10 digits above the barcode on your Library ID card.

For requests, the hint will have the above text plus, "It's optional, but may help you track your request in My Library Account."