Touchscreen HMI keyboard design for reliable operator input

Size touch targets on the installed screen

A touch target is the area that accepts a tap. Its usability depends on physical size, spacing, reach and the touchscreen's response, not just the size of the icon drawn inside it.

There is no single button dimension that suits every industrial installation. Glove use, mounting angle, touch technology and the consequences of an adjacent selection all affect the design. Check that the touchscreen supports the intended gloves before treating larger controls as the solution.

For a browser-based HMI, distinguish the panel's native resolution from the application's viewport in logical pixels. Operating-system scaling and browser zoom can change their relationship. For a view filling the active screen width:

Physical target width = target width in logical pixels × active screen width ÷ viewport width in logical pixels.

Use matching units for the two pixel measurements. Do not substitute native panel resolution for viewport width unless they actually match. If the browser's rendering area is uncertain, resolve the kiosk browser sizing before tuning individual controls.

Measure the rendered target on the installed panel. Check taps near its edges as well as at its center. Leave clear space between neighboring actions, especially where the wrong selection could change an operating value. Enlarged invisible hit areas must not overlap or make the visible boundary misleading.

Keep navigation and overlays predictable

Place common navigation in a consistent location across views. A bottom dock can work well when it matches the mounting height and reach, but it is not automatically better than side navigation. A hand reaching across the bottom may obscure information that matters during entry.

Reserve keyboard space deliberately. When it opens, the active field, its label, units and acceptance controls should remain visible. Decide whether the keyboard reduces the content area or overlays it. An overlay that covers the destination makes it harder to notice entry into the wrong field.

Use popups for short contextual tasks rather than as a substitute for every view. Percentage-based width helps accommodate different viewports, but a popup can still be too tall. Check it with the keyboard open and with longer labels or validation messages.

Avoid shrinking a process diagram until its controls become ambiguous. Use a task-focused detail view or intentional pan and zoom. Likewise, do not assume a vertical slider will behave well: dragging can conflict with page scrolling. For an exact numeric value, a field with explicit acceptance is often easier to control.

Choose who owns the keyboard

An operating-system keyboard and an application keyboard solve the same entry problem at different layers. Choose based on the deployed client environment and the amount of behavior the application needs to control.

A text field can receive focus without a desktop operating system displaying its touch keyboard. Confirm that behavior in the actual browser, account and kiosk configuration. A development computer's behavior is not a substitute for the deployed panel.

An application dock gives the project control over its layout and visible keys. That is useful for numeric values with signs or decimal places. A full text keyboard requires more work, including case changes, cursor editing and any required language support.

Do not make launching an operating-system executable the default design. Where a platform documents that integration, it still depends on the correct client host, account permissions and installation path. A process started on a remote application host will not necessarily present a keyboard on the touchscreen.

Give each edit an explicit target and buffer

The keyboard must know which field it is editing. Screen coordinates and the last visible selection are not reliable destination identifiers.

Keep edit state local to the touchscreen session. It should identify the destination, its label and units, the original value, the editable buffer and the rules that apply. A reusable dock should receive this information when the field is activated.

Treat editing as a distinct state rather than writing every key directly to the process:

• Open: identify the destination and load its current value into a temporary buffer.
• Edit: change the buffer while keeping the destination visible.
• Accept: validate the complete entry and request the permitted write.
• Cancel: discard the buffer without changing the destination.
• Close: clear the active edit target so later key events cannot reuse it.

If another field is selected during an unfinished edit, define what happens. Either require the current edit to be accepted or canceled, or explicitly discard it before loading the next destination. Do not silently carry the old buffer into the new field.

Define Enter and focus-loss behavior too. Closing a keyboard, tapping outside a field or navigating away should not accidentally become an acceptance action. Keep one clear commit action so a touch gesture and a generated click cannot submit the same entry twice.

Validate the complete value before writing

Restricting the available keys helps prevent mistakes, but it is not sufficient validation. A numeric keypad can still produce an empty value, an incomplete minus sign or a number outside the allowed range.

Validation should cover the destination's data type, units, permitted range, decimal precision and text length where applicable. Take these rules from the application and controller design. Do not invent a convenient display limit that conflicts with the actual destination.

Show the reason for rejection beside the field or keyboard. Keep the entered buffer available for correction rather than clearing it without explanation. For values whose meaning depends on units, show those units during editing and confirmation.

Check authorization at the write boundary, not only by hiding a button. Controller-side limits and operating permissives remain authoritative. An HMI field or custom keyboard is not a substitute for protective functions.

Distinguish a local edit from a completed write. The interface should show when a value is pending, rejected or confirmed through the application's defined acknowledgement or readback. If the current value changes while an edit is open, handle that conflict explicitly rather than silently overwriting a newer value.

Separate touch, keyboard and write faults

Troubleshooting is easier when each stage has a visible result. Use the symptom to choose the next check:

• A tap produces no visible response: inspect the hit area, enabled state, overlays and the interaction events supported by the deployed client.
• The field shows focus but no keyboard appears: inspect operating-system input settings or the application's keyboard-opening action.
• The keyboard edits the wrong field: inspect the destination passed into the dock and whether old session state was cleared.
• The buffer changes but acceptance is rejected: inspect parsing, range checks, permissions and the commit action.
• The value changes locally but not at the destination: inspect the binding direction, write result and communications path.

A changed display value is not proof that a controller accepted it. Likewise, an accepted controller value is not proof that equipment should act on it; operating logic and permissives still apply.

Check the complete interaction on the installed panel

Review the interface from its normal operating position, using the intended input method. A mouse-only review misses finger occlusion, reach problems and controls that are too close together.

Include these conditions in the acceptance checks:

• Every target can be selected without activating its neighbor.
• Navigation, field labels and acceptance controls remain visible with the keyboard open.
• Sign, decimal entry, deletion, Cancel and Accept behave consistently.
• Invalid input produces a useful message and leaves the process value unchanged.
• Rapid field changes do not retain the wrong destination or duplicate a write.
• Navigation, session expiry and reconnection clear or explicitly reconcile unfinished edits.
• The displayed result distinguishes an edit buffer from the confirmed destination value.

Keep this work within the machine's normal authorization and commissioning procedures. Use an approved test environment where interaction checks could otherwise affect equipment.

These requirements belong to the control interface. If the requirement is only to present notices or production information, the distinction between a factory status display and an operator HMI helps avoid specifying an interactive control system for a read-only job.

Questions