Wishlist: button to email receipts from circ workstation

[Christine Burns]

Evergreen 2.6.0

Currently - it is possible to email circulation receipts from the staff client, but there is no option - if there is an email in the account and the trigger set up for the checkout library, patrons will receive emails.

We would like to add a button which when pressed would trigger the email action - this would make the setting optional, and only patrons who requested an email circulation receipt would receive one.

We believe this would require a low to medium amount of development work to add the button in the staff client and adjust the action trigger.

[Galen Charlton (gmc)]

Equinox is taking this on as a commissioned development project funded by the Pioneer Library System. The specifications we're using can be found here:

http://yeti.esilibrary.com/dev/public/techspecs/email-receipts.html

"For the purpose of allowing patrons and staff greater flexibility in the delivery of checkout receipts, Equinox proposes to implement a method which will allow for patrons to control and “opt-in” to an email checkout receipt from both staff mediated checkouts at the circulation desk as well as the Evergreen self-check station. This development will include the following:

  * Creation of a new API with a mechanism to group checkouts into sessions
  * Configuration of the email receipts via A/T templates as with other email templates
  * UI addition in patron account settings to support the flag to "opt in" to email check out receipts (and to ensure an email address is on file)
  * UI addition to the check out screen in the staff client to include a visibility flag to indicate if the patron has opted in for email receipts

Inclusion of an "email receipt" option to the native Evergreen self-check interface that will work if the patron has an email address on file"

[Josh Stompro (u-launchpad-stompro-org)]

Hello, it looks like this enhancement will add two extra steps to logging out of the self check.

Currently you press either the logout or logout no receipt button.

I think the proposed process would involve pressing the logout button, then selecting a type of receipt delivery, then pressing submit/print.

I'm concerned this will result in users walking away while the receipt selection screen is on the screen. How will timing out the receipt selection screen be handled? It should probably also not be possible to exit out of the receipt selection in such a way that you are back in the users session, to prevent someone from gaining access to their account after someone walks away.

Would it be possible to have the option to remember the users choice for receipt delivery method so they don't need to choose it in the future? This would also require a way to remove the selection if the customer wants to change it.

Also, please keep in mind touch screens when designing the UI elements. Instead of radio buttons, just show a large button for each choice. Pressing the button performs the action, vs selecting a radiobutton and then selecting submit/print.

Thanks
Josh

[Josh Stompro (u-launchpad-stompro-org)]

One other thought, if there was a method to have an automatic choice of receipt delivery methods, it would be nice to throw up a status message for choices that don't print out a receipt. So the customer isn't left guessing what happened. "Sending receipt to email" "Not printing/sending receipt"

Josh

[Mike Rylander (mrylander)]

Josh,

To clarify, no extra steps are added.

There will be a set of radio buttons adjacent to the logout button for the desired receipt type: print, email, and none. If the user has chosen email receipts via the opt-in setting, that will be selected by default. If they have not chosen email receipts, print will be selected. If they do not want a receipt, they'll select none. When they press the logout button, it just does what they've chosen and they are logged out. (Note: just like today, if there are no checkouts for the session, no receipt of any kind is generated.)

As for touch screens, we'd happily accept suggestions for CSS to improve the UI (google says there are several, such as http://uxmovement.com/forms/ways-to-make-checkboxes-radio-buttons-easier-to-click/), We're going to use <label>s to make the click area larger, for instance. Adding more buttons (which amounts to more choices for the user to make, even though they've told us their desired default) that do the same thing with more/different side effects seems like suboptimal UI design.

Thanks for looking at the spec!

[Galen Charlton (gmc)]

The working branch user/gmcharlt/lp1356477_messy contains the code currently being tested by our customer. As the branch name implies, this ain't neat; when it comes time for a pullrequest, we'll rebase and clean up.

[Galen Charlton (gmc)]

A clean series of patches is now available in the user/gmcharlt/lp1356477_email_cko_receipts branch in the working repository:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/gmcharlt/lp1356477_email_cko_receipts

[Bob Wicksall (bwicksall)]

We have tested this feature and consent to signing off on the patches.

Bob Wicksall
<email address hidden>

[Mike Rylander (mrylander)]

Merged to master. Thanks, Galen and Bob!