# Daily Poker Hub Design-System Foundations and Draft Wireframes

**Version:** 1.0
**Decision date:** August 30, 2026
**Status:** Working design-system foundation; page composition requires refresh and owner approval
**Primary visual reference:** Polygon
**Primary decision/SEO reference:** TechRadar

> The system adapts compositional and information-architecture principles. It does not copy either reference site's code, graphics, proprietary fonts, exact layouts, or distinctive trade dress.

`/DESIGN.md` owns design approval status and boundaries. The tokens and component principles in this document are working authority where they agree with `DESIGN.md`. The current wireframes and HTML prototypes are draft exploration only and are not visual acceptance or implementation authority.

## Executive design decision

Daily Poker Hub should look like an editorial gaming publication at first contact and behave like a disciplined product-comparison resource once a visitor begins making a decision.

Reference principles:

- **Editorial-publication principles:** expressive typography, strong feature hierarchy, graphic surfaces, and fewer but more consequential modules.
- **Decision-resource principles:** verdict-first page anatomy, concise pros and limitations, structured facts, jump navigation, methodology, freshness, and related decision paths.
- **DailyPokerHub behavior:** evidence-state labels, club/app separation, crawlable directory enhancement, UTC recommendation records, and future live-table freshness states.

The emphasis changes by user task. Exact visual composition is deferred to the wireframe refresh; no percentage is an implementation rule.

## Product assumptions

The launch product is a **small, high-density CMS site**, not a high-volume newsroom.

### MVP acquisition/product routes

- `/`
- `/apps/`
- one `/apps/{app-slug}/` per qualifying app
- `/daily-pick/`
- `/daily-pick/history/` as public `noindex` history

### Required trust/operational routes

- `/methodology/`
- `/corrections/`
- `/about/`
- `/responsible-play/`

Methodology owns editorial and commercial policy. Privacy and terms routes are added only when actual data handling or product behavior requires them.

### First expansion

- `/compare/`
- selected `/guides/{guide-slug}/`
- selected `/best/{intent}/` only after demand/evidence justify them
- selected game/platform hubs only when they stand independently
- `/live/` after the data source and expiry model are proven

The launch has no design-mandated app count. The BSB Poker/SERP audit and publication gates determine which applications qualify.

## Brand foundation

**Long promise:** Your one-stop place for finding the best games daily.
**Primary display line:** **Find the best games, every day.**

Character: confident, current, useful, editorial rather than casino-promotional, playful without becoming juvenile, transparent about uncertainty, bold enough for the illustrated logo, and disciplined enough for factual app/club records.

Avoid green-felt site surfaces, neon casino marquees, luxury-gambling stock imagery, poker symbols on every component, ubiquitous gold, brushed body copy, ungrounded star scores, and generic article feeds added to make the homepage look busy.

## Logo

`assets/daily-poker-hub-logo.png` is the owner-supplied, approved, canonical logo artwork. It is a 1536 × 1024 PNG with SHA-256 `d047cdf743a453a5974c6d113d9ec0260ccea43c17fa9bb3e1f6c4e6f33360c8` and is registered in `/RIGHTS.md`.

The artwork combines the Daily Poker Hub wordmark with a crown, four aces, red and black chips, suit marks, and a red underline. Do not redraw, simplify, crop, recolor, vectorize, or create small-format variants as though they were approved. Any transparent, cropped, monochrome, or vector derivative requires owner approval.

`assets/logo-lockup-proxy.svg` remains only as historical prototype evidence. It is not a brand asset, alternative logo, or implementation source.

## Color

| Token | Value | Role |
|---|---|---|
| Ink | `#0A0A0C` | text, dark surfaces, borders |
| Paper | `#F7F2E9` | warm page background |
| Raised paper | `#FFFDFC` | cards/reading surface |
| Red | `#E4252B` | action and editorial energy |
| Dark red | `#B91C24` | accessible small red text |
| Gold | `#D6A521` | crown, Daily Pick, rare emphasis |
| Positive | `#176B45` | confirmed/current state |
| Focus | `#155EEF` | keyboard focus |

Gold remains rare. Evidence semantics always include text, never color alone.

## Typography

- Display: Archivo Black with safe heavy fallbacks.
- Body/UI: Inter or Source Sans 3 with system fallback.
- Data/time: IBM Plex Mono/system monospace.
- Logo: approved custom brushed lockup only.

No font files are bundled.

Display headings are uppercase by default. Body copy remains mixed case and roughly 45–48rem max. Brush treatment belongs only in the logo and rare campaign art. Tabular numerals are required for timestamps/live data.

## Layout

Desktop: 12-column grid, 1440px max shell, 20–56px fluid gutters, 16–32px module gap, ~760px reading column.

Tablet: stack major regions; directory falls from three columns to two; sidebars become normal-flow content where necessary.

Mobile: single-column reading order; one app card per row; bounded comparison-table scrolling; recommendation evidence follows the recommendation; minimum 44×44 controls.

Primary card geometry: `1.25rem 1.25rem 1.25rem .25rem`, 2px ink borders and hard offset shadows. The playing-card cue is subtle rather than literal.

## Core components

Global: site header/nav, mobile navigation, breadcrumbs, section heading, footer/trust navigation.

Action/state: primary red, dark and paper buttons; evidence badges; active/stale/discontinued/unknown states; verification timestamp; commercial disclosure; correction notice.

Discovery: standard/compact/featured app cards; directory search; non-indexable filters; crawlable category links; related-app modules.

App profile: identity, quick facts, DPH verdict, good-for/limitations, structured fact tiles, evidence-aware tables, TOC, screenshot gallery, app/club boundary, sources, change history, related content.

Recommendation: Daily Pick feature, app+club lockup, check time, use case, rationale, alternatives, relationship disclosure, expiry/removal state.

Live: coverage state, activity row, app/club/game identifiers, observed-at timestamp, fresh/stale/unavailable states, last-good warning, source health and partial coverage.

## Page reference emphasis

Home and Daily Pick may emphasize editorial hierarchy. Directory, app profile, and methodology emphasize decision clarity and evidence. Compare and Live are DailyPokerHub product interfaces when their later release gates pass. These are qualitative reference principles, not compositional acceptance.

## Draft page anatomy

The following sequences identify required information, not approved layout. The owner has deferred page-composition and wireframe approval.

### Home

1. Brand promise/actions
2. Today's app + club recommendation
3. Featured app discovery grid
4. Live-table coming-soon preview
5. Recently verified records
6. Real guides only when content exists
7. Methodology/trust feature
8. Footer

No large news stream is required at launch.

### Directory

1. H1/explanation
2. Crawlable category shortcuts
3. Search/filter enhancement
4. Result count
5. Full normal-anchor app grid
6. Directory methodology/indexability explanation

All eligible cards exist in initial HTML. Filter/sort states are not canonical URLs.

### App profile

1. Breadcrumb
2. App identity/classification/summary
3. Quick facts
4. DPH verdict
5. Good for / limitations
6. Current status/availability
7. Platforms/games/features
8. Original screenshots/testing context
9. How it works
10. Club model and app/club boundary
11. Safety/evidence
12. Sources/change history
13. Related apps/guides

Broad app and review intent stays on one canonical route.

### Daily Pick

1. Date and clear Daily Pick label
2. App + club
3. Best-for/use case
4. Check time/evidence
5. Why selected
6. What was checked
7. Limitations/commercial relationship
8. Alternatives
9. Link to the app profile

Use one stable `/daily-pick/`. UTC effective and expiry instants are controlled per CMS record. When no record is active, show a no-current-pick state. Preserve prior and corrected records at the public `noindex` `/daily-pick/history/` route without indexable daily pages. The history composition remains part of the wireframe refresh.

### Guide

Large editorial H1/deck, author/reviewer and substantive date, answer-first intro, TOC, original synthesis/tables/diagrams, evidence caveats, contextual canonical links, sources and related guides.

### Compare

Static H1/method, crawlable eligible-app list, Svelte selector, matrix, evidence/unknown states and canonical profile links. Use URL fragment selection state initially; do not generate pairwise routes automatically.

This is a later-release template and does not appear in launch navigation or launch app controls.

### Live

Coverage/source health, last observation time, filters only after data exists, activity rows, explicit stale/partial/unavailable states and coverage methodology. Before the data contract passes, only the home page may show a non-interactive future preview. Do not publish or link `/live/`.

### Methodology

Testing workflow, source hierarchy, evidence labels, recommendation method, commercial disclosure, corrections, freshness/retirement and responsible-play context.

## CMS mapping

**App record** feeds identity, directory card, quick facts, platform/game tiles, comparison matrix, related apps and structured data.

**Editorial profile** feeds verdict, good-for/limitations, onboarding narrative, screenshots, safety/evidence and change notes.

**Club record** feeds Daily Pick lockup, public ID/contact route, evidence class, last check, caveat and commercial relationship. A club record does not automatically receive a public/indexable route.

**Recommendation record**: UTC `effectiveFrom`, UTC `expiresAt`, `appId`, `clubId`, headline, rationale, best suited for, games/formats, check time, evidence references, limitations, commercial relationship, alternatives, correction notes and revision history.

**Verification event** feeds homepage freshness, app last-verified state, source list, change history and stale warnings.

## Accessibility

Semantic landmarks and one descriptive H1; visible skip link; native anchors for indexable navigation; keyboard access to filters/compare; persistent focus ring; no essential hover-only content; image alternatives; reduced motion; 400% reflow except bounded tables; real table headers; text plus color for states; body >=16px; controls >=44px.

## SEO/performance constraints

- Primary content/app facts render in static HTML.
- App cards are normal `<a href>` links.
- Directory works as a full list without JavaScript.
- Filter/search does not create crawlable inventory.
- App H1/canonical/core facts do not depend on hydration.
- First useful answer stays near top of app pages.
- No whole-page Svelte root on editorial routes.
- Screenshot dimensions are reserved to avoid layout shift.
- Home/app/guide routes default to zero client JS; launch client code is limited to directory filtering.
- Design survives blocked third-party scripts and failed enhancement.

## Content voice

Direct, specific and evidence-aware. “We observed” only for documented first-hand checks; “the operator states” for official claims; “could not verify” for insufficient evidence. Avoid unsupported absolutes. Recommendations identify use case/time window. App and club remain separate entities.

## Astro implementation handoff

Suggested server-rendered components:

- `SiteHeader.astro`
- `SiteFooter.astro`
- `Breadcrumbs.astro`
- `SectionHeading.astro`
- `AppCard.astro`
- `AppIdentity.astro`
- `QuickFacts.astro`
- `VerdictPanel.astro`
- `EvidenceBadge.astro`
- `VerificationTime.astro`
- `SourceList.astro`
- `ScreenshotGallery.astro`
- `RelatedApps.astro`
- `Disclosure.astro`
- `LivePreview.astro`

Initial Svelte island: `DirectoryFilter.svelte`. `ComparisonTool.svelte` belongs to the later comparison release.

## Acceptance criteria

Visual foundation: the canonical DPH brand is recognizable before app logos; the design works with any evidence-qualified app count; editorial influence appears through hierarchy rather than copied styling; app information scans quickly; gold remains rare; poker motifs never overwhelm factual content. Page-level visual acceptance waits for the owner-approved wireframe refresh.

Functional: core navigation/content works without JS; directory enhancement preserves canonical links; all major components have mobile states; unknown/stale/discontinued/partial states are designed; recommendation evidence/disclosure sits adjacent to the decision.

SEO/content integrity: one canonical profile owns broad app intent; no filter/daily-history URL explosion; original screenshots/evidence metadata have defined places; verification dates represent actual checks; no fabricated ratings, table counts, safety claims or endorsements.