OPAC -"Add to my list" not displaying properly

Bug #1182547 reported by Deborah Luchenbill
56
This bug affects 12 people
Affects Status Importance Assigned to Milestone
Evergreen
Won't Fix
Undecided
Unassigned

Bug Description

We are in version 2.3.3:

When patrons are logged into their accounts on the OPAC, do a search, and choose to "Add to my list," items in their search results, the link no longer changes to "Remove from my list," as it used to. The items are being added to the lists, but there isn't anything to let the patron know that happened (or where on the list they left off, if they're adding several items). It doesn't matter it it's to a temporary list or to an already existing list.

When a patron is not logged in/anonymous and does the same procedure, the link does change to "Remove from my list."

Tags: opac
Kathy Lussier (klussier)
Changed in evergreen:
status: New → Confirmed
Revision history for this message
Kathy Lussier (klussier) wrote :

Confirming that the "Remove from my list" option is no longer appearing for logged-in users in both 2.3 and master.

In looking at this feature side-by-side with a 2.2 system, the "Add to list" feature worked the same whether the user was logged in or not. With the logged-in users, you only had the "Add to list" option, and the title was added to a temporary list. Whenever the remove option was used, tpac knew that it needed to be removed from the temporary list.

It's a little more complicated with 2.3. The logged-in user now has the option to add it to a temporary list or to one of the user's permanent book lists. To get the "Remove from my list" option back, do we need a way tell tpac which list to remove it from?

Revision history for this message
Holly Brennan (hollyfromhomer) wrote :

We are running 2.3.4 and are also encountering this problem. We just went live in March so I can't say what happened on other versions.

A confirmation that something happened (or failed to happen) would be great!

Revision history for this message
Ben Shum (bshum) wrote :

Just some initial thoughts... With how the new hovering works in 2.3+, when you're logged in, you get the options to add items to a particular list, default list, or temporary list. So, the link is always going to give you the option to add to a list. Having the text change to "remove from list" is no longer appropriate in my opinion since you might add to one list, hover, and add to another list, etc. Perhaps if it said something like "Add to / edit my list", that might make more sense.

Alternatively, perhaps we need better ways of notifying the end user that an action has occurred other than the label on the screen. Maybe a popup of some kind like "bib X was added to list Y"?

I'm not sure how feasible or not it would be to have a remove from list option that affects the hover smartly (but I would suspect that it's a performance issue to determine whether or not a particular title is already or not on any given list for display purposes?).

Revision history for this message
Jason Stephenson (jstephenson) wrote :

The lack of confirmation has its own bug# 1181018. I think that discussion should happen there.

When implementing this feature, I could think of no good solutions for making it easy to remove lists on the search page, and since that was also not part of the specification for the new feature, I didn't try too hard to come up with one. I figured that a patron could go to their lists under My Account and manage them there.

The reason you get the Remove From List when not logged in is that behavior was little changed. Originally, adding to my list always added to a temporary list in TPAC, when logged in or not, and the patron had to know to got to that list and move things to permanents lists.

Revision history for this message
Kathy Lussier (klussier) wrote :

I wasn't thinking that we should have a new function that checks to see if a particular title is in a user list, because I agree that it could be a hit on performance. The previous functionality only added the "Remove from list" link directly after the user added a title to the list. If the user performed another search in which the same title appeared, they did not receive that option.

I wasn't too articulate in my previous comment, but what I was trying to convey was that it is indeed more complicated now that we have the ability to add to any number of lists from this screen.

When we were planning for the development that added the hover menu, I had looked at various web sites that allowed users to add to a list. One method I saw that was quite effective was a pop-up, as Ben describes, that displays the title, confirms that it was added to foo list, and then provides a link to view/manage the list or to return to the previous screen. Clicking the link to return to the previous screen would then close the popup. Perhaps a "remove" link could be added there too.

I would be happy to mock this up if others think it is a good idea.

Revision history for this message
Srey Seng (sreyseng) wrote :

I think a pop-up might be a tab bit intrusive, and might loose some of the ease that comes with quickly being able to add books to lists.

For example, a pop-up will force user interaction, when for the most part, the user is only interested in passively knowing that the book has been added.

Revision history for this message
Blake GH (bmagic) wrote :
Revision history for this message
Bob Wicksall (bwicksall) wrote :

Evergreen 2.7.5 still has this issue.

Revision history for this message
Blake GH (bmagic) wrote :

The code I put in the working repo will only provide feedback when someone adds something to the list. It does not cross reference all of the bibs in all of the lists and display a visual cue when any bib matches. Our libraries would like the OPAC to have a visual cue to inform the patron when they come across any bib that they have it in one of their lists.

The problem with that is performance. We don't want the server to do all of that work and make the browser wait for the server to spider through a potentially huge list of bibs and cross reference them to the displaying page.

Does this idea sound like it would work: Upon login, set a cookie. This cookie would be an array of bib id's and attached to list id's. Then let the browser do the work after the page has loaded. Let dojo/jquery go through the page and alter the markup when it encounters a match?

tags: added: opac
Revision history for this message
Blake GH (bmagic) wrote :

I believe the root issue here is resolved with the introduction of Baskets in EG 3.2. Anyone else agree?

Revision history for this message
Terran McCanna (tmccanna) wrote :

I agree that the new basket functionality has resolved this issue. Marking this Won't Fix.

Changed in evergreen:
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.