Illustrated Stats Wiki
This documentation covers the real product as it exists today: public discovery pages, the Try Me sandbox, team and season management, live stat workflows, account self-service, exports, and the core ASP.NET Core MVC structure behind the app.
System Overview
Illustrated Stats is a basketball team management and stat-collection platform built around fast game-night usage. The app supports public product discovery, seeded demo access, team setup, roster management, seasonal organization, real-time collaborative stat entry, post-game reporting, printable summaries, and CSV exports.
Visitors can learn the product, launch a real sandbox, and understand the workflow before creating a permanent account.
Coaches, scorekeepers, players, and owners can work from one shared system without splitting live game data across tools.
Primary user journeys
Try Me Sandbox
Try Me is the guided demo path into the real application. It provisions a disposable account, team, roster, season, and game history so visitors can experience the real dashboard without affecting permanent customer data.
The sandbox uses the live UI and working workflows. The difference is that the seeded data is temporary and isolated for demo use.
Demo sessions expire automatically after 10 minutes, and the layout shows a visible countdown with an Exit Try Me action.
Sandbox behavior
Roles And Access
The application behavior changes based on authentication state, demo mode, and elevated privileges. Several screens expose owner-only or admin-only actions while keeping public discovery pages open to everyone.
Can browse the landing page, instructions, documentation, donation flow, sign-in, and the Try Me entry point.
Receive a disposable seeded workspace with real navigation and reporting, but without permanent team-creation authority.
Can access their teams, account area, assigned game workflows, and linked player tools based on team permissions.
Can access owner tools, approvals, impersonation support, and organization-level administrative workflows.
Impersonation support
The shared layout includes a visible impersonation banner and a return action when the relevant claim is present. This allows elevated operators to help another user while keeping the active context obvious on screen.
Teams, Rosters, Seasons
Team management is the foundation of the app. Teams hold identity, branding, roster membership, staff, and seasonal grouping. Team and season dashboards organize upcoming games, completed results, and reporting windows.
Core team concepts
Game creation
When creating a new game, the operator selects the stat-keeping model up front. This is where the workflow branches into Classic or Dynamic live stat behavior.
Live Stat Workflows
The live game experience is centered around the LiveStats screen. It provides the scoreboard, player selection, stat-entry sheet, correction and undo controls, lobby access, and cross-browser coordination signals.
Recorded stats belong to the player and game, not to the specific scorekeeper currently holding that player or stat family.
The system prevents overlapping ownership in Classic mode and stat-family conflicts in Dynamic mode.
Live screen responsibilities
Classic Mode
Classic mode is the original workflow. A scorekeeper claims one or more players and is responsible for all supported stats for those claimed players.
How Classic works
Correction behavior
Operators can directly adjust stat counts, undo the most recent change, or clear a player's collected game stats using the in-screen tools and confirmation flow.
Dynamic Mode
Dynamic mode is a second live-stat workflow designed for families or staff who want to split work by stat type instead of by player.
Stat-family model
Dynamic interaction model
In Dynamic mode, anyone can open any player. The live stat tiles only stay active for the stat families currently claimed by that user, while unowned categories stay greyed out and blocked.
Lobby And Presence
The lobby is the coordination layer for both live workflows. It shows who is present, what they are responsible for, and whether the game is ready to begin.
Classic lobby
Classic mode shows who is tracking which players. It supports player claiming, saving selections, and scheduled-game startup.
Dynamic lobby
Dynamic mode shows who is covering what, current coverage completeness, and role-selection actions. The UI emphasizes visible presence, clearer labels, and easier claim controls so scorekeepers can coordinate quickly.
Browsers refresh presence and assignment data to keep lobby state synchronized across users.
Scheduled Dynamic games stay blocked until all required stat jobs are covered.
Post-Game, CSV, Reports
After a game is completed, the game detail page becomes the source of truth for final outputs and administrative follow-up.
Delete game safeguard
The completed-game delete flow nudges users to export first and keeps confirmation guardrails in front of final removal so historical data is not lost casually.
Accounts, Profiles, And Self-Service
The account area now handles more than simple profile edits. It ties together sign-in identity, team access, player profile linking, owner-controlled email changes, and destructive account cleanup.
Users can edit profile details from the account dashboard while keeping their team access and login context in one place.
If a coach-created player record matches the signed-in email, the dashboard can surface a claim flow so the player can take ownership of that profile.
Self-service flows
DELETE, keeps the action disabled until confirmed, and removes related memberships, tokens, linked player access, owned teams, and the user account itself.Application Architecture
The app follows an ASP.NET Core MVC structure with controllers, Razor views, shared layout composition, service-layer helpers, and SQL-backed storage. Most game-night interactivity is implemented with Razor-rendered HTML plus client-side JavaScript inside the relevant views.
Key controllers and services
View responsibilities
Large interaction-heavy views such as LiveStats.cshtml, account surfaces, and dashboard pages hold significant UI logic, live polling, and client-side state management. Shared navigation and cross-app messaging live in Views/Shared/_Layout.cshtml.
Data And Storage
The application uses SQL-backed entities and runtime schema checks for newer features. Live stat mode selection, demo provisioning, account cleanup, and player-link flows all depend on persisted relational data.
Important persisted concepts
Games.StatKeepingModeStores whether a game uses Classic or Dynamic live-stat behavior.GameDynamicStatAssignmentsMaps game, user, and stat-family ownership for Dynamic mode.Data safety patterns
Deletion flows explicitly clean up related rows, and export-first safeguards reduce the risk of losing final game history without an offline backup.
Operations And Support
From an operating perspective, the app is optimized for gym usage, phone entry, onboarding new scorekeepers quickly, and preserving clean account ownership over time.