Dictation: give routine no-speech outcomes brief feedback and keep recovery reachable

Aperta
#156 3 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
macos, swift

Direzione di ricerca

Start with AppModel.swift around the cited no-speech and retained-audio paths, then read CapturePanel.swift and CaptureHUDLayout.swift for presentation behavior. Exercise the listed short-input, silence, speech, provider-failure, and save-failure cases with controlled material. Done means routine no-speech returns to controls within two seconds unless its cue is in use, while technical and recovery failures remain actionable and accessible without discarding recoverable audio.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement

Outcome and evidence

P2, user-reported friction and source-confirmed presentation policy. A no-speech result replaces the toolbar with a large persistent “Dictation needs attention” panel and requires another close click. The user requested a smaller, more intuitive cue.

The supplied screenshot proves the no-speech presentation but has no embedded build identity. During this audit a persistent recovered-recording panel was also observed and dismissed in the current installed build. No new silence transcription or provider-failure recording was performed, so do not claim measured transcription reliability.

Workbench Preview 2.3.0, build 20260928054038, source 00be555139f87d4557f48fcffc132b8621c251a2, unmodified source, macOS 26.5.1 (25F80), Apple M5, built-in display. Identity verified in the running app using Copy build details on 28 September 2026.

Owner and bounded change

Source links below pin the earlier audited commit 9578d8cf; the relevant paths were checked against installed 00be5551 and the described behaviour is unchanged. Source findings and native observations are distinguished below.

  • AppModel.swift turns empty recognised output into generic transcription failure; another path is at line 601.
  • CapturePanel.swift gives any failure the dictation surface; the persistent message layout is at line 563.
  • CaptureHUDLayout.swift fixes that surface at 480 × 128 points.
  • Existing short/silent handling and retained-audio admission are in AppModel around lines 453 and 606.

Distinguish routine silence/accidental short input from permission, engine, persistence and recovered-audio failures. Routine no-speech should give an understandable cue for up to 2 seconds and return to the toolbar without requiring dismissal. Pause expiry while the cue is deliberately focused or hovered; complete its accessibility announcement. Technical failures and recovered recordings keep an explicit reachable recovery path. Detailed retry/recovery must stay discoverable through the existing owner.

A gentle shake can supplement a textual/accessible cue, with Reduce Motion respected. It must not be the only explanation, and automatic visual dismissal must not discard retained audio.

Acceptance

  • Exercise short input, silence, non-speech, normal speech, provider unavailable and failed save with controlled material.
  • Routine no-speech returns to normal controls within 2 seconds unless the person is interacting with its cue; meaningful technical/recovery failures remain actionable.
  • Retry/Record again preserve the promised recovery and do not reuse an old paste destination.
  • Escape/dismiss never discards recoverable audio; a new capture is admitted safely.
  • VoiceOver and Reduce Motion receive understandable feedback.
  • Record actual installed outcomes and unavailable microphone/provider cases.

Related: #134's recording-on-toolbar work and #7. This is feedback/recovery refinement, not permission to suppress all errors.

Lingua principale
Swift
Stelle
0
Fork
1
Merge medio
18h 19m
PR unite (30g)
114

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Ship-Work/workbench

Tutte le issue di Ship-Work/workbench

Issue simili

Altre issue su Swift

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.