Library Answers: Los Rios Common Questions

We have a Report a problem button that appears in OneSearch. We implemented this button and accompanying form in 2020 when we went live with Alma/Primo. More recently Ex Libris has developed a report/feedback tool that is configured in Alma, but because our homegrown tool is more flexible, we are sticking with it for now.

Originally the focus of this button was on linking problems. In 2024 it was decided to expand the use of it to all records. The hope is that students and other users will use it when they encounter any problems that they prefer to send this way rather than via our chat service.

Where does the button appear?

• For records that include online availability, the button will appear
  • below any list of full-text links in a record's full display
  • on the brief results display—note in this case the button will only be visible on hover/focus.
• For records that include only physical holdings, the button will appear under the table of holdings.

What does the report include?

The user is required to send some sort of message. The form allows them to enter an email address if they would like a reply.

Additional information is provided automatically. Clicking the button opens a pop-up window that receives a number of query parameters, including:

• the current URL. Note this is not the same as the permalink; rather it is what appears in the browser's address bar
• the record ID of the record the user clicked from; note this data is very important when the user has clicked it from brief results, since in that case the URL will not tell you which record they were looking at
• the college abbreviation matching the Primo VE view the user is on
• a code indicating where the report should be sent

All of this info is included in the form submission so that it can eventually be displayed in an HTML table.

Where is the report sent?

• If the button is clicked from a record that has only physical holdings, the report will be sent to the LibAnswers queue of the college corresponding to the Primo VE view the user was on.
• If the button is clicked from a record that includes online holdings, the report will be sent to the Problem Reports LibAnswers queue, which is monitored by the ERM librarians.

How do we respond to the reports?

These reports are similar to other tickets we receive, such as via the Ask Us widget. But:

• be aware that many will not have a user's email address attached and will instead show a noreply email address. In these cases, do not use the Create a Reply tab
• records in OneSearch often involve books and other items from various libraries. Watch out for cases where the best thing is to ask others or even transfer the ticket
• if a student is registering a complaint about a particular item, be sure to address this appropriately with colleagues; do not simply close the ticket.

How is the Problem Reporter built?

The tool has three components:

• An AngularJS component
• PHP scripts that create and process the form
• LibAnswers queues that receive the form.

AngularJS Component

This strategy allows us to vary the appearance of the button and collect the URL and record ID. We have defined a custom directive, lr-problem-reporter. The template is then inserted in three different "-after" directives, and the controller determines whether or not the button appears according to various parameters. So it appears in Get It only if there are no electronic or digital services; in brief results only if there are electronic or digital services; and so on. Since the current URL and record ID are available to many of Primo's AngularJS directives, these can be passed to the PHP form as GET query parameters.

PHP scripts

One PHP script receives the query parameters and builds the form. Another receives the form submission, processes its POST values, builds an HTML table and sends it to the appropriate queue. These scripts are maintained in a private GitHub repository available to the Los Rios development team.

LibAnswers queues

Nothing really to say about these.

Issues / future development

We are currently sending the form data to the LibAnswers queue using the queue's email address using PHP Mail. LibAnswers will occasionally put these submissions in the spam queue. The HTML table occasionally creates some display weirdness. It would probably be better to send form submissions via the LibAnswers Create Ticket API.

Alternatively, the PHP form could be replaced by the built-in form belonging to the queue. JavaScript could be used to parse the query parameters. However, additional changes to the queue forms would likely be needed to accommodate this strategy and it might end up being a little odd.