New ASRS Request Workflow is Live
Just before the break, Mary M and I were planning on switching the workflow for users who request items from the ASRS. The old reasons for having different workflows no longer applied, and it was more important to us now to have a consistent experience for our users, regardless of where the item they needed was housed. Once we got back from the holiday break, we got to work on making the changes.
The old ASRS request screen
Except we couldn’t. It turns out that Sierra doesn’t actually let you route ASRS requests through an external login like LDAP. It will let you have your patrons log in using a barcode (like our Visitors and Alumni), but allowing the 99% of our users to log in with their GVSU IDs was actually impossible, something we hadn’t realized before, thanks to the super job the folks at III did on writing documentation. For some reason, III requires users to log in with real credentials when requesting an item in the stacks, which anyone could just walk up and get for themselves. But when asking for an item that is impossible to retrieve without the aid of a computer, they have no restrictions on what you can enter. It’s a questionable design choice, to say the least.
Mary and I tossed around a few ideas, and then we came up with one that works pretty well, I think: a placebo login. The whole goal was to solve the problem of users typing the wrong thing into the login screen, rather than to actually have them log in. So, we could just redesign the existing page to appear to be a login page. There would be a username field and a password field, and while users can still technically type whatever they want, users won’t know that and will be inclined to log in as they usually do. I designed the page to appear in two chunks, even simulating the login process. First you are presented with the login screen, which contains all of the same checks the real login screen does (looking for G#s, barcodes in the password field, etc.):
The new ASRS request screen, step 1: the placebo login
Once you click the log in button, the login screen is hidden and you are asked to choose your pickup location, just as if you were requesting an item from the stacks. This is technically the exact same page, but I made it appear to be a new page to give users the feeling that they were making progress on their task. I also show them the name that they entered in the username field of the login screen, to help give the illusion of a new page.
The new ASRS request screen, step 2: pickup location
Now, the user is given better clues about what to enter in the text box by simulating a login screen. Underneath, this is the exact same thing we’ve been doing for 8 years. We didn’t change any of the actual functionality, which was what we had hoped to do. Instead, we simulated that change and will be watching closely to see if users are better able to enter identifying information into the request screen.
A few caveats: if the user had really logged in, they wouldn’t have to log in again to make another request (or look at their account). Since we’re only pretending to log them in, they won’t actually be logged in. They’ll have to complete this every time they make a request. (When I submit the form, the password is ignored.) That said, if a logged in user makes an ASRS request, the page goes right to the pickup selection in step 2, bypassing the placebo login altogether.
I tried getting around this by setting the username and pickup location values in a cookie, and then checking for the cookie whenever this page appeared. It worked really well, until I actually tested it in Sierra. It turns out that Sierra uses the information it stores in the cookie in a rather unsophisticated way (you’re all shocked, I know) and so adding any additional information to the cookie broke the ability to place requests or search the catalog! I quickly removed my cookie code, but am working on other ways to simulate this, if the data shows that it is affecting enough users to be worth the time. (Modern browsers allow you to store data in the browser’s local storage, rather than in a cookie, for instance.) For now, we’ve got a new look to the ASRS request page that should cut down on the number of problematic “names” entered into the free-for-all text box.
As always, let me know if you have any questions!