Choose a barcode handheld for gloved work by checking the complete input sequence in the intended application. A successful scan leaves important questions unanswered: can the worker select the quantity, replace it, correct a mistake, choose an exception and confirm the displayed result while wearing the required gloves?
The useful purchasing evidence is a recorded combination of glove, device, input configuration and application behavior. It should show which steps work as intended, which need adjustment and what remains unverified before a configuration is selected.
Start with the work after the scan
Consider a receiving task in which a worker scans a carton and the application supplies a quantity. The actual count differs, so the worker must replace that quantity, correct one entry, select a receiving exception, review the values and use the assigned confirmation action. The next item must then begin with the intended input mode and field selected.
This is an editorial illustration, not a customer case or an AIDC GO test. Assume the barcode decodes correctly, its data is parsed correctly and the network is working. Perform the exercise with authorized sample records in a test environment, at a work position permitted by site procedures. Keep required protective equipment in use.
Specify the characters and actions that this task actually needs. A whole-number quantity, a decimal quantity and a reason selected from a list create different input requirements. Include only those relevant to the planned workflow.
If the device class is still undecided, first consider whether the work calls for a rugged handheld or rugged tablet. The exercise here helps evaluate an input configuration within the chosen direction.
Record the glove and device combination
“Tested with gloves” leaves too much unspecified. Record the glove manufacturer, product and size, together with its approved usage condition. Also identify the device model, keypad version where applicable, firmware, application build and approved screen protector or other relevant accessory.
Include the permitted grip and work position. If the proposed workflow depends on one-handed input, observe that arrangement where site procedures allow it. Record when the worker changes grip or needs the other hand; do not hide those changes in a general statement that the task was completed.
Touch settings also require model-specific evidence. Zebra's Touch Manager documentation, for example, describes sensitivity options and screen-protector settings that depend on the supported device or platform. This illustrates why a setting must be checked against the exact equipment; it does not establish that another manufacturer's device has the same options. Zebra Touch Manager
Ask the supplier to confirm the documented touch settings and supported accessory combination for the proposed unit. Record the setting actually used. Neither an Android operating system nor a general mention of glove input establishes compatibility with the customer's particular glove.
Separate touch response, target selection and field focus
When an input step fails, record what happened before assigning a cause. Three observations lead to different follow-up questions.
No intended response appears. A tap produces no visible change. That observation alone does not prove that the touch panel failed to detect it. The supplier and application team may need to distinguish unsupported touch conditions, input delivery and application handling.
The wrong control responds. A nearby button activates, or the worker repeatedly misses a field. Inspect the effective touch area and neighboring controls in the actual screen, including any changes when the keyboard opens. A large display does not by itself establish that the required controls are easy to select.
Android's guidance for applications using Views recommends touch targets of at least 48dp by 48dp and explains that padding can make the touch area larger than the visible icon. Here, dp means density-independent pixels. This is accessibility guidance, not a glove compatibility certification or a sufficient acceptance criterion for this receiving task. Android accessibility guidance
Input reaches the wrong field. The worker enters the expected characters, but another field changes. Observe which field has focus—the field currently selected to receive input—and whether focus changes after a scan, correction or exception selection. The application team should investigate the input path appropriate to its framework.
These are diagnostic starting points. Keep the observed result separate from an unverified explanation such as “the gloves are too thick” or “the screen is too small.”
Check the physical keys in the intended application
For a keypad candidate, inspect the exact layout and version offered. Verify how the worker enters the required characters, changes input modes, deletes a character, moves between fields and performs the assigned confirmation. Include any touch interaction still needed to select an exception or review the result.
Key legends alone cannot establish application behavior. Zebra's MC34 guide, for example, describes numeric, alphabetic and function modes on its 29-key keypad and notes that applications can change keypad functions. Those details belong to that documented configuration; they are not mappings for an AIDC GO device. Zebra MC34 keypad guide
Ask the application owner what Enter, Backspace and navigation keys do on each relevant screen. Do not presume that Enter submits a receipt or that a proposed keypad supports remapping.
Android's keyboard documentation also distinguishes hardware key events from soft keyboard input. Applications should not rely on an on-screen keyboard producing the same key events, and holding a hardware key can generate repeated key-down callbacks. The practical implication is to observe the actual input path and application response when testing corrections. Android keyboard actions
Observe a normal press and, where relevant, a sustained press in the sample exercise. Record the resulting text or action. A repeated character is an input observation; it does not establish that the WMS created duplicate receipts. Likewise, a key response or vibration does not by itself establish final business acceptance.
Use a short exercise to support the configuration decision
Use the same receiving sequence with representative operators wearing the required gloves. Agree beforehand on the intended result at each step and which issues would prevent selection. Keep the application and other conditions consistent when comparing candidates, and record differences that cannot be held constant.
The following is a proposed observation sheet, not a record of completed testing. Copy it into the evaluation record and add the observed result and follow-up owner for each action.
| Required action | What to observe with the required glove and configuration | What the observation should inform |
|---|---|---|
| Select the quantity | Does the intended field show that it is selected? Record missed attempts and activation of adjacent controls. | Investigate touch conditions, effective target area or focus behavior, according to the evidence. |
| Replace the quantity | Can the worker enter every required character? Note input-mode changes and any information covered by the soft keyboard. | Check the proposed keypad version, input method and application layout. |
| Correct one entry | Record the result of a single press and a relevant sustained press. Note unintended deletion, a neighboring key or a different field changing. | Review key layout and application handling of corrections. |
| Choose an exception | Observe scrolling, opening the selection control and the selected reason remaining visible. Record grip changes. | Decide whether the application needs adjustment or the input configuration needs reevaluation. |
| Review and confirm | Can the worker read the corrected quantity and reason, use the assigned action and identify the resulting message? | Have the application owner define what that feedback confirms and what permits the next action. |
| Resume the next item | Check the starting field, input mode and whether the previous reason or quantity persists as intended. | Record the required starting state and recheck it after relevant changes. |
Capture the extra attempts, corrections, unintended selections, mode changes and grip changes that explain a result. Completion time can be recorded when useful, but a fast attempt with the wrong final quantity does not meet the intended task result. The project must set its own criteria; this article supplies no universal time or accuracy threshold.
Change one suspected factor at a time where practical. If a documented setting or interface adjustment resolves a problem, repeat the full sequence with that change recorded. Continue through the next item, where a leftover mode or selection may become visible.
The exercise should support one of three decisions: retain the candidate for the broader pilot under recorded conditions; adjust a documented configuration or application behavior and retest; or hold selection because the evidence is incomplete. A pass here covers these input steps. Use the findings when you plan a representative device pilot for the wider workflow.
Bring the observed input steps to hardware evaluation
Use the handheld terminal range to discuss candidate input directions. The HX-24 provides a touchscreen handheld direction, while the HX-27 provides a keypad handheld direction with the keypad configuration dependent on version. These descriptions help frame the hardware discussion. They do not establish which candidate will work with a particular glove and application.
Prepare the glove identification, approved usage conditions, required characters and actions, permitted grip and the exact step causing difficulty. Include the proposed device and keypad version, screen protector, firmware and application build where known. A sanitized screen image or short action description can help explain the issue without exposing customer records.
AIDC GO can help clarify the hardware direction, configuration questions and sample evaluation needs through integration and support. The customer and its application partner define screen behavior, key handling, business confirmation and acceptance criteria. Record who will investigate each unresolved observation before the next evaluation.
To discuss your application, describe what the worker must select, enter, correct and confirm after the scan, along with the glove and configuration involved. That gives the hardware discussion a concrete task to evaluate.