KPAC - "Get It!" page does not show item status

Bug #1623134 reported by Sam Link on 2016-09-13
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Evergreen
Wishlist
Unassigned

Bug Description

Evergreen Version: 2.9.x

In the KPAC, the search results display a prominent "Get It!" link, which takes the patron to a hold request page. This should also display the item status and shelving location prominently - we have had several patrons who placed holds and waited on books they could have picked up immediately from the shelf due to confusion caused by this. "Get It!" indicates that it is going to provide all information on how to get the item, whether that is via hold request or off the shelf.

To reproduce:

* Open a KPAC instance (example, http://gapines.org/eg/kpac)
* Search for any keyword
* Click on the prominent "Get It!" link
* Note the lack of item status/call number in the information provided

Sam Link (slink-g) on 2016-09-13
tags: added: kpac
Jim Keenan (jkeenan) on 2016-09-15
Changed in evergreen:
assignee: nobody → Jim Keenan (jkeenan)
Terran McCanna (tmccanna) wrote :

I think the button wording is the main problem. The behavior is the same as it is in the regular OPAC (when you click on the title it shows you the details, when you click on the Place Hold link it takes you to the hold form), but the "Get It" wording doesn't indicate that it's really just taking you to the place hold screen.

Jim Keenan (jkeenan) wrote :

I agree about the wording. It's not clear, especially if the catalog is aimed at younger patrons. I was thinking this bug could be addressed with two things: a change of wording and the addition to the display to show available local holdings to people doing a scoped search. (The way we've implemented this is C/W MARS is by making scoped-locally--by-default KPAC searches available to libraries who wanted to use the KPAC.)

Terran McCanna (tmccanna) wrote :

+1 Making both changes together would be great.

+1, the combined changes would make a huge difference.

Sam Link
Systems Librarian
Greater Clarks Hill Regional Library
<email address hidden>
<email address hidden>
706-447-6702

On Thu, Sep 15, 2016 at 10:17 AM, Terran McCanna <
<email address hidden>> wrote:

> +1 Making both changes together would be great.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1623134
>
> Title:
> KPAC - "Get It!" page does not show item status
>
> Status in Evergreen:
> New
>
> Bug description:
> Evergreen Version: 2.9.x
>
> In the KPAC, the search results display a prominent "Get It!" link,
> which takes the patron to a hold request page. This should also
> display the item status and shelving location prominently - we have
> had several patrons who placed holds and waited on books they could
> have picked up immediately from the shelf due to confusion caused by
> this. "Get It!" indicates that it is going to provide all information
> on how to get the item, whether that is via hold request or off the
> shelf.
>
> To reproduce:
>
> * Open a KPAC instance (example, http://gapines.org/eg/kpac)
> * Search for any keyword
> * Click on the prominent "Get It!" link
> * Note the lack of item status/call number in the information provided
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/1623134/+subscriptions
>

Jim Keenan (jkeenan) wrote :

I pushed a branch with a change so that location data shows for the item.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=a7a76853b70e343346ae42714607dddf877d2e36

Here's what it looks like in a KPAC search for "peter pan" on our training server.

https://training.cwmars.org/eg/kpac/getit/1897644?query=peter%20pan;qtype=keyword

You can do multiple searches in the KPAC on our training server, if you like, to see how it's working: https://training.cwmars.org/eg/kpac/home (I have, just for testing.)

I did not change the "Get it!" wording. I thought it might be okay to leave it (it seemed to make sense in the context now in a way it didn't before) but changing it to something else is not a big problem.

There is a provision in the code for showing added content under the location data. I see in addedcontent.tt2, though, there's a caveat about enabling this and its potential unhappy effect on the display. (How is it that in fixing one issue we always uncover others?)

If interested people would like to test out this code change and see how it goes in your environment.

Jim Keenan (jkeenan) on 2016-09-29
Changed in evergreen:
status: New → In Progress
Kathy Lussier (klussier) on 2016-09-29
Changed in evergreen:
assignee: Jim Keenan (jkeenan) → nobody
status: In Progress → Confirmed
tags: added: pullrequest
Terran McCanna (tmccanna) wrote :

Looks good, Jim!

I have tested this code and consent to signing off on it with my name, Terran McCanna, and my email address, <email address hidden>.

Changed in evergreen:
assignee: nobody → Terran McCanna (tmccanna)
tags: added: signedoff
removed: pullrequest
tags: added: pullrequest
Changed in evergreen:
assignee: Terran McCanna (tmccanna) → nobody
Kathy Lussier (klussier) wrote :

This feels like a new feature to me, so I'm going to mark it as a Wishlist and assign targets accordingly. Jim, as a new feature, this branch will need release notes. We have some guidelines for writing release notes at https://wiki.evergreen-ils.org/doku.php?id=contributing:release_notes. Feel free to let me know if you need any guidance in writing one up.

Thanks Jim and Terran!

Changed in evergreen:
importance: Undecided → Wishlist
milestone: none → 2.next
Kathy Lussier (klussier) wrote :

Adding a new link to the branch; the commit referenced above appears to be gone.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jkeenan/LP1623134-getit-page-does-not-show-item-status

Jim, can you add release notes to this branch?

Changed in evergreen:
milestone: 2.next → 2.12-beta
tags: added: needsreleasenote
Kathy Lussier (klussier) wrote :

Hi Jim and Terran,

This looks good. I just had one question. Jim said above "addition to the display to show available local holdings to people doing a scoped search." However, this display also appears when users are searching the entire consortium. The list can then get a bit long, but is limited to 10 copies when it first loads.

Assuming that there may be Evergreen sites out there that do not automatically scope the search to a library, do you think it's okay to have a list that long, requiring users to scroll further to get to the button where they can place a hold?

In my environment, the entry boxes for placing the hold had fallen "below the fold."

Terran McCanna (tmccanna) wrote :

Good point, Kathy. We have some titles that have 200+ titles across the consortium, so that wouldn't work for us. I'd prefer it only showed the list if it were scoped to a branch.

Changed in evergreen:
milestone: 2.12-beta → 2.next
Kathy Lussier (klussier) wrote :

Removing the pullrequest from this bug and adding a needsrepatch for now while we work on getting release notes and also better handling of situations where there are so many copies on this screen that the hold options get pushed below the fold.

tags: added: needsrepatch
removed: pullrequest
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers