[feature] Redesign the Pebble watch experience #16

• 
  @github-anthodev opened this issue · Sep 4, 2026

  🔢 Impact Version (SemVer)

  MINOR

  ---

  🌿 Suggested Branch

  feature/redesign-watch-experience/watch/16

  ---

  📝 Description

  Review and redesign the visual design and user experience of the Pebble watch application. The redesign must make the consultation flow clearer, more legible, and more intentional on both supported watch shapes while preserving the existing departure behavior and resource constraints.

  The product and visual guidelines will be supplied by the product owner during this ticket. They are intentionally not guessed or frozen here; they must be captured and agreed before implementation begins.

  ---

  ✅ Expected Behavior

  The watch presents favorites, departures, freshness, loading, stale, unconfigured, and unavailable states with a coherent visual hierarchy and predictable button interactions. The approved guidelines are reflected consistently in French and English on both emery and gabbro without regressing the event-only consultation flow.

  ---

  📋 Acceptance Criteria

  • Record the product owner's design and UX guidelines in this issue before implementation and translate them into an agreed watch design direction.
  • Review the current information hierarchy, typography, spacing, state differentiation, navigation feedback, and use of the available screen area.
  • Apply the approved direction consistently to UNCONFIGURED, LOADING, READY, STALE, and UNAVAILABLE.
  • Keep Up/Down favorite navigation, Select refresh, Back behavior, cache-first rendering, and minute aging understandable and predictable unless an explicit guideline changes their presentation.
  • Preserve the frozen request triggers, AppMessage contracts, departure semantics, localization fallback, and platform limits unless a separately agreed contract change is documented.
  • Render authored French and English copy plus representative long user/backend labels without clipping critical information on emery and gabbro.
  • Provide before/after captures and an interactive emulator walkthrough for both supported platforms, covering every state and the main navigation/refresh flow.
  • Stay within the established Alloy heap, binary/resource, and AppMessage budgets; do not introduce polling, steady-state animation, vibration, forced backlight, or touch input.
  • Update behavior-focused presentation/UI tests where the approved design changes observable output or interaction.

  ---

  🔗 Affected Endpoints/Routes

  • No backend route is expected to change.
  • The existing departure and AppMessage contracts remain consumers of the redesigned watch presentation.

  ---

  🧪 Tests to Add

  Type	Coverage
  Presentation/UI tests	Approved hierarchy and state-specific output, French/English copy, long-label handling, platform-specific layout
  Interaction regression	Up/Down navigation, Select refresh feedback, Back behavior, cache-first replacement, minute aging with no I/O
  Emulator QA	Every state and main interaction flow on emery and gabbro, with before/after captures
  Runtime verification	Existing heap/resource/AppMessage budgets and zero new network or background triggers

  ---

  ⚙️ Constraints

  • Do not invent visual or product rules before the product owner provides the guidelines.
  • Reuse the single Alloy/Piu implementation and built-in watch resources unless an approved guideline requires otherwise.
  • Keep accessibility, glanceability, legibility, and button-only operation central to design decisions.
  • Preserve bilingual behavior and verbatim user/backend labels.
  • Prefer a deeper, simpler presentation model over platform-specific duplication.

  ---

  🔀 Dependencies

  • Builds on the completed watch consultation implementation in #7.
  • Coordinate with the release work in #9 if the redesign changes release screenshots, metadata, or runtime evidence.

  ---

  ⚠️ Impact on Existing Behavior

  The watch's visual presentation and interaction feedback may change substantially. Departure data, request policy, storage, synchronization, and backend behavior should remain compatible unless the supplied guidelines explicitly require a separately reviewed change.

  ---

  🔍 Technical Context

  The current watch presentation is primarily implemented in:

  • packages/watch/src/embeddedjs/ui.js — Piu geometry, typography, wrapping, drawing, and platform-specific layout.
  • packages/watch/src/embeddedjs/presentation.js — state-to-visible-content mapping, departure rows, freshness, and footer content.
  • packages/watch/src/embeddedjs/localization.js — authored French/English watch copy.
  • packages/watch/test/presentation.test.js — observable presentation and rendering constraints.

  Implementation must begin by reviewing these areas against the supplied guidelines rather than treating the current layout as the target.

• 
  @github-anthodev · Sep 4, 2026

  Product-owner-approved watch direction and scope amendment

  This comment records the design/UX direction agreed during ticket execution and explicitly supersedes the issue body's expectation that no backend/AppMessage contract changes are required, but only for the changes listed below.

  Navigation and information architecture

  The watch will use three progressive screens:

  1. Favorites overview — favorites remain in companion-defined order. Each row shows the line, concise origin/direction, exactly one next-departure countdown, and a line-state indicator only when delayed, interrupted, or unknown. A final focused row performs Refresh all / Tout actualiser.
  2. Departure detail — one selected favorite with dominant next countdown, following departures, result freshness, per-departure delayed/cancelled information, and a bottom band summarizing the line state. Select opens traffic detail.
  3. Line traffic detail — normal confirmation with last-checked time, or a bounded/paginated IDFM traffic message for delayed/interrupted service; unknown is distinct and never presented as normal.

  Button mapping:

  • Overview: Up/Down move focus without I/O; Select opens a favorite or refreshes all; Back exits.
  • Departure detail: Up/Down switch favorites; Select opens line traffic; Back returns to overview preserving focus.
  • Traffic detail: Up/Down paginate long text; Select has no action; Back returns to departure detail.

  Loading and cache behavior

  • A full-screen static hourglass and “Rafraîchissement des informations en cours” is reserved for a true cold start with no usable summary.
  • Warm refresh always keeps cached overview/detail data visible and adds static update feedback.
  • Partial success remains visible; a failed traffic lookup becomes UNKNOWN, never NORMAL.
  • No polling, steady-state animation, vibration, forced backlight, or touch input is introduced.

  Traffic semantics

  The owner clarified that the former “perturbé” concept means retardé / delayed. The product states are therefore:

  • NORMAL
  • DELAYED — explicit line-level delay information
  • STOPPED — only an explicit interruption/suspension, never inferred from generic severity
  • UNKNOWN

  A delayed/cancelled individual departure must never be promoted into a line-level state. Line traffic must come from authoritative IDFM traffic information (candidate: PRIM Messages Info Trafic — Requête globale), with source freshness and bounded title/message/validity data.

  Approved scope expansion

  Issue #16 now includes the necessary clean contract cutover across backend, shared contracts, companion/AppMessage synchronization, watch model/storage/controller/presentation, and UI tests for:

  • per-favorite overview summaries;
  • bounded/coalesced Refresh all behavior;
  • line traffic state and active-line detail;
  • the revised Select/Back navigation model;
  • cache-first cold/warm/partial behavior.

  All new external responses remain untrusted and must be normalized/bounded before crossing public or AppMessage boundaries. Existing credential redaction and event-only behavior remain mandatory.

  Visual language

  • Operational screens omit the redundant app title; use current time, position, and freshness.
  • The next departure is the dominant typographic element.
  • Line state uses color plus symbol plus text; the colored surface is a bottom band, not the full screen.
  • Gabbro uses the official 260×260 round geometry with centered/focused content; current legacy 180×180 fixtures must be corrected.
  • FR/EN and representative long labels/messages must remain legible.

  Line badges

  The direction currently uses generic Lapin Futé line chips. Official IDFM pictogram embedding, downscaling, modification, and PBW redistribution are not sufficiently cleared by the dataset's ODbL metadata. Reproducing the artwork is not treated as a rights workaround. Official assets remain out of production scope until written permission/terms are confirmed; resource budgets must be remeasured if that changes.

  The local throwaway prototype is packages/watch/prototype-issue-16.html and is not production code.

Sign in to comment.