This feature displays recently added items to your Koha's main OPAC page, using a 'carousel' style display. This feature can be enabled/disabled via a Koha syspref, and requires memcached. This feature can be styled and configured using CSS. A demo of the feature (Koha-3.10) is available at http://demo.calyx.net.au This feature adds to Koha the ContentFlow library by JacksAsylum.eu (MIT license): http://jacksasylum.eu/ContentFlow/index.php Special thanks to Harvest Bible College, Australia for sponsoring this feature. Thanks also to Albany Senior High School,New Zealand and KohaAloha for an earlier prototype.
Any movement here? :-)
Oh yeah! This is a nice feature! Its been almost 2 years any update on this? Thanks!
This will be a nice feature added into Koha ILS, instead of trying out different technologies just to make this work, which can be a migration headache.
The coverflow plugin : http://bywatersolutions.com/koha-plugins/ uses the public reports to generate a responsive carousel of books.
Created attachment 51173 [details] [review] Bug 10756 - Carousel Display of New Titles on OPAC home page add ContentFlow dir http://www.jacksasylum.eu/ContentFlow
Created attachment 51174 [details] [review] Bug 10756 - Carousel Display of New Titles on OPAC home page test plan... 1/ import some bibs into your database for testing (important) $ wget http://www.loc.gov/catdir/cpso/RDAtest/extra_bib_marc.zip $ unzip extra_bib_marc.zip $ bulkmarcimport.pl -b -m ISO2709 -file ./formal_extra_all_final.bib 2/ apply patches 3/ execute atomic update to add syspref and 'Carousel' table $ perl ./installer/data/mysql/atomicupdate/Bug-10756-carousel.pl 4/ open OPAC homepage in web-browser, observe no change 5/ set 'OpacCarousel' syspref to 'display' 6/ open OPAC homepage in web-browser, observe a new carousel :0) extra QA tests... 7/ run 5 carousel tests $ prove ./t/db_dependent/Carousel.t 8/ run qa-tool on patchset $ qa -c 2
QA note: patchset applied to 68dbe84 'Bug 14632: Add Copyright for the Koha'
(In reply to Mason James from comment #7) > QA note: patchset applied to 68dbe84 'Bug 14632: Add Copyright for the Koha' That bug number and title does not match up.
Created attachment 51175 [details] [review] Bug 10756 - Carousel Display of New Titles on OPAC home page add ContentFlow dir http://www.jacksasylum.eu/ContentFlow Signed-off-by: Magnus Enger <magnus@libriotech.no> Comment on the other patch.
Created attachment 51176 [details] [review] Bug 10756 - Carousel Display of New Titles on OPAC home page test plan... 1/ import some bibs into your database for testing (important) $ wget http://www.loc.gov/catdir/cpso/RDAtest/extra_bib_marc.zip $ unzip extra_bib_marc.zip $ bulkmarcimport.pl -b -m ISO2709 -file ./formal_extra_all_final.bib 2/ apply patches 3/ execute atomic update to add syspref and 'Carousel' table $ perl ./installer/data/mysql/atomicupdate/Bug-10756-carousel.pl 4/ open OPAC homepage in web-browser, observe no change 5/ set 'OpacCarousel' syspref to 'display' 6/ open OPAC homepage in web-browser, observe a new carousel :0) extra QA tests... 7/ run 5 carousel tests $ prove ./t/db_dependent/Carousel.t 8/ run qa-tool on patchset $ qa -c 2 Signed-off-by: Magnus Enger <magnus@libriotech.no> Followed the test plan, everything worked as expected. The front page displays a nice coverflow widget. More parameters to control the widget would be nice, but that could be added later. On first running this I got a nasty 500 error: "Can't call method "is_valid" on an undefined value at /home/magnus/scripts/kohaclone/Koha/Carousel.pm line 128." But I think I found a cure for that and will propose a followup patch.
Created attachment 51177 [details] [review] Bug 10756 - Carousel Display - Followup On first testing this I got a 500 error saying "Can't call method "is_valid" on an undefined value at /home/magnus/scripts/kohaclone/Koha/Carousel.pm line 128." This was caused by a record with an ISBN of "979-10-91414-01-2". The relevant code looks like this: my $isbn_obj = Business::ISBN->new($ii); my $isbn10; $isbn10 = $isbn_obj->as_isbn10; if ( $isbn10->is_valid() ) {...} The documentation for Business::ISBN::as_isbn10 says: "Returns a new ISBN object. If the object is already ISBN-10, this method clones it. If it is an ISBN-13 with the prefix 978, it returns the ISBN-10 equivalent. For all other cases it returns undef." So for an ISBN that starts with 979 like mine did, $isbn10 will be undef and we need to do some extra checking before is_valid(). To test: - Apply the first two patches on this bug and follow their test plan - Make sure you have a new record with an ISBN that starts with 979 - Refresh the front page and observe the error - Apply this patch - Refresh the front page again and notice the absence of the error
I have signed off the two original patches from Mason. As noted in the sign off message I found a problem for 13 digit ISBNs that do not start with 978. The third patch attempts to fix this. I think my patch needs a signoff, so I am leaving this bug as "Needs Signoff".
Mason: Just wondering why you picked ContentFlow? I once wrote something simple with jquery.jcarousel.min.js and just note that this carousel is considerably larger (18K vs 264K?). BTW I am not saying that we should use the other one :) On http://www.jacksasylum.eu/ContentFlow/ I only see changelogs until 2010? If there is no further development(?), this might be a risk.
I don't see the advantage of this implementation against Bywater plugin. I can rather see disadvantages, including ContentFlow.js obsolescence (not updated since 2010, when jQuery Flipster used by ByWater plugin is actively maintained). Reading the code, I don't understand how GetRecentBibs generates the list of 'recent' bibs. Why a new table (carousel)? Is it necessary to read/re-read this table each time the OPAC main page is loaded?
Created attachment 51187 [details] [review] Bug 10756 - Carousel Display - Followup On first testing this I got a 500 error saying "Can't call method "is_valid" on an undefined value at /home/magnus/scripts/kohaclone/Koha/Carousel.pm line 128." This was caused by a record with an ISBN of "979-10-91414-01-2". The relevant code looks like this: my $isbn_obj = Business::ISBN->new($ii); my $isbn10; $isbn10 = $isbn_obj->as_isbn10; if ( $isbn10->is_valid() ) {...} The documentation for Business::ISBN::as_isbn10 says: "Returns a new ISBN object. If the object is already ISBN-10, this method clones it. If it is an ISBN-13 with the prefix 978, it returns the ISBN-10 equivalent. For all other cases it returns undef." So for an ISBN that starts with 979 like mine did, $isbn10 will be undef and we need to do some extra checking before is_valid(). To test: - Apply the first two patches on this bug and follow their test plan - Make sure you have a new record with an ISBN that starts with 979 - Refresh the front page and observe the error - Apply this patch - Refresh the front page again and notice the absence of the error Signed-off-by: Mason James <mtj@kohaaloha.com>
(In reply to Marcel de Rooy from comment #13) > Mason: > Just wondering why you picked ContentFlow? 2 reasons, 1/ it's the carousel CALYX selected for production 3 years ago 2/ it works well in responsive views, (others did not work) > I once wrote something simple with jquery.jcarousel.min.js and just note > that this carousel is considerably larger (18K vs 264K?). BTW I am not > saying that we should use the other one :) > On http://www.jacksasylum.eu/ContentFlow/ I only see changelogs until 2010? > If there is no further development(?), this might be a risk. I think it a great idea to offer multiple carousel options, but I left this extra functionality until after the patch was accepted I plan to add other carousels to the feature, should the patch be accepted
(In reply to Marcel de Rooy from comment #13) > On http://www.jacksasylum.eu/ContentFlow/ I only see changelogs until 2010? > If there is no further development(?), this might be a risk. I can see that as blocker, Mason, would it be easy to update the plugin you used? (In reply to Frédéric Demians from comment #14) > I don't see the advantage of this implementation against Bywater plugin. I > can > rather see disadvantages, including ContentFlow.js obsolescence (not updated > since 2010, when jQuery Flipster used by ByWater plugin is actively > maintained). Reading the code, I don't understand how GetRecentBibs generates > the list of 'recent' bibs. Why a new table (carousel)? Is it necessary to > read/re-read this table each time the OPAC main page is loaded? Same for me, it's not conceivable to call this subroutine for each get of the opac main page. Could you please detail what is the purpose of this subroutine? Why do you need a new table, cache of the image url that's it? Additional comments: - kohastructure.sql changes are missing - Amazon lookup should be optional - We have several subroutines in C4::Koha to deal with ISBNs, I am sure you could reuse - What are the 150 and 300 hardcoded limits? - It would be better to use Koha::Object - It would be great to remove all the debug variables, it will ease the readability
(In reply to Jonathan Druart from comment #17) > (In reply to Marcel de Rooy from comment #13) > > On http://www.jacksasylum.eu/ContentFlow/ I only see changelogs until 2010? > > If there is no further development(?), this might be a risk. > > I can see that as blocker, Mason, would it be easy to update the plugin you > used? hi, yes - its very easy to swap the carousel plugin to anything else i'm happy to change the carousel plugin to whatever people desire > (In reply to Frédéric Demians from comment #14) > > I don't see the advantage of this implementation against Bywater plugin. afaik, the big advantage is that the Bywater plugin can't display an *automated* selection of verified cover-images for recently added items i think for the Bywater plugin, a manual list (report?) would need to be created daily, then each item manually verified for a matching amazon image? > > rather see disadvantages, including ContentFlow.js obsolescence (not updated > > since 2010, when jQuery Flipster used by ByWater plugin is actively > > maintained). Reading the code, I don't understand how GetRecentBibs generates > > the list of 'recent' bibs. Why a new table (carousel)? Is it necessary to > > read/re-read this table each time the OPAC main page is loaded? > > Same for me, it's not conceivable to call this subroutine for each get of > the opac main page. with a warmed cache table, the GetRecentBibs() sub takes around 10ms on my old slow VM. 10ms seems acceptable? > Could you please detail what is the purpose of this subroutine? the subroutine returns a list of recently added bibs with verified matching amazon cover images > Why do you need a new table, cache of the image url that's it? yes, thats all - a method of caching the urls is needed for the feature to work at an acceptable speed fyi: i did experiment with memcache - but the speed difference was small/negligible, so i decided upon the convenience of a mysql table instead > Additional comments: > - kohastructure.sql changes are missing thanks, i can do this - no problem > - Amazon lookup should be optional amazon lookups effectively cease (ie: become 0) as the cache table becomes populated so this is probably not needed? (unless i misunderstand your point) > - We have several subroutines in C4::Koha to deal with ISBNs, I am sure you > could reuse thanks for the suggestion, i could use NormalizedISBN() instead > - What are the 150 and 300 hardcoded limits? they are limits to reduce the item list, the values were chosen to give a happy balance of acceptable performance and a good selection of randomised items > - It would be better to use Koha::Object sure, i can do this - no problem > - It would be great to remove all the debug variables, it will ease the > readability i would really prefer to leave the debug/profiling code (should any future problems occur?), i'm happy to tidy/improve the readability of the profiling code
> > Same for me, it's not conceivable to call this subroutine for each get of > > the opac main page. > > with a warmed cache table, the GetRecentBibs() sub takes around 10ms on my > old slow VM. 10ms seems acceptable? a small missed point.. the GetRecentBibs() sub is only executed if the Caro syspref is manually enabled
(In reply to Jonathan Druart from comment #17) > (In reply to Marcel de Rooy from comment #13) > > On http://www.jacksasylum.eu/ContentFlow/ I only see changelogs until 2010? > > If there is no further development(?), this might be a risk. > > I can see that as blocker, Mason, would it be easy to update the plugin you > used? Jonathan, can you please suggest a replacement for ContentFlow, so I may proceed
(In reply to Mason James from comment #20) > (In reply to Jonathan Druart from comment #17) > > (In reply to Marcel de Rooy from comment #13) > > > On http://www.jacksasylum.eu/ContentFlow/ I only see changelogs until 2010? > > > If there is no further development(?), this might be a risk. > > > > I can see that as blocker, Mason, would it be easy to update the plugin you > > used? > > Jonathan, can you please suggest a replacement for ContentFlow, so I may > proceed I have no idea, but reading the previous comment it seems that jcarousel or jquery-flipster could be good candidates. Kyle, any ideas?
(In reply to Jonathan Druart from comment #21) > (In reply to Mason James from comment #20) > > (In reply to Jonathan Druart from comment #17) > > > (In reply to Marcel de Rooy from comment #13) > > > > On http://www.jacksasylum.eu/ContentFlow/ I only see changelogs until 2010? > > > > If there is no further development(?), this might be a risk. > > > > > > I can see that as blocker, Mason, would it be easy to update the plugin you > > > used? > > > > Jonathan, can you please suggest a replacement for ContentFlow, so I may > > proceed > > I have no idea, but reading the previous comment it seems that jcarousel or > jquery-flipster could be good candidates. > Kyle, any ideas? my humble opinion is that aesthetically flipster is a better choice for the style of this feature
The ByWater plugin actually can automatically update the covers used. It uses a public report, chosen in config, so updates whenever the cache expires. I would like to see this option remain as we have many users basing their reports on time or specific item types or collection codes, or pointing the report to a list they can individually and and remove titles from. More flexibility is often better :-) The coverflow plugin is currently tied to amazon covers and generates the links statically: <img src="http://images.amazon.com/images/P/[% d.isbn %].01.LZZZZZZZ.jpg" /> I would second the use of Flipster since it has a few different config options available (coverflow, carousel, flat)
(In reply to Nick Clemens from comment #23) > I would second the use of Flipster since it has a few different config > options available (coverflow, carousel, flat) To second here does mean first, not second choice? :)
(In reply to Marcel de Rooy from comment #24) > (In reply to Nick Clemens from comment #23) > > I would second the use of Flipster since it has a few different config > > options available (coverflow, carousel, flat) > > To second here does mean first, not second choice? :) Poor choice of English vocabulary in a global community :-) Yes, I support flipster as first choice
I would also recommend using Flipster. It's even touch aware and has multiple layout options. Honestly, I'd recommend you take a good look at the cover flow plugin ( https://github.com/bywatersolutions/koha-plugin-coverflow ) and steal heavily from it ; ) It provides a very efficient and flexible way to define the results you want, and allows for as many coverflows as you'd like. The results are based on reports, which are cached, and the javascript it generates is also cached. The only thing it's really lacking is a nice graphical editor. Right now all the setting are defined as a piece of hand written JSON.
(In reply to Nick Clemens from comment #23) > The ByWater plugin actually can automatically update the covers used. It > uses a public report, chosen in config, so updates whenever the cache > expires. hi Barton, that sounds positive. can you please provide the SQL for the public report, so i can test this further?
(In reply to Mason James from comment #27) > (In reply to Nick Clemens from comment #23) > > The ByWater plugin actually can automatically update the covers used. It > > uses a public report, chosen in config, so updates whenever the cache > > expires. > > hi Nick, that sounds positive. > > can you please provide the SQL for the public report, so i can test this > further? Pasting in the default report we use, but the plugin allows for use of any report the user saves in Koha through the reports module So we have used it to report froma public list, or only on specific item types, we even have a few libraries that manually restrict the report to biblios in the IN statement. Standard setup is this: SELECT b.biblionumber, SUBSTRING_INDEX(m.isbn, ' ', 1) AS isbn, b.title FROM items i LEFT JOIN biblioitems m USING (biblioitemnumber) LEFT JOIN biblio b ON (i.biblionumber=b.biblionumber) WHERE DATE_SUB(CURDATE(),INTERVAL 30 DAY) <= i.dateaccessioned AND m.isbn IS NOT NULL AND m.isbn != '' HAVING isbn != "" ORDER BY rand() LIMIT 7
If you need an example of some tweaks we've made, go to https://catalog.cin.bywatersolutions.com/. We limit the carousel to 20 items, but add links on a few to expand the search. We also used the tab layout for multiple groups, and have added an animated loading message that looks sharp. I love the fact that you can currently use reports or lists for this feature. Would love it if this would use any/all of the same cover resources setup in Koha, and not just Amazon covers.
On of my biggest concerns right now is lack of control over the width of the title. Some titles are huge, and spread the covers apart more. It would be great if there were a definable confined space for the title, which could include the ability to wrap, shrink to a minimum, etc.
Not much activity here in the last 4 years. Do we still want a carousel included with Koha, or should we focus on the CoverFlow and possibly other plugins?
Librarian using Coverflow here. We found it a little tricky to set up but once we had understood all the options (display type, limit how many covers to rotate through, max size for images, connection with automated SQL report for new titles) we have found it looks very nice, is responsive and maintenance free. I personally think that including brief description and where to find current documentation for this addon with the main Koha documentation (along with any others worth mentioning) would be more useful than effort to create a built-in version. However the description needs to be updated! The text here https://koha-community.org/manual/19.11/en/html/extending_koha.html seems to be the same as written in 2014. Something short and non-technical that points to Bywater's content, if that is permitted, would be more helpful.
I think it would be more productive to put energy behind enhancements of CoverFlow than to do something different. It seems like this bug is intended to reinvent the wheel. We have used the CoverFlow plugin for years, and it has been virtually trouble free.
(In reply to Christopher Brannon from comment #33) > I think it would be more productive to put energy behind enhancements of > CoverFlow than to do something different. It seems like this bug is > intended to reinvent the wheel. We have used the CoverFlow plugin for > years, and it has been virtually trouble free. I understand your point. But your remark is not correct. This report was already opened before there was actually code on the CoverFlow plugin (July 2014). So talking about the "intention to reinvent the wheel" is not appropriate imo. I would not oppose closing the report anyway.
(In reply to Marcel de Rooy from comment #34) > I understand your point. But your remark is not correct. This report was > already opened before there was actually code on the CoverFlow plugin (July > 2014). > So talking about the "intention to reinvent the wheel" is not appropriate > imo. > > I would not oppose closing the report anyway. Since I have no idea what the timeline was, I would say it is inaccurate, not inappropriate. However, since it was a precursor to CoverFlow, I would also agree that it would be appropriate to close this bug or mark it resolved.
I think CoverFlow has become a de facto standard for Koha. At this point, maybe Bywater would consider converting the plugin into a patch, but I don't see a problem leaving it as a plugin and just closing this report.
(In reply to David Cook from comment #36) > I think CoverFlow has become a de facto standard for Koha. > > At this point, maybe Bywater would consider converting the plugin into a > patch, but I don't see a problem leaving it as a plugin and just closing > this report. Yes, ByWater or anybody else. The ambition for a plugin that is widely used must be to integrate Koha core. I don't think we should close this bug report, but obsolete the patches and link to the plugin instead, in hope someone will be willing to port it to master.
(In reply to Jonathan Druart from comment #37) > Yes, ByWater or anybody else. > > The ambition for a plugin that is widely used must be to integrate Koha core. > > I don't think we should close this bug report, but obsolete the patches and > link to the plugin instead, in hope someone will be willing to port it to > master. That sounds reasonable to me too.
As suggested on comment#37 Plugins that could be used as a base for the new feature: https://github.com/bywatersolutions/koha-plugin-coverflow https://inlibro.com/en/carousel-instructions/
As part of the wishlist for when the carousel might be coded into the community version of Koha may I ask that the code deal well with keyboard navigation. We are testing functionality of the 21.11 Koha OPAC on our upgrade server with minimal customisations other than colours etc., and find that the keyboard navigation jumps from the links on the left hand side of the OPAC page into individual titles of records in the carousel, rather than into the carousel heading. This means repeated tabbing to move from the carousel to the next OPAC feature.