Bug 2534 - Viewing items table on item edit screen requires horizontal scrolling
Summary: Viewing items table on item edit screen requires horizontal scrolling
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: master
Hardware: All All
: PATCH-Sent (DO NOT USE) normal (vote)
Assignee: Owen Leonard
QA Contact:
URL: /cgi-bin/koha/cataloguing/additem.pl
Keywords:
Depends on:
Blocks:
 
Reported: 2008-08-19 06:54 UTC by Chris Cormack
Modified: 2013-12-05 20:01 UTC (History)
4 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Who signed the patch off:
Text to go in the release notes:
Version(s) released in:


Attachments
Screenshot of FF on Win32 (132.15 KB, image/png)
2008-08-19 07:48 UTC, Chris Cormack
Details
Proposed change to additem interface. (28.78 KB, image/gif)
2008-09-25 06:25 UTC, Chris Cormack
Details
Proposed change (3.98 KB, patch)
2010-01-07 16:10 UTC, Chris Cormack
Details | Diff | Splinter Review
Screenshot showing inline edit/delete menu (10.97 KB, image/png)
2010-01-07 16:12 UTC, Chris Cormack
Details
Proposed fix follow-up fix (3.96 KB, patch)
2011-08-22 15:43 UTC, Owen Leonard
Details | Diff | Splinter Review
Proposed alternate fix (4.11 KB, patch)
2011-08-30 15:28 UTC, Owen Leonard
Details | Diff | Splinter Review
Screenshot of alternate layout change (74.90 KB, image/png)
2011-08-30 15:30 UTC, Owen Leonard
Details
[Signed Off] Alternate fix for Bug 2534 - Viewing items table on item edit screen requires horizontal scrolling (4.23 KB, patch)
2011-08-30 15:52 UTC, Liz Rea
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Cormack 2010-05-21 00:52:17 UTC


---- Reported by joe.atzberger@liblime.com 2008-08-19 06:54:00 ----

Client reports (complete with screenshot) that the addition of new column "Source of classification or shelving scheme" forces the table to be truncated on the right side (including part of the  "Date last borrowed" column).



---- Additional Comments From joe.atzberger@liblime.com 2008-08-19 07:48:35 ----

Created an attachment
Screenshot of FF on Win32





---- Additional Comments From oleonard@myacpl.org 2008-08-19 08:06:59 ----

The only solution here I can see is to reduce the number of columns in the table. Removing the left-hand sidebar would mitigate the problem, but every time I think we've got enough room someone shows me a table with even more columns.

The other thing I think we should do is eliminate the "overflow:scroll" from the items list table. As in the screenshot example, if you have a list that pushes the scrollbar down below the bottom of the viewport, you can't scroll to the end of the table at the same time you're looking at the top of the list.

Better to have the whole page show a horizontal scrollbar than not be able to see part of the holdings table.



---- Additional Comments From gmcharlt@gmail.com 2008-08-19 08:13:44 ----

I prefer limiting the columns to a set list, perhaps:

itemnumber
barcode
location (perhaps combine holdingbranch, location, ccode in one column?)
call number
enum/chron

I think the point of this list should be to allow the cataloger to identify which item to edit, not to dump every populated column into the table.

In order to avoid endless debates about exactly which columns to include, and if at all possible to avoid yet another display syspref, we could consider adding a "view details" link to each row that when clicked would display everything in a div floating over the page.



---- Additional Comments From henridamien@koha-fr.org 2008-08-20 07:06:26 ----

Iirc, they already have the choice of the information they display.
They can manage information and with hiding it.

Problem is that the more information you have in base the more they want to get on the same screen.
(Some wants the previous borrower, the location this and that way, the same status on all the pages, and also editable list of statuses reshelving, damaged, reliure, onshelf, ....) And this would be require a good common and flexible API to display an item, and a list of item that could be used in any place an item is displayed.

Maybe short term solution would be to display an item on more than one line.

my 2 cts.



---- Additional Comments From oleonard@myacpl.org 2008-09-25 06:25:38 ----

Created an attachment
Proposed change to additem interface.

I suggest 2 steps which can be taken immediately: First, take out the left-hand menu and replace it with a horizontal menu below the breadcrumb menu. Second, remove the overflow property from the table of item information. Having up to three scrollbars for the page is too much. Better to have a horizontal scrollbar for the whole page is better than having to deal with trying to manage the scrolling of just the items table.



---- Additional Comments From nengard@gmail.com 2009-12-23 17:59:25 ----

This bug hasn't been touched in nearly a year, please revisit and test and close if appropriate.



---- Additional Comments From oleonard@myacpl.org 2009-12-28 15:05:54 ----

My suggestion about changes to the page layout still stand. I also propose this addition: http://www.myacpl.org/koha/examples/additem-2009-07-20.html



---- Additional Comments From oleonard@myacpl.org 2010-01-07 16:10:35 ----

Created an attachment
Proposed change

This patch implements the inline add/edit screen as described in my blog post linked above.



---- Additional Comments From oleonard@myacpl.org 2010-01-07 16:12:10 ----

Created an attachment
Screenshot showing inline edit/delete menu

Clicking anywhere in a table row will bring up the edit/delete links. This means that even if you scrolled the table all the way to the right you can still access the edit/delete function without having to scroll all the way back.



---- Additional Comments From oleonard@myacpl.org 2010-01-27 20:20:03 ----

My patch for inline edit/delete links has been pushed to HEAD.



--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 00:52 UTC  ---

This bug was previously known as _bug_ 2534 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=2534
Imported an attachment (id=715)
Imported an attachment (id=716)
Imported an attachment (id=717)
Imported an attachment (id=718)

Actual time not defined. Setting to 0.0
The original reporter of this bug does not have
   an account here. Reassigning to the person who moved
   it here: chris@bigballofwax.co.nz.
   Previous reporter was joe.atzberger@liblime.com.
The original submitter of attachment 715 [details] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.
The original submitter of attachment 716 [details] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.
The original submitter of attachment 717 [details] [review] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.
The original submitter of attachment 718 [details] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.

Comment 1 Owen Leonard 2011-08-22 15:43:14 UTC Comment hidden (obsolete)
Comment 2 Liz Rea 2011-08-30 15:01:35 UTC
owen,
I like what you've done here -- getting rid of the horizontal scroll on the table is very nice.

I have one small suggestion, however: 

I wonder if you could put the sidebar back, but below the table, so that when the table is full width, horizontal scrolling cuts off the sidebar instead of the labels for the item inputs. That way they could be scrolled over, but still see to put in items. That would also keep the interface slightly more consistent (though I'm not sure it really matters).
Comment 3 Owen Leonard 2011-08-30 15:28:53 UTC Comment hidden (obsolete)
Comment 4 Owen Leonard 2011-08-30 15:30:16 UTC
Created attachment 5223 [details]
Screenshot of alternate layout change
Comment 5 Liz Rea 2011-08-30 15:52:20 UTC
Created attachment 5224 [details] [review]
[Signed Off] Alternate fix for Bug 2534 - Viewing items table on item edit screen requires horizontal scrolling

This patch doesn't eliminate horizontal scrolling, but simplifies
the situation:

- The left-hand sidebar has been moved below the table of items.
- The "overflow:scroll" style has been removed from the table of items.
  Having overflow set meant that it was often necessary to scroll twice
  to reach data in the table: once using the scrollbars on the table
  and again using the page's scrollbars.

The NEKLS catalogers also extend their thanks for this fix.

Signed-off-by: Liz Rea <lrea@nekls.org>
Comment 6 Ian Walls 2011-09-22 17:41:14 UTC
Template and CSS change only, easy to read, marking as Passed QA
Comment 7 Chris Cormack 2011-09-22 18:22:16 UTC
Pushed, please test