In a nutshell: a mobile registration app for Evergreen (initially imagined for Android though an iOS version would be cool). The features list includes a password screen to protect the app, and the dual ability to edit accounts on the fly. To be clear this is not a project that SCLENDS or York County has decided to take up but I was asked to imagine what such an application could do. I’m trying to balance the original inspiration with robust functionality but I have to admit, once you go this far it’s tempting to add features like checkin or checkout though that might also be over reaching. I’m posting this purely in case anyone is interested. Ultimately this is a pretty simple app and has a lot of overlap with web based solutions that others have already done.
Use cases that drove these decisions: I manage circulation and outreach departments. With circulation we have frequent issues with lines backing up because patron registration takes a long time compared to normal checkouts. This is made worse by things like summer reading program hikes in activity. We could send people elsewhere to register but they still need a lot of assistance and the layout of our building is ... well, designed for a different age of the world. So, mobility is better but not crucial. However, mobility is all-important for outreach. My outreach staff go out to events like festivals, walk lines and the ability to deliver services like register patrons with a table and a mobile hotspot are extremely attractive. Finally, I can buy a decent Android tablet event with a pen and security devices substantially less than a desktop and usb tablet.
Requirement: We have to be able to store signatures. This is a hold up for many library boards and in fact would be nice in Evergreen itself (upon demand).
Proposal: To do this we add a column to the actor.usr table called signature. This would handle the storage of the actual signature. Alternatively we could work around and use the photograph field but that would interfere with anyone who uses that field for that function. We might be able to save either binary data of the image there or the array for a bitmap or a mathematical value of the signature curve. (This part of the idea was inspired by a lightning talk at the conference which nicely paralleled a lot of my own thinking.)
So, let’s break this down by workflow and screen:
When I run the app the screen I am greeted with will depend upon if this is the first time I have run the app. If it is, then the first screen I see upon initial load of the app is the password screen. The purpose of the password is to prevent patrons from accessing the settings screen when they are using the app and therefore potentially messing up any settings. Thereafter when the app is loaded it will go to the logon screen.
First time you load the app:
Logon Screen, this is the default you see after the first time, the Settings Password Screen:
[image not loading]
Settings Screen:
After logging in a registration screen is loaded. The settings can be accessed from there and other screens. There are actually two registration screens - one simple self-registration screen where staffs still have to intervene to finalize the record and a more full featured one meant for staff mobility.
Self-Registration Screen:
The self-registration screen is pretty straight forward but you will notice that it lacks a few critical things and makes some assumptions. Required fields should be marked by some kind of symbol or background filled in color, which is based on what is required in the database. Note that I’ve tried to make this reflect some core Evergreen conventions not be SCLENDS specific but I have moved away from the staff client registration screen in a few places where I think it makes more sense for this purpose.
● When the record goes into the actor.usr from here it will leave the password blank or make it the last four digits of their PIN number if you’ve set that option.
● Juvenile is calculated based on birthdate.
● Parent/Guardian should only be set by staff so it’s missing.
● Internet Access level should only be set by staff so it’s missing.
● Profile Permission group should only be set by staff so it’s missing but it will default based on settings.
● Privilege Expiration date should only be set by staff so it’s missing but it will be default based on settings.
● Barred and collections exempt default to null, not set.
● Active defaults to FALSE, so that they have to have staff activate their account.
● Claimed return, claimed never checked out, alert message are all null on self registration.
● Hold behind the circ desk defaults to null.
● Valid address and statistical categories are for staff interface only.
The planned workflow included that the patron would hit submit at the end of entering their information and a new screen would come up that would present the actor.usr id, entered name, phone number and email address. When the submit button was hit it inserted a new actor.usr record that was automatically marked as invalid and without a barcode. The password would be left blank. The staff member would use the name, id, phone number or email address to access the patron record that has now been inserted into the database. Based on library procedure they might go directly to the record via the user id or they might search based on name or email to find inclusion in a group or merging if it is a duplicate. Since it is a self-registration some options are restricted from the app user. The user name will be left blank until staff adds the barcode. At that same time the password can be added along with a corrected patron profile group.
Then the staff member marks the account valid and adds a barcode to give the patron their barcode. Using the options screen there is an option to set the machine to staff mode and there would be a barcode scanner to immediately attach a barcode and to override some default behaviors of the self-registration.
The staff registration screen is quite different and gives direct access to everything. It is also used when editing a record:
Staff Registration/Editing Screen:
---------------------------------------
;)