Choices without hover: show touchscreen players the costs before they commit

If an option’s resource costs, time requirements, or known restrictions appear only on mouse hover, touchscreen players lack the information they need to make an informed decision. Start the revision by placing known costs that could change the player’s choice beside the option. Supplementary explanations can open with a tap. An optional confirmation summary lets players check their current decision; it must not be the first place where important conditions are disclosed.

To decide whether information should remain visible, ask: could knowing this sentence make the player choose another option? If so, it should not be hidden in a collapsed section or behind an unmarked gesture. For example, “uses your only pass” is a condition that affects the decision. Who issued the pass and why it is valid can stay in the details only if that information does not affect the current choice.

Also distinguish three actions: viewing, selecting, and committing. Tapping “View costs” only expands the text; tapping an option can mark it as the current selection; tapping an explicit commit button advances the story. If a game commits to an option as soon as it is tapped, the control for opening its explanation must be clearly separate from the commit area. A tap intended to open an explanation must not also commit to a choice.

This article uses a fictional teaching example, Last Boat from Fog Harbor. Its characters, numbers, and interactions were created to illustrate the issues. They are not a real user case or measured test results, and they do not represent existing DramaFork product features.

List the known conditions for each option before assigning display locations. Do not start by cutting text to fit a word count, or you may remove a decisive restriction.

During review, ask again: “Would removing this change the decision?” If yes, move the information back to the always-visible layer, including uncertainty that could affect the decision. Conditions governing when an option applies cannot all be collapsed: conditions that determine whether it is available or how much it costs must remain visible. Only supplementary explanations that do not affect the choice can go in expandable details. Details are not a storage box for important information, and a summary cannot repair a failure to disclose it earlier.

The three approaches can be combined, but they serve different purposes. Always-visible essentials make options easier to compare at the cost of page height. Expandable details accommodate longer explanations at the cost of an extra viewing step. Confirmation summaries suit actions that are hard to undo or easy to trigger accidentally, at the cost of interrupting the pace.

For just two short options, visible conditions and an explicit commit action may be enough. If four options each have several conditions, first standardize the information order so players can compare the same aspects, then add access to supplementary details. Do not put a confirmation dialog on every ordinary line of dialogue.

In the example, Lin Yao has two boat tickets and a document to deliver, with fifteen minutes left before departure. She can ask the boatman to deliver the document immediately or stay at the dock to wait for her companion. The teaching scenario specifies that delivery uses all her tickets, leaving her unable to take a passenger boat that evening. Waiting uses no tickets but means missing this delivery boat. The consequences after the document arrives have not yet been revealed.

The original draft shows only “Ask the boatman to deliver the document” and “Wait for your companion to return,” with costs hidden in hover text. The first revision reads:

• Ask the boatman to deliver the document: uses two boat tickets; you cannot take a passenger boat this evening. Add “View delivery conditions” beside it.
• Wait for your companion to return: uses no boat tickets; you miss this delivery boat. Add “View waiting conditions” beside it.

Expanding the delivery conditions reveals: “The boatman takes both boat tickets as payment. Once handed over, the document cannot be retrieved; the recipient’s response is unknown.” This exposes an omission in the first revision: being unable to retrieve the document could affect the choice, so it cannot remain only in the expanded section. The final always-visible text should read: “Ask the boatman to deliver the document: uses two boat tickets; you cannot take a passenger boat this evening; the document cannot be retrieved once handed over.” The details should only add explanations about the handover that do not affect the choice.

After reading, the player collapses the details, selects delivery, and proceeds to the summary used in this example: “Hand over the document and spend two boat tickets, leaving zero; you cannot take a passenger boat this evening, and the document cannot be retrieved.” Label the actions “Return to choices” and “Confirm delivery,” avoiding a vague label such as “OK.”

The key outcome of this teaching walkthrough is the omitted condition it uncovered. The summary checks information already disclosed; it must not suddenly introduce a loss at the final step. Keeping the option selected when the player returns lets them compare again.

The first failure is replacing hover with a long press without providing a visible control. Players still do not know where explanations are available, and they may interpret a long press as another action. A long press can be a supplementary method. Key conditions should be directly readable, and supplementary explanations need a clearly labeled text control.

The second failure is an explanation icon that is hard to tap or sits too close to an area that commits immediately. The questions are both “Can players open it?” and “Might they make the wrong choice while trying to view it?” W3C’s explanation sets out minimum target-size requirements and exceptions. This does not mean every button must have the same size, nor does it justify claiming that a page is certified. Checks should examine both the positions of explanation controls and commit areas, and the results of operating them.

The third failure is a details overlay that hides other options, followed by a jump to the top of the page when it closes. When players need to compare options one by one, details can expand in place, with the control changing to “Hide conditions.” Very long details can appear separately, but returning should take the player back to the original option’s position.

The fourth failure is expressing losses only through colors, icons, or ellipses. A boat-ticket icon with “−2” should have the text “Uses two boat tickets” beside it. Wrapping on narrow screens must not cut off “cannot be retrieved.” Checks with enlarged text should cover complete conditions and the commit button, not just whether the title overflows.

Copy the following checklist to each key choice point. Have the editor fill in the wording, then pass it to the interface implementer for checking:

This checklist covers only the presentation of decision information. It cannot replace a full accessibility assessment. A summary is optional; checking actual conditions before committing is necessary regardless of whether a summary exists. If resources change while the player is reading, show the new cost first and let the player decide again. If a summary is used, update it as well instead of retaining outdated content.

Unrevealed story information must also be distinguished from interface omissions. The example can withhold the recipient’s response, but it cannot hide the ticket price the character already knows. Limiting spoilers means leaving unrevealed consequences undisclosed, not concealing the terms of the immediate transaction. If a consequence is only the character’s guess, write “may”; do not turn it into a guarantee in the summary.

Timed choices also require a decision about whether reading time counts, and the interface must explain it. If the timer continues during reading, shorten the always-visible wording while retaining every key condition, and reduce content that must be expanded. A details button alone does not solve the reading burden. The final handoff standard is this: players can understand what they are exchanging before acting, without having to discover a hidden gesture.