DEV Community: JD Liu

Building an Accessible Visual Scaling Game with Astro and React Islands

JD Liu — Thu, 17 Sep 2026 04:00:21 +0000

I recently built a browser game where the player's answer is a visual ratio rather than a typed number. The static pages use Astro, while the playable area is a focused React island. That boundary made the site easier to keep fast, crawlable, and accessible.

The game is available at Size It Up Party. A round shows a fixed reference silhouette and an adjustable target. The player changes the target scale, locks the estimate, and receives a reveal with the actual ratio and score.

Keep the rules outside the component

Normalization, validation, error calculation, and scoring live in a pure TypeScript package. React owns interaction state and rendering, but it does not own the mathematical definition of a valid answer. The same scoring behavior is reusable across Daily and Unlimited modes, and tests remain independent from the DOM.

Treat pointer input as one interface, not the interface

Dragging a scale handle is useful, but it is not sufficient. The game also exposes Smaller, Larger, and Reset controls with visible labels. Keyboard users can reach the same actions, and touch users do not need precise pointer movement.

The important value is the normalized scale ratio. Pointer gestures, buttons, and keyboard shortcuts are different ways of updating that same value.

Separate object movement from the answer

Players may reposition silhouettes or change the view to inspect them. Those actions must not alter the submitted estimate. The answer is derived only from the target's scale along the named measurement axis.

Keeping camera state, object position, and answer state separate prevents subtle bugs and makes the reveal deterministic.

Preserve static HTML

The game island is interactive, but the rest of the page is ordinary Astro output. The heading, instructions, explanation, FAQ, legal links, and metadata are present in the initial HTML. The site does not need to turn an entire landing page into a client-rendered application just because one section is interactive.

Design the reveal as a stable state

The reveal reuses the same canvas area instead of mounting a second interface below it. This avoids a large layout shift. Text feedback explains direction and error, so color is supportive rather than the only signal.

Test rules and controls separately

Pure scoring tests cover exact answers, symmetric overestimation and underestimation, invalid values, and boundaries. UI tests focus on whether every input method updates the same scale state and whether locking prevents later edits.

The broader lesson is that a custom visual interaction does not require a custom architecture everywhere. A small interactive island, pure shared rules, and ordinary static content can coexist cleanly.

Designing a Fair Reveal Sequence for a Multiplayer Voice Game

JD Liu — Tue, 08 Sep 2026 13:24:02 +0000

A voting screen is only the final step of a multiplayer voice game. Fairness begins earlier: before players hear the first recording, while they are working out whose turn it is and whether there are more performances to come.

This design note comes from the ChoicerVoicer project and uses our independent Mimic Party experience as the context. The product is a private browser game for three to five players: hear a reference, record an impression, listen to the group, and vote. The points below are a review framework, not a claim that we have experimentally measured a particular voting bias.

Separate the jobs of each phase

A player has a different question in every phase:

Phase	Player question	Useful interface answer
Reference	What am I imitating?	A clear sound and a visible listening state
Preparation	Should I start yet?	A countdown with an explicit transition
Recording	Is my take being captured?	A recording interval with progress
Reveal	Whose attempt is this?	The performer’s name and playback progress
Voting	Have I heard everyone?	Voting after the reveal sequence
Results	What happened to my vote?	A visible result before the next round

Trying to answer all six questions on one permanently interactive screen makes the interface harder to read. The primary action should follow the current phase. Controls can remain spatially predictable without implying that every action is available at every moment.

Do not make voting race the last recording

If voting becomes available while the final take is still playing, the interface invites users to make a choice before listening is complete. Even without a formal fairness study, that is a clear mismatch between the stated rule and the available action.

In a review, ask whether an impatient user can cast a vote while another performer is still waiting to be heard. Also inspect the transition between tracks: a brief gap should not look like the end of the whole sequence. A performer label plus a count such as “3 of 5” provides different information from the progress bar within a single recording.

Names should remain useful when avatars repeat

People may choose the same character because it is funny or because they like it. A shared avatar is therefore a weak identifier. Keep readable nicknames attached to recordings and voting choices; do not rely on color alone to distinguish players.

Review a deliberately awkward set of names: two short names, two similar names, and one longer nickname. The test is whether players can still connect the take they heard with the person they mean to select. There is no need to expose account details to solve that problem.

A vote result is not a voice-quality assessment

A group may reward similarity, timing, or the attempt that made everybody laugh. Those are different preferences. Interface copy should describe the votes that were cast rather than imply an objective measurement of a person’s voice.

For example, “Three players voted for this take” is supported by the interaction. “Your voice is 92% accurate” would require a separate measurement method and an explanation of what it measures. If that method does not exist, do not invent precision in the presentation.

Review the experience with an interrupted participant

Useful acceptance questions include:

Can a late-loading player tell which phase the room is in?
Does the end of one recording clearly differ from the end of all recordings?
Can keyboard users identify the current choice and move between candidates?
Is the current performer still identifiable without color or animation?
Does a disabled action explain what must happen next?
After the standings, is another game an explicit host decision?

These questions can guide a usability review before a team adds more animations or scoring options. They are proposed checks, not a report that every browser and assistive technology combination has passed.

Keep entry conditions as clear as the round rules

In the current Mimic Party flow, hosting requires active membership; creating a room has no credit cost and starting a game costs the host 15 credits. Guests need no subscription. Those conditions belong before the start decision, not after players have already committed to a countdown.

A good reveal sequence gives everyone a clear opportunity to be heard and everyone else a clear moment to choose. That is a concrete design target even when the performances themselves are happily unpredictable.

Design Recording Errors Around the Next Safe Action

JD Liu — Tue, 08 Sep 2026 07:27:17 +0000

A recording error is not just a technical status. It is a decision point for someone who may have just delivered a take they do not want to repeat.

The most useful question for an error message is: what can this person safely do next? Here is a product-design checklist for answering it without promising recovery that the application cannot actually provide.

Separate the failure from the recording

“Something went wrong” leaves two questions unanswered: did capture fail, or did a later step fail? A person needs to know whether their performance still exists before deciding to retry.

Treat these as separate states in the interface:

No recording was captured.
A take exists locally, but a later operation did not finish.
A saved take exists and can be reopened.
The application cannot confirm whether a take is recoverable.

These are proposed UX categories, not claims about every browser or recording library. Your implementation must establish which category is true before displaying it.

Write the recovery contract first

For each state, write a short contract: what remains available, what the button will do, and what the user might lose. Then make the message match that contract.

For example, if a take is still playable, a message could say: “Your take is available below. The video export did not finish. Listen to it before trying export again.” That copy is appropriate only if the player really works and retrying export does not overwrite the take.

If nothing was captured, be equally direct: “No take was recorded. Check your microphone selection, then record this line again.” Do not use “restore” or “resume” when the next action is actually a fresh recording.

Give buttons precise scopes

“Try again” can mean reacquire microphone access, repeat processing, resend an upload, or discard the current take. Those are not interchangeable actions.

Prefer scoped labels such as “Record this line again,” “Retry export,” or “Choose another microphone.” Put destructive actions apart from safe recovery actions. If replacing a take is unavoidable, explain that before the replacement starts.

Do not make reassurance outrun evidence

Avoid “Your work is safe” unless the application can substantiate that promise. A local preview may disappear if the tab closes. A completed upload may not mean the final output exists. A success animation is not a persistence guarantee.

A narrower statement is often more useful: “This take is still available in this tab.” Pair it with an actual next step, not an instruction to refresh that could remove the only accessible copy.

Test the message with a small scenario table

Scenario	Question the UI must answer
Microphone unavailable before capture	Was anything recorded?
Interruption midway through a line	Is there a usable partial take?
Processing fails after capture	Can I listen before retrying?
User presses retry twice	Does another action start or is one already running?
User wants to leave	What remains available afterward?

Run these checks with the actual product behavior. If the message and behavior disagree, fix the contract rather than adding more reassuring words.

Review copy alongside the interaction

I work on ChoicerVoicer, a browser-based voice-acting and dubbing project. This checklist is a general design exercise, not a claim that a particular recovery guarantee exists there.

The broader lesson is simple: error copy belongs in the same review as state transitions and destructive actions. A beautiful message is still misleading if its button performs the wrong kind of retry.

Five UX Lessons from Building a Browser-Based Dubbing Game

JD Liu — Thu, 27 Aug 2026 13:58:30 +0000

Building a browser-based dubbing game sounds straightforward: play a scene, open the microphone, record a line, and export the result.

The difficult part is not getting audio into the browser. It is helping someone move from “I want to try this” to a finished performance without making the experience feel like audio-editing software.

While building ChoicerVoicer.games, I kept running into UX problems that were specific to voice recording. Here are five lessons that shaped the product.

1. Ask for microphone access at the moment of intent

A permission prompt shown during page load has no context. The visitor has not chosen a scene, read a line, or decided to perform yet, so the request feels suspicious.

A better sequence is:

Let the visitor browse scenes first.
Show exactly what the recording step will do.
Request microphone access only after the visitor presses a clear recording action.
Explain how to recover if permission is denied.

This does not remove browser friction, but it gives the prompt a reason. The user understands why the browser is asking.

The denial state also needs to be a real product state. “Microphone unavailable” is not enough. It should explain whether the user needs to change a browser permission, select another input device, or reload after granting access.

2. Treat every line as a small, reversible task

Recording an entire scene in one take creates pressure. One mistake near the end can make the user feel that all earlier work was wasted.

Line-by-line recording changes the mental model. Each line becomes a small task with a clear beginning and end:

listen to the reference,
prepare,
record,
review,
keep or retry,
continue.

The important part is reversibility. A retry should replace only the current take, not reset the rest of the performance. Completed lines should remain visibly completed.

This pattern is useful beyond dubbing. Any creative workflow involving performance, narration, language practice, or repeated capture benefits from dividing a large commitment into recoverable steps.

3. Make review part of recording, not a separate editing mode

Creators often want to hear a take immediately. Moving them into a separate editor after every line interrupts the flow, but skipping review removes confidence.

The compromise is a lightweight review loop:

play the recorded take immediately,
keep the retry action close,
show which take is currently selected,
avoid presenting a full timeline unless the task really needs one.

The goal is not to recreate professional audio software. It is to answer one simple question quickly: “Do I want to keep this take?”

A focused review loop also works better on mobile, where dense editing controls quickly become difficult to use.

4. Design recovery before designing the happy path

Browser media workflows fail in more ways than a normal form:

permission is denied,
no input device is available,
the active microphone changes,
a recording is empty,
the tab loses focus,
a mobile browser interrupts capture,
a user refreshes halfway through a scene.

These cases should not all collapse into one generic error.

It helps to classify failures by what the user can do next. Can they retry the current line? Change a permission? Select another device? Continue with previous takes? Start the scene again?

Recovery copy should describe the next useful action instead of exposing implementation details. Users do not need to know which internal stage failed. They need to know whether their work is safe and how to continue.

5. A finished result is part of the onboarding

In a creative tool, the first finished artifact teaches the product better than a long tutorial.

That changes what “onboarding” means. The product should minimize the distance between selecting a scene and seeing a playable result. Optional settings, accounts, advanced editing, and export choices can wait until they are relevant.

A useful first-session path is:

choose a short scene,
record a small number of lines,
review the combined performance,
download or share the result.

Once someone has completed that loop, more advanced features make sense because the user understands the reward.

What I would do differently

If I were starting the interaction design again, I would prototype denial, retry, refresh, and mobile interruption states at the same time as the main recording flow.

Media products often look complete in a happy-path demo while still feeling fragile in real use. The recovery states are not polish added at the end; they are part of the core experience.

You can try the current browser experience at ChoicerVoicer.games. It is an independently developed web project, separate from the similarly named downloadable itch.io game.

I would be interested to hear how other developers handle microphone permissions, retakes, and interrupted recording sessions in browser-based creative tools.