Self Check (web based) - Keep focus on scan input box in checkout screen

Bug #1560601 reported by Josh Stompro on 2016-03-22
18
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Evergreen
Medium
Unassigned

Bug Description

EG 2.8.4

The issue we are seeing is that if a customer presses the tab key the cursor focus will move on to the next element. This causes the next scan to have no effect, if the focus is on the print list button, a receipt gets printed in response to the newline after the scan. Once the print list button is removed, then a tab takes the focus to the home button, so a scan would reload the checkout screen, but would loose the barcode just scanned.

So we have customers that either hit the tab key or via the touch screen change the focus, then scan all their items without looking at the screen, and don't notice that they haven't checked out more than the first one or two items.

It would be nice if there is nothing that the user can accidentally do on the checkout screen that would cause their next scan to fail.

A possible solution would be to tightly control the focus of the scan box on the checkout screen, and disable the scan box for the other screens where other input may be wanted/needed.

Some googling brought me to this example that disables the tab index, and moves the focus back to the text box onblur. I don't know if this is the correct way to handle it, but it might be a start.
http://jsfiddle.net/QcSPB/10/

Thanks
Josh

description: updated

I'm been looking into this more, and have something that seems to work. We keep getting reports of people that think they have checked everything out, but have not. We have a problem with people never looking at the screen and thinking that the barcode scanner beep means that the checkout was successful. For some reason some scans are not registering with the self check, I'm assuming some of them are because the focus isn't in the scanbox, so I'm trying to get rid of at least that issue if possible.

The first fix is to register a onclick handler for the HTML element that returns focus to the scanbox any time anything is clicked. This keeps a random click/touch of the touch screen from sabotaging the next users first scan.

The next fix is to add an onkeyup handler that looks for a tab keypress, and returns the focus to the scanbox. This requires that there always be an extra element in the tabindex for the focus to move to first. If no other elements are available, the browser (firefox/openkiosk) will take the focus to the browser UI, which isn't possible to handle. So I added a <a>.</a> element hidden in the borders, So the scanbox will always have something to tab to.

I disable the tab hijacking for the payments page, so users can tab through the form there. I still need to work on re-enabling the tab hijack when you leave the payment page.

I added a bit that makes sure that the first field in the payments tab gets focus, so users can just start typing.

I don't have a branch ready to share yet, I want to do some more testing and try it out in production.

Josh

Branch at user/stompro/lp1560601-selfcheck-keep-focus

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/stompro/lp1560601-selfcheck-keep-focus

This has been working well for us for a few years. It makes the web based self check more fool proof since the focus will always move back to the scan box after an accidental click/touch or tab. The fix is disabled for the payments interface since that can make it harder to enter the CC info.

Josh

tags: added: pullrequest
Galen Charlton (gmc) on 2019-10-18
tags: added: ux
Changed in evergreen:
importance: Undecided → Medium
assignee: nobody → Galen Charlton (gmc)
Galen Charlton (gmc) wrote :

I've reviewed this patch, and it does the thing. However, after discussing it with Josh, he will send out a note asking folks who use web-based self-check at computers that have keyboards whether they have users that are reliant on the keyboard as the sole input source, as this patch has the effect of breaking keyboard navigation. If it turns out that this may be a problem for known users, perhaps the focus-keeping could be activated by a library setting.

Changed in evergreen:
assignee: Galen Charlton (gmc) → nobody
Terran McCanna (tmccanna) wrote :

Good catch, Galen. I didn't notice that it stopped users from being able to intentionally tab out of the field.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers