Bug 11325 - Focus on "Add item" in Lists
Summary: Focus on "Add item" in Lists
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Lists (show other bugs)
Version: master
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Samuel Crosby
QA Contact: Testopia
URL:
Keywords:
: 14663 17280 (view as bug list)
Depends on:
Blocks: 16897
  Show dependency treegraph
 
Reported: 2013-11-30 23:08 UTC by Ian Palko
Modified: 2016-09-09 12:14 UTC (History)
10 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Trivial patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Moved add barcode to be focus (48.20 KB, patch)
2014-01-06 05:08 UTC, Samuel Crosby
Details | Diff | Splinter Review
Bug 11325 - Focus not on "Add Item" in Lists (3.49 KB, patch)
2015-06-17 11:25 UTC, Fridolin Somers
Details | Diff | Splinter Review
[SIGNED-OFF] Bug 11325: Focus not on "Add Item" in Lists (3.63 KB, patch)
2015-06-19 17:51 UTC, Bernardo Gonzalez Kriegel
Details | Diff | Splinter Review
Bug 11325: Focus not on "Add Item" in Lists (3.68 KB, patch)
2015-06-22 13:57 UTC, Jonathan Druart
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Ian Palko 2013-11-30 23:08:49 UTC
When viewing a list, the focus/cursor is no longer on the "add items" field below the list.

Previously a user could simply scan or enter barcode numbers to add multiple items. Now a user must manually focus on this field for each added item, slowing list creation.
Comment 1 Samuel Crosby 2014-01-06 05:08:45 UTC Comment hidden (obsolete)
Comment 2 Owen Leonard 2014-01-14 14:18:36 UTC
I like the idea that we might place focus on the input field if the page is being redisplayed after a barcode was entered. If we did might even add an "Add item" link to the page which lists existing shelves.

I don't think this patch is the correct solution, and anyway it inadvertently adds a couple of patch files which we don't want.
Comment 3 Ian Palko 2014-01-17 15:34:43 UTC
I'll second Owen's comment.

Permit me to expand my explanation.

Before 3.14 when one loaded this shelves.pl page for a certain list, the focus (cursor) went to the "add items" barcode field.

To create a list, one would then just scan (or type in) an item barcode. The page would then reload with the new item in the list. Adding another item was a simple as scanning yet another barcode. Quick list creation (especially for merging items!)

Now, the focus does not go to any field. To create a list now, I have place the cursor in the barcode field (or tab to it), scan the item. Then to add a second item, scroll down, again place the cursor, scan.

I list of ten items used to require ten scans. Now it requires ten scans, plus ten mouse movements and clicks, plus scrolling as the list gets longer.

The solution does not seem to be to move the location of the "add item" field, but to make the focus on the page load on that barcode field. That would restore the earlier functionality.
Comment 4 Ian Palko 2014-01-25 02:01:32 UTC
In 3.14.01 the bug is even worse ...

Now, the focus is not by default on the "add barcode" field, but when data is entered into this field, whether by scanner or keyboard, focus is immediately sent to the "search the catalog" field at the top of the page.

This makes it impossible to create lists except by searching for the item in the catalog and adding it to the list from the biblio details.

Perhaps our library just disproportionately affected because of needing to clean up an imported database with lots of records needing to be merged, but it seems that whatever patches were applied between 3.12 and 3.14.01 have effectively broken this part of the list feature. 

That doesn't seem to me to be a "low minor bug". A seriously broken feature doesn't seem minor, or low priority.
Comment 5 Ian Palko 2014-01-25 02:39:53 UTC
If it helps, I've done some playing around to try to contribute more than just complaints. I think I know why the bug is happening and have a few ways to try to solve it, but have no idea how to patch things or use git, etc.

Here goes:

The focus problem is because shelves.tt calls [% INCLUDE 'cat-search.inc' %]. This include gives #findborrower the class "focus". jQuery then assigns the focus to this field which is hidden on this page by default. The catalog search is visible by default.

I fixed the jumpy cursor by editing shelves.tt and adding 'class="focus"'. This does not give it focus, #findborrower still steals it, but at least now data can be entered.

It seems that having the include give focus to #findborrower is a bad way of defaulting. Rather each tt should independently give focus to the proper element for this page.

Thus, the solution seems to be to edit cat-search.inc, removing focus from #findborrower, then on each tt page assign focus to the appropriate field.

Another default is to throw some javascript in that steals focus back to the field we would want.
Comment 6 Owen Leonard 2014-01-27 14:09:27 UTC
(In reply to Ian Palko from comment #4)
> Now, the focus is not by default on the "add barcode" field, but when data
> is entered into this field, whether by scanner or keyboard, focus is
> immediately sent to the "search the catalog" field at the top of the page.

This sounds like Bug 11567. Are you using a non-English translation which needs to be updated?
Comment 7 Ian Palko 2014-02-11 20:45:15 UTC
(In reply to Owen Leonard from comment #6)
> (In reply to Ian Palko from comment #4)
> > Now, the focus is not by default on the "add barcode" field, but when data
> > is entered into this field, whether by scanner or keyboard, focus is
> > immediately sent to the "search the catalog" field at the top of the page.
> 
> This sounds like Bug 11567. Are you using a non-English translation which
> needs to be updated?

In fact, no. 

We've used the main English koha without any translation since 3.6. I've never run or needed to run koha-translate.
Comment 8 Fridolin Somers 2014-06-24 14:47:54 UTC
Be carefull your patch adds a backup file :
/koha-tmpl/intranet-tmpl/prog/en/modules/virtualshelves/shelves.tt~
Comment 9 Fridolin Somers 2015-06-17 11:25:29 UTC Comment hidden (obsolete)
Comment 10 Fridolin Somers 2015-06-17 11:26:39 UTC
I propose another patch, nearlyby :

It moves the "Add Item" form at left part of page so that it is always shown (usefull when there are a lot of items).
And adds focus to barcode input so you can enter several items with a barcode scanner.
Comment 11 Fridolin Somers 2015-06-17 11:27:32 UTC
It set this as enhancement, I think its not a bug.
Comment 12 Bernardo Gonzalez Kriegel 2015-06-19 17:50:36 UTC
Comment on attachment 23921 [details] [review]
Moved add barcode to be focus

First patch obsoleted, is malformed and think Fridolin solution es simpler an elegant.
Comment 13 Bernardo Gonzalez Kriegel 2015-06-19 17:51:11 UTC Comment hidden (obsolete)
Comment 14 Jonathan Druart 2015-06-22 13:57:49 UTC
Created attachment 40475 [details] [review]
Bug 11325: Focus not on "Add Item" in Lists

When viewing a list, the focus/cursor is no longer on the "add items" field below the list.

This patch moves the "Add Item" form at left part of page so that it is always shown (usefull when there are a lot of items). And adds focus to barcode input so you can enter several items with a barcode scanner.

Test instructions:
1. Create a list
2. Make sure you have an object with an assigned barcode
3. Go to the list
=> The barcode entry interface should be at left and has the focus
4. Enter the barcode and press enter (or use a scanner)
=> The item is added to the list

Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
I like the new position.
Works well, focus on input box
No errors

Signed-off-by: Jonathan Druart <jonathan.druart@koha-community.org>
Comment 15 Nick Clemens 2015-08-07 22:08:41 UTC
*** Bug 14663 has been marked as a duplicate of this bug. ***
Comment 16 Tomás Cohen Arazi 2015-08-11 18:16:54 UTC
Patch pushed to master.

Good one Frido!
Comment 17 Owen Leonard 2016-09-09 12:14:24 UTC
*** Bug 17280 has been marked as a duplicate of this bug. ***