Angular Catalog should include "Summary" Tab

[John Amundson]

This is a sort of wishlist bug but also a regression, so I'm tagging it as both...

This request has come out of testing Evergreen 3.7.2 in preparation for our next upgrade.

When a record is pulled up in the Angular Catalog, there is very little content actually pertaining to the record. The record summary contains basic details such as Title, Author, and Published Date, but it's missing other useful/important information such as ISBN (LP Bug #1946777) and links to quickly search on Title and Author (LP Bug #1910446). In addition, it's missing information that's important for both catalogers and circ staff looking to place holds.

Right now, there is no way on the record itself to quickly see information such as physical description, (page counts, size, etc), summaries, other formats, etc.

Yes, the user can click on "Patron View", which is a great addition, but this opens the traditional catalog in a new tab, and anything the user does at this point - click on another format or subject, place a hold, etc - is done in the traditional catalog.

It also adds another step for catalogers to check to make sure they are attaching to the right record. They have three options, but none of them are great:
- See physicals descriptions on the Search Results page.
- Open up MARC View/Edit.
- Open up Patron View.

I propose adding a new tab, (and making it the default/first tab) called "Quick Summary" or "Summary", that contains some of the information present in the traditional catalog.

- Record Details
-- Authors / Added Authors / Cast / Etc - all with links
-- ISBN
-- Physical Description
-- Publisher
-- Etc

- Content Descriptions
-- Notes
-- Summary
-- Etc

- Search for related items
-- By subjects with links
-- By genres with links
-- etc

- More Options
-- Other formats and editions with links

- Copies and Holds
-- Available and total copies at network/preferred library/chosen library/etc
-- Hold count

Essentially anything that appears in the summary in the OPAC or included under "More Details".

Perhaps the Electronic Resources links that appear in the Record Summary currently could also be brought down into this tab, decreasing the size of the Record Summary for records with many links.

The formatting of this page doesn't have to be fancy or formatted like in the OPAC. It just needs to simply list the information so that staff can stay in the Angular catalog and actually use it.

[John Amundson (jamundson)]

Attaching a quick mock-up. Most of this is copy and pasted from the OPAC so the formatting will probably look different, but this generally my idea.

[Elizabeth Thomsen (et-8)]

I complete agree with everything John wrote. The lack of a full record view has been the biggest complaint with the Angular staff catalog here -- a big issue for both public and tech services staff. As John notes, the Patron View is helpful but it's an extra click and can't be set as the default tab. We'd like this to match the local catalog display as much as possible -- everything that's a link in the public catalog should be a link in the staff catalog so staff users can jump around to different formats and editions, other works by the same author, etc., whether they are looking for the right record to attach an item, order or hold to, or selecting titles to recommend to a patron, add to a carousel, or whatever.

We also want to have our added content from NoveList Select here -- staff use that all the time to find related titles (readalike, series, etc.)

[John Amundson (jamundson)]

Thanks, Elizabeth!

My additional two cents on this is that I think we should try to avoid simply replicating the OPAC View on this page. The catalog already had that, it didn't work well, and it was replaced with the Patron View option.

I'd like to see the tab limited to useful information that doesn't necessarily slow down the whole process. I personally find the angular catalog much speedier than both the old catalog and the BOOPAC (did I write that right?). I'd like to try to maintain the speed while bringing back as much of this information as possible. [After placing holds in the Angular catalog, I never want to go back to the old way. It's so fast and informational.]

That said, any info we put that can be linked should be linked - authors, other formats, subjects, etc.

[Ruth Frasur Davis (redavis)]

Just adding in a voice of support for this feature. I also agree that keeping this as light but informative is preferable. A new library setting that allowed for added content to be enabled/disabled in this view might also be a good idea.

[Elizabeth Thomsen (et-8)]

We would be happy with a library setting to enable/disable the added content, or maybe the added content is closed by default and opened with a click (touch, tap, etc.)

[Elaine Hardy (ehardy)]

I am a little confused by the need for this, particularly in light of the statements "When a record is pulled up in the Angular Catalog, there is very little content actually pertaining to the record" and the "lack of a full record view"

When I pull up a record in the Angular catalog, I can see it in MARC view. Which is the complete MARC record. Am I missing something?

[John Amundson (jamundson)]

Elaine, the MARC View is there, but very little of the information from the MARC is "translated" and viewable outside of the MARC.

There is also missing 'metadata' that makes navigating the catalog harder - links to authors, other formats, editions, subjects, etc.

A non-cataloger, such as circ staff, who uses the catalog to place holds won't know to go to MARC View or how to read it. Simple things like the description/summary of the title needs to be more accessible.

Some of our libraries are quite small, as well, and they may only be borderline familiar with the MARC. It would be good to get the generic information needed to ensure they are attaching to the right record out of the MARC - ISBN, size, pages, etc.

[Elaine Hardy (ehardy)]

John,

Thanks for the clarification.

The sounds to me like a summarized OPAC view based on what we had several versions ago, with active links and icons, pulling in number of copies from the staff display in a format which can be displayed compactly without clicking on more details and is available as a tab in the staff catalog. Perhaps Quick view rather than summary?

I can see where this would be useful for a number of reasons.

Consider how a record with a large number of ISBNs would appear in the view. Specifically a record for a graphic novel that has an ISBN for every volume, which is 50+ and counting. Should you limit the number of ISBNs displayed? I am not a fan of having all the ISBNs display as EG does now in a number of places.

Another problematic display might be a DVD with extensive cast and crew entered in 700 fields. Those fields are currently listed in the OPAC at the beginning of the record, making the OPAC record unwieldy and requiring a lot of scrolling. Limiting the number would mean not all would be available by links, however. Perhaps having a limited number at the beginning of the record and the remainder at the end (which I would love to see in the OPAC)

I think having the added content here, particularly if locally controlled, would also be useful.

[Andrea Neiman (aneiman)]

CW MARS has signed a contract with Equinox to create a "Staff View" tab in the manner that John describes in the OP.

[John Amundson (jamundson)]

Related bug - added content - https://bugs.launchpad.net/evergreen/+bug/1991294

[Jason Etheridge (phasefx)]

Top five commits at collab/phasefx/lp1959010-catalog-quick-view

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/phasefx/lp1959010-catalog-quick-view

For those interested, more granular commits at

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/phasefx/catalog-quick-view-wip

[Jason Stephenson (jstephenson)]

Is this a regression that will go into 3.10 and/or 3.9? Is this considered a "new feature?" That needs to be cleared up so we can target this bug properly.

That said, since CW MARS tested the work in progress branch, I'll grab this for now so we can check that nothing was lost in the branch cleanup.

[Jason Stephenson (jstephenson)]

The branch does not apply to rel_3_10 because of the changes to use ngbnav in master. The previous work in progress branch did apply to 3.10 because it predated those changes.

Jason Etheridge: Would it be onerous to produce a backport branch for 3.10?

[Jason Etheridge (phasefx)]

Hey Jason, it's outside the scope of where I can spend my time, but the individual commits prior to the most recent rebase (and the tab changeover) exists in the -wip branch if you want to tackle it. I just squashed them together.

[Jason Etheridge (phasefx)]

Oops, no, I was wrong, the -wip has the rebase too. :-(

[Jason Stephenson (jstephenson)]

I was able to apply this to a custom 3.10 branch with a cherry-pick of commit 365e6c38f52029e9c4464c277f81d1747b9cf9c5 from the master branch.

I have not tested it, yet.

[Andrea Neiman (aneiman)]

Adding my two cents that this is a new feature, and 3.11-beta is the appropriate target.

[Elaine Hardy (ehardy)]

I think it is a regression since we had the patron view tab previously and this builds on that.

[John Amundson (jamundson)]

Jason Stephenson installed this code on a 3.10 server for testing purposes. He compared our branch with the working branch and didn't notice any differences.

He recommended that I update this bug because I am seeing missing behavior.

Hold and copy counts should be updating automatically when a hold is placed or copy added, respectively, but that is not happening. I have to refresh the page to get the counts to update. This behavior was fixed towards the end of development with Equinox, but it does not appear to be in the working branch, or at least not applying for some reason on our server, (that Jason S), cannot find.

[John Amundson (jamundson)]

Actually, I think that last comment can be struck.

The automatic refresh is happening, it's just very slow and inconsistent on our server. Right now I'll assume that's because of the specs of our server.

[Jason Stephenson (jstephenson)]

I mostly agree with Elaine's comment #19. In order for this to be backported to 3.10, the ngbnav changes from bug 1948693 also need to be backported. I have done this in the branch that CWMARS has been testing for our upgrade to 3.10 next month. Both changes apply cleanly and work without issue.

I recommend backporting both branches, but I won't target the bugs pending consensus.

Also, John's comments 20 and 21 have changed. He was originally testing on a slow VM running against a database server with a failing hard drive. The VM host and database server have been replaced and performance is as expected. I believe that he also found the performance to be as expected on our normal test/training server, but if he wishes to clarify anything, he may speak for himself.

[John Amundson (jamundson)]

Thanks, Jason. Yes, once we figured out issues on our side, the code itself behaved as expected.

[Gina Monti (gmonti90)]

Testing this for Bug Squash 2/2023 on the Mobius server. I wasn't able to find the summary tab. Can someone send a screenshot of what that would look like if they have it?

[John Amundson (jamundson)]

Gina, it's called "Staff View", and it should show up on a tab to the left of "Item Table".

Attached is a screenshot from https://bugsquash.mobiusconsortium.org/

It can be set as the Default View if desired. Item Table was kept as the default default view to maintain status quo.

[Mary Llewellyn (mllewell)]

Looks nice. I think it will make some public services librarians very happy.

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

[Galen Charlton (gmc)]

Pushed to master for inclusion in 3.11-beta. Thanks, Jason, Stephanie, Mary, and everybody else who tested!

I don't have a personal objection to a backport to rel_3_10. However, Jason S., if you could open a new bug and post the 3.10-ish branch where you got it work, please do so. There are likely some ngbTab => ngbNav follow-up patches that we'll need to put in place as well to do it.