Patron Notices (UXPROD-18)

[UXPROD-723] Patron notice templates and editor Created: 25/May/18  Updated: 16/Sep/20  Resolved: 14/Sep/18

Status: Closed
Project: UX Product
Components: None
Affects versions: None
Fix versions: None
Parent: Patron Notices

Type: New Feature Priority: P3
Reporter: Darcy Branchini Assignee: Darcy Branchini
Resolution: Duplicate Votes: 0
Labels: notices, resourceaccess
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Blocks
is blocked by UXPROD-596 Emailer and Message Formatter Closed
Epic Link: Patron Notices
Analysis Estimate: Medium < 5 days
Analysis Estimator: Darcy Branchini
Front End Estimator: Michal Kuklis
Back End Estimate: XL < 15 days
Back End Estimator: Jakub Skoczen
Estimation Notes and Assumptions: BE: Assumes templating and emailing functionality is built specifically for this feature rather than provided through UXPROD-596
Development Team: Prokopovych
Rank: Chalmers (Impl Aut 2019): R1
Rank: Chicago (MVP Sum 2020): R1
Rank: Cornell (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R1
Rank: GBV (MVP Sum 2020): R1
Rank: Lehigh (MVP Summer 2020): R1
Rank: TAMU (MVP Jan 2021): R1
Rank: U of AL (MVP Oct 2020): R1

 Description   

Need the ability to define email, sms (text) and/or print templates depending on the institution/organization. For example, some organizations are required to send print notices for a fee/fine notice; whereas, some organizations have a no paper policy. For email, a subject, body (or multiple body parts) and signature are required. For sms, just a body of text is required. For print, they'll need to be able to include a patron name and address (for mailing) and body as well as signature.

It was suggested that contact information (and logo) being defined with location settings instead of in the notice itself. If it changes, then it is edited once, and it'll fix all notices.

Template requirements include:

  • Layout
  • Fonts, styles (perhaps somewhat limited though so accessibility regulations are considered)
  • Tokens or individual fields, such as patron name, fee/fine description and amount
  • Loop through multiple values, such as a list of all over items including multiple fields for each object (title and call number)
  • Conditional, such as if patron type equals faculty, then... or if patron type equals student, then...

Also, the idea of consolidating notices came up. The use case that came up is over items from multiple library locations. For some institutions, it's simple, one notice with all items overdue with one statement about fee/fine policies and/or contact information. For some, it's more complicated, they might each have their own policies and/or generated fees, so it look something like this:

Library 1
Statement about fee/fine policy and/or contact information
List of items

Library 2
Statement about fee/fine policy and/or contact information
List of items

...

Also see UXPROD-675 Closed for CRUD.

Not sure what templating language will be selected but some early ideas include Mustache. Mustache seems to be popular because of it's simplicity and it's ability to integrate with several languages as described by this comparison chart - (https://en.wikipedia.org/wiki/Comparison_of_web_template_engines). I'd suggest it's biggest drawback is that it won't handle the conditionals outlined above. It will do a simple if exists/not empty test, but that's it.

For what it's worth, a few developers at Cornell have researched the topic of rich-text editors combined with templating languages for an email notification system, and their solution eventually became a combination of Quill (https://quilljs.com/) because it stores the template as JSON (and got them out of some earlier trouble with tags and/or elements being stripped out) and Liquid Droplets (https://github.com/Shopify/liquid/wiki/Introduction-to-Drops) for field tokens and/or code snippets. Or at least I think I'm explaining that correctly! Here's a ticket that goes into some details about their research - https://github.com/cul-it/studentsite/issues/862#issuecomment-349994330.



 Comments   
Comment by Cate Boerema (Inactive) [ 27/Aug/18 ]

Hi Darcy Branchini. How do you see this distinguished from UXPROD-675 Closed ? They seem to have a lot of overlap (e.g. how can you CRUD a notice without an editor) so maybe we should combined. Also, the feature description above says "see UXPROD-723 Closed for logic", but this is UXPROD-723 Closed and the logic for when to send patron notices and to whom doesn't seem to be in scope.

Comment by Cate Boerema (Inactive) [ 06/Sep/18 ]

Darcy Branchini I see this is still targeted for the Q3 2018 release. Is there still a chance this will make it? Can you follow up with the devs to make sure they are working on it?

Comment by Darcy Branchini [ 06/Sep/18 ]

Cate Boerema I must have misunderstood you, or maybe I'm thinking back to my first staff slip story, but I remember a conversation where you suggested splitting the editor/template from the CRUD portion.

Comment by Cate Boerema (Inactive) [ 14/Sep/18 ]

Closing as a duplicate of UXPROD-675 Closed

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