ux: auth usability pass — 9 fixes from Nielsen heuristics + Don't Make Me Think#48
Merged
Merged
Conversation
The input styling rule targeted only input[type="text"], so the password box fell back to the browser's default chrome — a different border, background, height, and font from the username box right above it. On a dark themed form that mismatch is glaring and makes the screen look half-finished, undermining trust right at the sign-in step (Nielsen #4: consistency and standards). This extends the base, focus, and mobile input rules to cover input[type="password"] as well, so both fields share one appearance. Done as a shared selector rather than a per-field class so any future input type inherits the same treatment. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Both the login and register screens opened with no field focused, so the very first thing a player had to do was click into the username box before they could type. For a screen whose entire purpose is "type two things and submit," that wasted click is exactly the kind of friction Krug's "don't make me think" warns against (Nielsen #7: flexibility and efficiency of use). This adds the autofocus attribute to the username input on both forms. On the login screen the post-register handoff still wins — when the username is pre-filled, focus jumps to the password field instead — so the cursor always lands on the first thing the player actually needs to fill in. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Password input is masked with no way to reveal it, so a player who fat-fingers their password has no way to check what they typed before submitting — they just get a generic "login failed" and start guessing. Masked-only fields are a known driver of failed logins, and a reveal toggle is now a platform convention players expect (Nielsen #7: flexibility and efficiency; Krug: conventions over invention). This adds an inline "Show"/"Hide" button inside the password field on both the login and register screens that flips the input between password and text and updates its own label and aria-label. The control is keyboard-focusable and type="button" so it never submits the form. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The login and register screens were visually near-identical: both opened with just the "🏰 Barony" title and two fields, so the only way to tell which one you were on was to read the field labels and button text. A player who clicked "Create one" and then got distracted had no at-a-glance confirmation they'd landed on the right screen (Nielsen #6: recognition rather than recall; #2: match between system and the real world). This adds a subtitle under the title — "Log in to your account" on login, "Create your account" on register — so each screen states what it is the moment it loads. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The username and password rules (3–50 characters; at least 8 characters) lived only in the placeholder text, which disappears the instant the player starts typing. So the requirements vanished exactly when they became relevant, and the player only learned the password was too short after submitting and getting an error back (Nielsen #6: recognition rather than recall; #5: error prevention). This adds a persistent hint line under each field that states the rule and stays visible while the player types, so they can satisfy the requirement on the first try instead of discovering it through a failed submit. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The "Don't have an account? Create one" and "Already have an account? Log in" links had no styling of their own, so they rendered in the muted gray of the surrounding helper text with no clear affordance — the one navigation path between the two screens looked like ordinary prose a player could easily skim past (Krug: an actionable thing should look obviously actionable; Nielsen #4). This styles the cross-links in the theme's accent color with bold weight and an underline on hover, so the way to switch between signing in and signing up reads as a real, tappable link. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Registration took a single password field, so a typo in that one masked input created an account with a password the player didn't intend — and they wouldn't find out until the next login failed, with no way to know whether they mistyped now or then. For a credential you can't see as you type, one field is a silent error waiting to happen (Nielsen #5: error prevention). This adds a "Confirm Password" field and blocks submission with an inline "Passwords do not match" message when the two differ, so a mistyped password is caught at registration instead of locking the player out of the account they just made. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The Logout button wore a saturated red (#8b3a3a → #a04040 on hover), the universal color for destructive actions like Delete or Surrender. Logging out isn't destructive — your account and game are saved — so dressing it in danger red both overstated the stakes and competed for attention with genuinely risky in-game controls (Nielsen #4: consistency and standards — a color that means "danger" elsewhere shouldn't mean "routine sign-out" here). This restyles Logout in the theme's neutral brown with a subtle border, so it reads as the secondary, safe, reversible action it actually is. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Because password fields are masked, a player with Caps Lock on can't see that every character is the wrong case — they just get "login failed" and retype the same thing, confused. Caps Lock is one of the most common reasons a known-good password is rejected, and nothing on the screen pointed to it (Nielsen #5: error prevention; #9: help users diagnose errors). This shows a "⚠ Caps Lock is on" warning while the player types in any password field on the login and register screens, detected via the key event's getModifierState, and hides it on blur. It surfaces the problem before the player wastes a failed submit on it. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
A second usability-pass batch over the auth UI (login, register, and the auth bits of the game screen), kicked off by a reported inconsistency: the password box didn't match the username box. Every commit is one self-contained Nielsen / Krug fix, scoped small for easy review.
Round 1 — input consistency & affordances
input[type="text"], so the password box fell back to browser-default chrome (Nielsen Implement Army Management (Split, Merge, Display) #4).Round 2 — recognition & guidance
Round 3 — error prevention & control
Test plan
🤖 Generated with Claude Code