Hold And Multi-Tap Interaction

Goal

This recipe turns a normal command into a progress-based interaction. Use Hold when the user should press and hold. Use Multi-Tap when repeated presses should contribute inside a tap window.

Hold Command Setup

1. Start from a working instant command row.
2. Change the input pattern to Hold.
3. Set a positive hold duration.
4. Keep the input action Boolean so pressed/released phases are available.
5. Set prompt text that communicates progress, such as a template containing percent or remaining time tokens.
6. Add execution actions to the completion outcome, not to every progress update, unless the action is intentionally progress-based.

Multi-Tap Command Setup

1. Change the input pattern to Multi-Tap.
2. Set required tap count and tap window.
3. Use prompt text that communicates current count or required count if the UI should show it.
4. Test slow taps, fast taps, too few taps, and completion.

Widget Feedback

Widgets based on UInteractionUIWidgetBase should render progress updates separately from command availability. A hold bar, circular progress ring, or compact percent label should clear when focus changes, the command completes, or the command cancels.

Verification

• Holding reaches completion after the authored duration.
• Releasing early follows the command’s release behavior.
• Multi-Tap count resets or expires according to the tap window.
• Cooldowns or disables apply only after the configured outcome.
• UI progress disappears when focus leaves the target.

Release Behavior Decisions

Decide what happens when the user releases early. A reset behavior is clear for deliberate holds such as “Force Open.” A decay behavior works for effort-based tasks such as “Repair.” A pause-like presentation can work for routes where progress belongs to several participants. The widget should communicate the chosen behavior so users understand whether progress was lost or retained.

Failure Diagnosis

• Progress never starts: input action, command pattern, focus, or command row visibility is wrong.
• Progress starts but never completes: hold duration, release behavior, activation phase, or authority validation is wrong.
• Completion fires repeatedly: action trigger or repeated activation handling is too broad.
• UI bar stays after focus leaves: widget is not clearing progress on focus/surface change.

Authoring Variants For Hold State

If a hold command changes the object’s state after completion, consider a second variant for the completed state. The initial variant contains the hold command. The completed variant can remove the command, replace it with an unavailable prompt, or show a different command. Use a target variant override or execution action to switch variants on completion.

Input Timing Test

Test a quick tap, a half-duration hold, an exact-duration hold, a long hold, focus loss during hold, and repeated holds after completion. These cases reveal most pattern, release, cooldown, and UI progress mistakes.

Authoring Fields To Recheck

• Row kind is Command, not More marker.
• Activation mode is interactive unless the command is intentionally automatic.
• Input pattern is Hold or Multi-Tap.
• Hold duration or tap window is positive.
• Input action is a Boolean button-style action.
• Prompt text communicates the required action.
• Execution actions are attached to completion or the intended outcome.

Runtime Checkpoints

During play, confirm focus first, then prompt row, then input phase, then progress, then completion, then execution action. If progress does not start, do not debug the action yet. If progress completes but state does not change, then debug the action and authority path.

UI Review Questions

Can the player tell when progress is starting, continuing, cancelled, complete, or blocked by cooldown? If not, improve prompt provider text and widget progress handling before shipping the command.