http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2713 Summary: Opac detail content overlaps when right column extends too far Product: Koha Version: HEAD Platform: All URL: http://nekls.test.kohalibrary.com/cgi-bin/koha/opac- detail.pl?biblionumber=41489 OS/Version: All Status: NEW Severity: normal Priority: P3 Component: Templates AssignedTo: oleonard@myacpl.org ReportedBy: oleonard@myacpl.org QAContact: koha-bugs@lists.koha.org If the holdings table is too wide and the right column too long there is a collision of objects on the page making it unreadable. The effect may only be noticeable below a certain browser width, about 1300x1000, but most users will have a small browser window. [10:35] <owen> I wanted to bring you and anyone else here into a discussion of a layout problem we have with opac-detail [10:35] <owen> http://fsc.kohalibrary.com/cgi-bin/koha/opac-detail.pl?biblionumber=114661 [10:35] <owen> http://nekls.test.kohalibrary.com/cgi-bin/koha/opac-detail.pl?biblionumber=4... [10:36] <owen> If the right-hand sidebar extends down too far, and the holdings table is too wide, we get a collision [10:38] <danny> oh I see it, I didn't see it before because my resolution is too wide [10:40] <gmcharlt> I think moving from a table to an arrangement where each item is described on two lines would keep the holdings table from getting too wide [10:40] <gmcharlt> something like location collection, and call number of the first line [10:41] <gmcharlt> volume and status information on the second [10:45] <owen> Here's an alternative solution: [10:45] <owen> http://zivotdesign.com/examples/opac-detail-fsc.html [10:45] <owen> http://zivotdesign.com/examples/opac-detail-nekls.html [10:46] <owen> And I know there are problems with the table sorting with large sets, but I'd hate to lose the ability to do sorting [10:48] <gmcharlt> yes, but it must be possible to page through long item lists first [10:50] <danny> personally i like how the alternative solution looks owen [10:50] <gmcharlt> re the proposed redesigns, I can see getting rid of the left column [10:51] <gmcharlt> I think save record should go back up with the other actions [10:51] <danny> good idea of moving them to the bottom [10:51] <gmcharlt> my concern, though is that the other search links will effectively disappear from the patron's POV by being pushed to the bottom [10:52] <owen> gmcharlt: maybe so. I'm used to dealing with records with a small number of items. [10:52] <danny> that left column is prime real estate and should meet the needs of what a majority of users are looking for [10:52] <gmcharlt> but of course, question is what set of users [10:53] <gmcharlt> for example, academic users are more likely to use the save record link [10:53] <gmcharlt> and I see no particular reason to put it down on the bottom [10:53] <gmcharlt> for the other search links, maybe adding it to the top right-hand box [10:53] <danny> good point, I can only come at it from the eyes of a public library [10:53] <gmcharlt> but just as a link that creates a floating panel of the specific links [10:54] <gmcharlt> would keep the action box at a finite size [10:54] <gmcharlt> no matter how many additional search links are configured [10:54] <gmcharlt> while still making it reasonably visibl [10:55] <danny> you are thinking like to add an anchor that would then pop you to the bottom of the page? [10:55] <danny> or do I misunderstand [10:55] <gmcharlt> no [10:55] <owen> If we 1) took out OpacNav on the detail page and 2) convert the save and search options to single links, that might be enough [10:56] <gmcharlt> an anchor that would open a layer over the bib details with the set of seach links ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.