Wishlist: Add a “read more” feature to the OPAC bib record view for fields with lots of text

Bug #1424815 reported by Don Butterworth on 2015-02-23
36
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Evergreen
Wishlist
Unassigned

Bug Description

The issue:
When fields are very long in a bibliographic record and the full text appears immediately in the display, a patron is forced to scroll down to see additional record details.

Recommendation:
In order to preserve a more compact, uniform display on the OPAC Record Detail screen, create a feature that limits the amount of text displayed in some fields; particularly in note fields such as Content Notes, and Summary Notes. When text exceeds the designated limit, hot text such as “read more” or "View complete summary” or “View full contents” will appear which can be clicked on in order to expand and display the full text.

Particulars:
Michael Schell indicated that Fort Erie Public Library has already implemented a “Read More” feature in their test catalog that uses the jQuery plugin. Michael says, “Here is a link to an example. It uses the lightweight jQuery plugin readmore.js from here, and is super easy to setup and has some great options. All it requires is that the [%- INCLUDE "opac/parts/record/contents.tt2" %] from the summary.tt2 be inside article tags like this:
<article>
      [%- INCLUDE "opac/parts/record/contents.tt2" %]
</article>

Several individuals have indicated support for this enhancement request and some noted that they would like this feature included in a public library PAC as well. http://georgialibraries.markmail.org/thread/tgj2qjwjez547cg7

Alex Lazar (alex-lazar) on 2015-07-16
tags: added: opac
tags: added: wishlist
Changed in evergreen:
status: New → Confirmed
Jake Litrell (jake-3) on 2016-05-06
Changed in evergreen:
assignee: nobody → Jake Litrell (jake-3)
Jake Litrell (jake-3) wrote :

Part 1 of 2 - maybe don't merge yet... :) Pure CSS (overloaded checkbox), no javascript.

Backend is mostly there, except for a corner case. CSS needs some specificity. Templates to be done - that's part 2, which was is another server for some reason. ~handwaving~

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jlitrell/LP1424815_long_fields_accordion

Kathy Lussier (klussier) on 2017-06-01
Changed in evergreen:
assignee: Jake Litrell (jake-3) → nobody
Kathy Lussier (klussier) wrote :

I merged a conflict in Jake's branch and rebased it against current master. New partially-done working branch is available at http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/kmlussier/LP1424815_long_fields_accordion

Kathy Lussier (klussier) on 2017-06-02
Changed in evergreen:
assignee: nobody → Kathy Lussier (klussier)
Kathy Lussier (klussier) wrote :

I took some time to look at this code over the past couple of days. Overall, the code in Jake's part 1 branch was successful in displaying more contents of the field. However, I wasn't a big fan of the way it displayed the additional content - see the screencast at https://drive.google.com/file/d/0B74gDMUDwDXqeU50VHdMdVpQLUk/view?usp=sharing.

The rest of the field displays after the 'read more' text, and I had trouble finding a way to change that behavior using the checkbox implementation. I decided to try a simpler CSS approach than what Jake was using. I've added a commit to the above work-in-progress branch that shows my proposed implementation. Still no javascript required.

I have a few todos I still want to work on:
- The current implementation only works with note fields. We have a local use case for truncating the title field on the search results page as well. I would like to add a setting to make that happen for sites that want it.
- We need to account for undefined cont.trunc_length fields
- I would like to put more settings in config.tt2. On the one hand, I like the fact that we can define the maximum character length before truncation on a field-by-field basis. But I also think it will be easier for most sites to just turn it on and identify the maximum character length in one setting for all notes.

Before I work on the remaining to dos, I would like to get some feedback on the branch just to make sure I'm moving in the right direction.

Alternatively, if bug 1642086 is merged, we could explore using the "Read More" jquery plugin. However, since one of the guidelines for jquery use was to only use it for things that can't be handled easily without javascript, I wanted to first see if I could get Jake's code working without the need to use javascript.

I have a working implementation of it at https://mlnc4.noblenet.org/eg/opac/record/249 if anyone wants to see it in action.

Download full text (4.3 KiB)

I like what Kathy has done a lot !

Question. Will there be a setting that can be made by each library
indicating how many characters display before the Read More feature
activates, or is this to be a hard setting?

Don

On Fri, Jun 2, 2017 at 10:51 AM, Kathy Lussier <email address hidden>
wrote:

> I took some time to look at this code over the past couple of days.
> Overall, the code in Jake's part 1 branch was successful in displaying
> more contents of the field. However, I wasn't a big fan of the way it
> displayed the additional content - see the screencast at
> https://drive.google.com/file/d/0B74gDMUDwDXqeU50VHdMdVpQLUk/
> view?usp=sharing.
>
> The rest of the field displays after the 'read more' text, and I had
> trouble finding a way to change that behavior using the checkbox
> implementation. I decided to try a simpler CSS approach than what Jake
> was using. I've added a commit to the above work-in-progress branch that
> shows my proposed implementation. Still no javascript required.
>
> I have a few todos I still want to work on:
> - The current implementation only works with note fields. We have a local
> use case for truncating the title field on the search results page as well.
> I would like to add a setting to make that happen for sites that want it.
> - We need to account for undefined cont.trunc_length fields
> - I would like to put more settings in config.tt2. On the one hand, I like
> the fact that we can define the maximum character length before truncation
> on a field-by-field basis. But I also think it will be easier for most
> sites to just turn it on and identify the maximum character length in one
> setting for all notes.
>
> Before I work on the remaining to dos, I would like to get some feedback
> on the branch just to make sure I'm moving in the right direction.
>
> Alternatively, if bug 1642086 is merged, we could explore using the
> "Read More" jquery plugin. However, since one of the guidelines for
> jquery use was to only use it for things that can't be handled easily
> without javascript, I wanted to first see if I could get Jake's code
> working without the need to use javascript.
>
> I have a working implementation of it at
> https://mlnc4.noblenet.org/eg/opac/record/249 if anyone wants to see it
> in action.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1424815
>
> Title:
> Wishlist: Add a “read more” feature to the OPAC bib record view for
> fields with lots of text
>
> Status in Evergreen:
> Confirmed
>
> Bug description:
> The issue:
> When fields are very long in a bibliographic record and the full text
> appears immediately in the display, a patron is forced to scroll down to
> see additional record details.
>
> Recommendation:
> In order to preserve a more compact, uniform display on the OPAC Record
> Detail screen, create a feature that limits the amount of text displayed in
> some fields; particularly in note fields such as Content Notes, and Summary
> Notes. When text exceeds the designated limit, hot text such as “read more”
> or "View complete summary” or “View full contents” will appear which ...

Read more...

Kathy Lussier (klussier) wrote :

As I alluded to above, in the current implementation, an Evergreen site can determine on a field-by-field basis how many characters should display, but I would like to move that setting into one setting in config.tt2 that governs the maximum character count for all notes. Generally, this setting will be global for the Evergreen instance, but sites that provide different subdomains for individual libraries can change this setting on a library-by-library basis.

However, I'm still on the fence about this approach and have probably shifted to the side of exploring alternatives since posting this branch. When testing this code on real bib records, I found that using an anchor leads to a lot of jumpiness when clicking the Read More link. I plan to look at it a little more closely when tuits free up again.

Terran McCanna (tmccanna) wrote :

I really like what you've done with this, Kathy. I don't have any strong feelings either way with having a global setting to control the character count or not.

Kathy Lussier (klussier) wrote :

I know I'm long past any deadline to add a pullrequest for inclusion in 3.0, but if it can't make it in for 3.0, let's consider this an early entry for the 3.1 release.

I was unhappy with my earlier implementation of this project. One I tested outside of a Concerto database with records that had many and long contents notes, I noticed that the anchor approach led to a lot of jumpiness when clicking the Read More link. See https://drive.google.com/file/d/0B74gDMUDwDXqWXM1Tzd2NVR4N3c/view

Also, if using the back button after clicking a link or two, you would have to click a couple of times before getting back to the search results page. Overall, it felt very clunky. Also, my earlier approach would have required entries in our css sheet for the ids of every single type of MARC note.

My current branch uses jQuery for the links, and it works much more smoothly. I did not use the jQuery plugin mentioned above because I want to limit our use of new plugins unless we absolutely need them, but also because I know Jake's code to create truncated strings does what we need it to.

I have added two config.tt2 settings: one to enable read more for contents notes and another to set the number of characters that should display before truncating the field. If Evergreen sites want to adjust those numbers on a field-by-field basis, I also coded it in such a way that they could use different truncation numbers for specific fields by editing the record/contents.tt2 file.

I would also like to leverage this code to provide a "Read More" link for titles on the search results page (we have some long ones in our catalogs), but that will have to come at a later time.

We also have a fallback for browsers that have disabled javascript.

Adding a pullrequest, but setting the target to 3.next.

Changed in evergreen:
assignee: Kathy Lussier (klussier) → nobody
milestone: none → 3.next
tags: added: pullrequest
Andrea Neiman (aneiman) on 2017-09-01
Changed in evergreen:
importance: Undecided → Wishlist
Kathy Lussier (klussier) wrote :

Since I have a little more time to tackle this, I'm going to remove the pullrequest and work on getting this to work for titles on the search results page too.

Changed in evergreen:
assignee: nobody → Kathy Lussier (klussier)
tags: removed: pullrequest
Kathy Lussier (klussier) wrote :

I force pushed an update to the above branch to address a missing character that broke the entire catalog.

Dan Wells (dbw2) on 2018-01-19
tags: added: pullrequest
Changed in evergreen:
milestone: 3.next → 3.1-beta
Kathy Lussier (klussier) on 2018-02-07
Changed in evergreen:
assignee: Kathy Lussier (klussier) → nobody
Kathy Lussier (klussier) wrote :

I removed myself as the assignee because I don't want to miss the chance of getting the note field Read More links added to the next release. I worked on the title links at the hack-a-way, but I was encountering an Internal Server error and haven't had the tuits to investigate further.

However, I wanted to add a note that there are existing bugs related to jQuery that should be addressed before we start adding too many features that rely on jQuery. I think they are harmless for most people now because people haven't had a reason to enable jQuery, but once this and other features are added, they will become a problem.

See bug 1739666 and bug 1745190.

Remington Steed (rjs7) on 2018-02-23
Changed in evergreen:
assignee: nobody → Remington Steed (rjs7)
Remington Steed (rjs7) wrote :

I tested this branch, and it worked, but after reading through the code I decided to try cleaning it up some. After the cleanup, it works the same as advertised. Here's my sign-off branch, with one extra commit on top:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/rsteed/lp1424815_long_fields_accordion_jquery-approach

And from the commit message:
-----------

This commit attempts to cleanup and simplify the "Read more" catalog
feature by making the following changes:

  - Simplify perl util function
    - Remove extra blank lines
    - Remove first IF branch, since rindex already covers this case
    - Remove "rest" from return value, since Kathy's changed stopped
      using it
    - Add logic to address the FIXME comment
    - Add a few code comments

  - Simplify template
    - Only split a string if feature is turned on in config settings
    - Allow, but don't require, "trunc_length" on every marc note field
    - Add a few code comments

Changed in evergreen:
assignee: Remington Steed (rjs7) → nobody
Kathy Lussier (klussier) wrote :

Thanks for the cleanup Remington! I like the changes and added my signoff to your commit. THe signoff branch is at http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/kmlussier/lp1424815_long_fields_accordion_jquery-approach-signoff

I really would love to see this feature get into 3.1, and I think a lot of other people would love to see it to. However, I didn't merge it to master due to the concerns I raised in comment #11. It would be difficult to implement this new feature while those other bugs exist. I'm in favor of merging it with the hope that we can get those jquery bugs addressed, but I'm obviously biased and thought that decision might be best left in the hands of a less biased person.

Mike Rylander (mrylander) wrote :

I'm going to assign myself to this and check to see if the truncation would have an effect on highlighted (via wrapping <span>s) content...

Changed in evergreen:
assignee: nobody → Mike Rylander (mrylander)
Mike Rylander (mrylander) wrote :

Arg... I was afraid of this.

So, with the new highlighting code, we get properly formatted HTML fragments from the backend and where we can use them we inject them directly. The good news is that the code, as it stands at the moment after resolving conflicts with that branch, would force a choice between the features rather than breaking strings mid-highlight (I believe). The bad news is that some significant work would need to happen if it were to be able to handle the Display Field highlighted data.

Also, we need to be careful about using "id" attributes on potentially duplicatable elements. I don't /think/ that's happening here, but it would be easy to slip in.

In any case, it does look useful. Thanks, all, for working on it.

Changed in evergreen:
assignee: Mike Rylander (mrylander) → nobody
Dan Wells (dbw2) wrote :

I decided to review this also and see if Mike missed anything, but he's right on. It needs a pretty major rethink to make this work with highlighting, and to do it right. I'm sorry!

FWIW, I did create another clean-up branch to remove white-space changes and one unused (I think) 'id' change.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/dbwells/lp1424815_long_fields_accordion_jquery-approach-signoff

Dan

Kathy Lussier (klussier) on 2018-03-01
tags: added: needsrepatch
removed: pullrequest
Changed in evergreen:
milestone: 3.1-beta → 3.next
Kathy Lussier (klussier) on 2018-06-12
Changed in evergreen:
assignee: nobody → Kathy Lussier (klussier)
Kathy Lussier (klussier) wrote :

I've rebased the branch against current master and pushed the new branch to:
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/kmlussier/lp1424815_long_fields_accordion_jquery-approach

It's still not ready for testing since I haven't yet looked at the display field problem.

Kathy Lussier (klussier) wrote :

While looking at the display field issue, I also noticed another problem with the previous implementation of the code. Repeatable note fields were not repeating in the display when this code was applied. For example, record 78 in the Concerto dataset has three 500 fields, but only one 500 field displayed as a general note.

Kathy Lussier (klussier) on 2018-11-05
Changed in evergreen:
assignee: Kathy Lussier (klussier) → nobody
Kyle Huckins (khuckins) on 2019-01-14
Changed in evergreen:
assignee: nobody → Kyle Huckins (khuckins)
Kyle Huckins (khuckins) wrote :

I'm picking this up on behalf of MassLNC. After reviewing the previous code and the issues and conflicts that have been brought up, I'm thinking of taking a frontend approach, gathering the text after it's been fetched and then shortening it. I believe this would avoid the highlighting incompatibility.

Not much to see here just yet, but here's my WIP branch: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/khuckins/lp1424815-OPAC-bib-read-more

Kyle Huckins (khuckins) wrote :

Taking a vanilla JS approach to this, I ended up backtracking and retreading some of the waters that have been tread in previous attempts at this functionality. I've updated the above branch with a solution that may be a bit hacky: it temporarily strips the <b>, classes and all, then performs the initially implemented accordion script, then reapplies the highlighting using the query parameter in the URL. Without a refactor of how highlighting works, I'm not sure of a better way to do this. The branch is still in a WIP state, but as it stands, the code is now friendly toward highlighting. The primary issue is ensuring the content displays in the proper location, which I'm nearing a fix on.

Kyle Huckins (khuckins) wrote :

I've made some additions and squashed things down to a single commit - note fields now work as one would expect with both read more and highlighting functionality. On reviewing some of the further requirements, implementation of the existing code will be needed on other fields, but the core of the functionality is done.

Kyle Huckins (khuckins) wrote :

I've pushed a further commit that takes a cue from previous attempts at this card, implementing config.tt2 variables previously considered to better manage truncation lengths. A macro has been created to truncate fields as well, which is utilized for the fields shown in Record Details. I haven't applied these changes to fields under subjects.tt2, series.tt2, or extras.tt2 as their contents don't appear to get particularly large, or are toggled as hidden by default already.

Changed in evergreen:
assignee: Kyle Huckins (khuckins) → nobody
tags: added: pullrequest
removed: needsrepatch
Dan Wells (dbw2) on 2019-02-06
Changed in evergreen:
milestone: 3.next → 3.3-beta1
Kyle Huckins (khuckins) on 2019-02-28
Changed in evergreen:
assignee: nobody → Kyle Huckins (khuckins)
tags: removed: pullrequest
Kyle Huckins (khuckins) wrote :

Additional commits have been made to let the accordion feature affect the title and entries in the search results UI, as well as making the Read More buttons into links, as originally requested. The accordion macro has been moved to misc_util so it can be used in other interfaces that utilize misc_util. Still trying to work out how to handle the fields used in authors.tt2.

Changed in evergreen:
milestone: 3.3-beta1 → 3.3-rc
Changed in evergreen:
milestone: 3.3-rc → 3.next
Kyle Huckins (khuckins) wrote :

Rebased to current master and updated to support graphics880 fields. The author fields are the last piece of this puzzle, and I'm somewhat worried that it might require some rethinking of how the authors fields are generated/displayed.

Reposting the branch so it doesn't get drowned in comments: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/khuckins/lp1424815-OPAC-bib-read-more

Kyle Huckins (khuckins) wrote :

New update has been pushed that refactors the read more scripts a bit, reducing code duplication in the Notes section and the misc_util accordion() macro. Using HTML::Element and HTML::TreeBuilder, the accordion can now handle the Added Authors portion of the contributors block. More work is required to get it working with more complex HTML blocks that happens with other parts of the contributors block(such as Cast).

The somewhat hacky additions that ensures highlight compatability have been removed, as they are no longer needed thanks to the use of HTML::Element and HTML::TreeBuilder.

Kyle Huckins (khuckins) wrote :

I was able to determine it was specifically not working with 511(Casts) fields. I've amended my previous commit to cover 511 fields in the authors block. This has the unfortunate byproduct of including the (Cast) at the end of the field in the clickable link, though it isn't added to the actual search query, so as far as potential issues go, it's fairly benign.

tags: added: pullrequest
Changed in evergreen:
assignee: Kyle Huckins (khuckins) → nobody
Jane Sandberg (sandbej) wrote :

Thanks for your thorough work on this, Kyle. We will need a release notes entry for this as well.

tags: added: needsreleasenote
Kyle Huckins (khuckins) wrote :

I've just pushed an additional commit providing release notes for this feature

tags: removed: needsreleasenote
Ruth Frasur (rfrasur) wrote :

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

tags: added: signedoff
Changed in evergreen:
milestone: 3.next → 3.5-alpha
Michele Morgan (mmorgan) wrote :

Just want to add that NOBLE has been using this code on our production server for about six months and it's a great improvement to the opac.

Dan Wells (dbw2) wrote :

I really appreciate the effort put into this patch. I have only given this eyeball testing, and while it appears to be basically sound as far as functioning, I feel like the design is still fundamentally upside-down. That is, we shouldn't be reparsing and breaking down HTML strings that we are already constructing on the fly, we should look for a way to treat highlighting *and* truncating as two aspects of the same operation (preparing the field for display), and do them in the same place, all at once.

As it stands, I think this design creates undue complexity and therefore would be a maintenance burden moving forward.

My two cents,
Dan

Dan Wells (dbw2) wrote :

Oof, re-reading my comment, it came out perhaps a little more harsh than intended. Sorry for that!

My main point is merely to suggest that a more unified approach probably exists, though it may mean digging a layer or two deeper. After all, we hold all the cards! :)

Changed in evergreen:
milestone: 3.5-beta → 3.5.0
Changed in evergreen:
milestone: 3.5.0 → 3.5.1
Jane Sandberg (sandbej) on 2020-07-21
Changed in evergreen:
milestone: 3.5.1 → 3.6-beta
Christopher Burton (cburton) wrote :

https://bugs.launchpad.net/evergreen/+bug/1778972 implements a fix to having too much information on a record as well by just hiding information that is more relavent to librarians or "the experts" and only showing it as needed with a simple button.
This is targeted for 3.6 release and may just satisfy at least a part of this need?

It does bring the copy table right up to reduce extra scrolling

Changed in evergreen:
milestone: 3.6-beta → 3.next
Michele Morgan (mmorgan) on 2020-11-03
Changed in evergreen:
milestone: 3.next → 3.7-beta
Michele Morgan (mmorgan) wrote :

Resolved a conflict and added Ruth's signoff (comment #29) and my own. Branch is here:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=4eb9e7f5b7b7e719c7f9a13eccd6b15a9d43d09a

working/Evergreen.git;a=commit;h=4eb9e7f5b7b7e719c7f9a13eccd6b15a9d43d09a

Galen Charlton (gmc) on 2021-03-15
Changed in evergreen:
assignee: nobody → Galen Charlton (gmc)
Galen Charlton (gmc) wrote :

Although I have reservations about the implementation (I think it would be better done entirely client-side), I've pushed it to master for inclusion in 3.7. Thanks, Kyle, Ruth, and Michele.

Changed in evergreen:
status: Confirmed → Fix Committed
assignee: Galen Charlton (gmc) → nobody
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers