Skip to content

Twitch extension: add the panel, video component and mobile views (all extension formats) #208

Description

@demortes

Goal

The Twitch extension currently ships one viewer experience: the video overlay (extension/video_overlay.html, a small tab over the stream that opens into the commander card). Expand it so viewers get the card in every extension view type Twitch supports, sharing one codebase, so a viewer on any device or layout can follow the commander's session.

Views to add

Twitch has changed these names and limits over time, so every dimension and capability below must be re-checked against the current Twitch extension docs and the developer console before building (verify in console).

View Where viewers see it Fit for EDNexus
Video overlay (exists) Over the whole player Keep as is.
Panel Always-on panel below the stream, on the channel page (fixed narrow width, limited height range) Good fit: a persistent, readable card that does not cover the game. Best for viewers who want details without opening an overlay.
Video component A movable component inside the player, sized and positioned by the broadcaster A compact always-visible summary (system, ship, fuel, a rank bar) the broadcaster can place in a corner of the stream.
Mobile The Twitch mobile app Needs a touch-first layout; the overlay's hover/handle model does not apply.
Config / live config (config exists) The broadcaster's setup and live dashboard Live config could show connection state and what viewers currently see.

Approach

  • One renderer, several shells. Keep js/state.js (transport, backoff, staleness) and the card rendering shared; add a small entry HTML per view (panel.html, component.html, mobile.html, optionally live_config.html) that picks a layout, the way video_overlay.html does today. No copy-pasted logic.
  • Layout per view: panel = full card in a fixed-width column with a scrolling body; component = compact summary with an expand option; mobile = single-column, large touch targets, no hover. All colours from extension/css/tokens.css (design system, no hardcoded colours); all text sizes within the type scale; accessibility as for the overlay (focusable regions, live region for status/stale).
  • State and rules unchanged: same EBS endpoints, same snapshot schema, same 25-minute staleness rule, same "show nothing unless there is a live card" behaviour so channels that are not playing do not show an empty box.
  • Per-view broadcaster control: the broadcaster may not want every view active; document how to enable/disable each in the Twitch console and whether the desktop app needs any setting (probably not, since views read the same snapshot).
  • Packaging/CI: the existing bundle workflow already zips extension/ and rejects inline script/style; extend its required-files check for each new entry page, keep dev/ out of the zip, extend the dev harness (?mock=1) and dev/test-state.js so each view can be run and tested locally without Twitch.
  • Listing assets: each view needs listing/screenshot coverage (the existing assets are in assets/twitch-listing/); update extension/README.md and the submission checklist with per-view steps.

Constraints and risks

  • Twitch review: adding or changing views is a new extension version that goes through review again, and each view has its own policy checks (size limits, no external requests, accessibility, no auto-playing media). Sequence this after the current extension has been approved and is live, so a problem in a new view cannot hold up the first release.
  • Privacy is unchanged and public: all views read the same public initial-state snapshot, so nothing new is exposed, but a persistent panel makes the card more visible than a hidden overlay tab. Re-check the defaults (location, carrier, credits off) in that light, and the stream-sniping note already in extension/README.md.
  • Density: a panel/component has far less room than the overlay, so the "which sections show" choice (set in the desktop app) matters more; consider a compact variant of the snapshot or per-view section limits.
  • Mobile testing needs the Twitch mobile app or its testing tools; budget for that.

Acceptance criteria

  • Panel view implemented and verified in the Twitch developer console hosted test, within the console's size limits.
  • Video component view (compact summary) implemented and verified.
  • Mobile view implemented and verified on a device or the mobile test tools.
  • Shared code only: no duplicated transport or render logic; the transport tests (dev/test-state.js) still cover it, with added tests for per-view layout selection.
  • Offline, error, stale and unsupported-schema states handled in every view (no permanent empty box).
  • Bundle workflow requires and packages each new page; zip layout unchanged otherwise.
  • extension/README.md and the listing assets updated per view; submission steps documented.
  • Accessibility and the no-hardcoded-colours rule met in every view.

Related: epic #39 (Twitch extension end to end), which is waiting on the first extension approval; do this afterwards.

🤖 Generated with Claude Code

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:twitchTwitch Extension and integrationenhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions