54 lines
6.0 KiB
Markdown
54 lines
6.0 KiB
Markdown
# Hope interface review and approval proposal
|
||
|
||
## Scope and method
|
||
Approval-only overhaul. Production web and native UI are unchanged by this proposal.
|
||
Independent assessments: product design (4638a6b7-0052-4043-924b-d20d21345fc1) and technical evidence (7d81a007-b618-49c2-91a5-22a92c0c1903). Both read current source and desktop/mobile screenshots independently. Technical assessment also ran the detector and offline Chromium tests. No production logins, microphone access, or live mutations during review.
|
||
|
||
## Verdict
|
||
Hope's calm reading surface is a good foundation. The structure undermines its distinctive promise: a realtime companion with a recognizable square presence. Text chat and voice behave like separate products. The visible Talk button navigates to another screen and focuses another Start button; it does not start talking. The desktop header exposes specialist conversation administration at the same priority as the conversation itself.
|
||
|
||
### Heuristic assessment
|
||
Source/static screenshot quality scores; not a claim of complete live usability qualification.
|
||
|
||
| Heuristic | Score / 4 | Main problem |
|
||
|---|---:|---|
|
||
| System status | 2 | Microphone/session state leaves the composer |
|
||
| Real-world match | 2 | Talk is a two-step navigation detour |
|
||
| Control and freedom | 2 | Split context for voice and text |
|
||
| Consistency | 1 | Separate chat/voice identities and layouts |
|
||
| Error prevention | 3 | Safe branching and confirmations are sound |
|
||
| Recognition | 2 | Voice/account conflated; too many concepts |
|
||
| Efficiency | 3 | Shortcuts/history are useful; voice takes extra steps |
|
||
| Minimalism | 2 | Management toolbar and feature stack clutter |
|
||
| Recovery | 2 | Repair/status are remote from composing |
|
||
| Help | 1 | Realtime vs dictation and mic truth need explanation |
|
||
| Total | **20 / 40** | Major structural improvement warranted |
|
||
|
||
## Priority findings
|
||
1. **P1 — Voice is a portal instead of an input method.** Put a labeled square Lightwell control inside the composer. In production, its intentional activation starts the permission/connection flow directly, not merely another screen. Keep the transcript and draft in place.
|
||
2. **P1 — Active voice needs persistent session truth.** Connecting, listening, thinking, speaking, muted, reconnecting, ending, failed, and ended must map to real state. Mute and End remain reachable. Never indicate mic-on before connection and microphone readiness are verified. Preserve editable drafts; current text-send exclusion must remain explicit.
|
||
3. **P1 — Light-theme voice transcript contrast fails.** A hardcoded dark background inherits dark Opal text: heading 1.35:1; muted copy 3.15:1. Replace the inconsistent legacy surface with shared semantic tokens. Primary-chat text contrast passed and should not be misreported as a failure.
|
||
4. **P2 — Management competes with conversation.** Group pin, rename, move, export, archive, delete into a clear overflow menu. Attachments belong inside the composer. Secondary tools belong in Library/Activity/account controls.
|
||
5. **P2 — Signature identity is disconnected.** Replace the generic star/mic approach with a square matrix presence, sampled for legibility at button scale. Use text and pattern as well as color to communicate state. Avoid an orb, decorative glow, or dictation icon as the primary voice affordance.
|
||
|
||
## Technical evidence
|
||
Detector: three warnings, one rule `layout-transition`, one file `web/style.css`, lines 371/613/792. Active voice animates LED size, meter width and waveform height. No measured jank claim. Reduced-motion CSS does not stop JS-driven layout changes.
|
||
Offline current-product browser suite: seven passed. No horizontal overflow at 390px or 320px. Drawer inert/Escape behavior and draft preservation work. Some 30–40px actions fall below preferred 44px comfort, not automatically below WCAG's 24px minimum. Timeline completion announcements exist, but response replacement/focus and screenreader reading need deliberate treatment.
|
||
No user-visible detector overlay was created; evidence is source, screenshots, computed browser styles and offline tests. No temporary servers remained running.
|
||
|
||
## Proposal design commitments
|
||
- Physical scene: a person switching between quiet typing and natural conversation at their desk or on a phone; calm light Opal is the default, with a fully composed dark variant.
|
||
- Restrained color strategy: pink identity at moments of action/presence, not everywhere.
|
||
- One system sans family; 14–15px reading copy; 740px rail; distinct content, navigation and input responsibilities.
|
||
- Square matrix action sits beside Send in the composer. Label reads Talk to Hope, accessible name Start realtime voice conversation. It is not dictation.
|
||
- Inline square persona appears in the same scrolling conversation surface. Existing transcript remains available; no separate voice application takeover.
|
||
- User action activates a simulated listening state only in this HTML. The preview neither requests microphone permission nor starts a backend session.
|
||
- Voice mute/end and speaking/listening examples are interactive. Text draft survives; text sending is disabled until simulated voice ends, reflecting the currently implemented exclusion.
|
||
- Mobile keeps the action in the bottom composer with 44px targets, drawer navigation, safe-area padding and no horizontal overflow.
|
||
- Native dialogs, accessible labels, keyboard focus, Escape, reduced motion and light/dark states.
|
||
|
||
## Approval boundary
|
||
The standalone HTML contains illustrative sample data and simulated controls. Search, settings, Library and Activity demonstrate information architecture, not complete production feature implementations. Connection, permission denial, reconnecting, approval, upload progress, errors and physical keyboard/microphone behavior still require implementation and qualification after approval.
|
||
|
||
**Nothing in this proposal authorizes production replacement.** User approval is required before adapting the real UI, and the real voice flow must be validated without regressing interruption, mic truth, draft retention, conversation ownership or account isolation.
|