Konzept: Bei GPS-Fehler trotzdem speichern – ja oder nein? #24

New issue

Closed

opened 2026-05-04 20:46:14 +02:00 by moritz · 0 comments

moritz commented

2026-05-04 20:46:14 +02:00

Owner

Frage

Wenn der GPS-Fix fehlschlägt (kein Signal oder zu schwach), wird das Ereignis aktuell mit null-Koordinaten gespeichert + ErrorView angezeigt. Ist das richtig oder sollten wir gar nicht speichern? Konzeptuelle Frage, kein Code-Issue — erstmal durchdenken.

Aktuelles Verhalten

Fall	Speichern?	UI
Erfolg (≥ USABLE)	Ja, mit Koords	SuccessView
Signal zu schwach	Ja, ohne Koords	ErrorView („GPS Signal zu schlecht")
Kein Signal	Ja, ohne Koords	ErrorView („Standort konnte …")

Argumente fürs Speichern

Zeitstempel ist gerettet: Im Einsatz oft das Wichtigste — „um 14:32 ist xy passiert", auch wenn Standort fehlt
User-Intent: Knopf wurde gedrückt → ein Log-Eintrag ist gewollt
Dokumentationspflicht: Polizei-Vorgang nachher — fehlender Eintrag ist schlimmer als unvollständiger
Keine doppelte Aktion: User muss nicht erneut drücken nach Error-Wegklicken

Argumente dagegen

Müll im Verlauf: Einträge ohne Koords sind nur halb nützlich, lenken beim Durchblättern ab
Falsches Sicherheitsgefühl: User glaubt evtl. „läuft", obwohl der Standort fehlt
Clean-UX-Prinzip: Error = nichts passiert, einfach wiederholen ohne mentale Last
Edge case: Wenn man vor laufender Funkstreife den Knopf drückt und GPS nicht greift, ist evtl. die zeitliche Genauigkeit wichtiger als die örtliche → Zeit-only ist trotzdem wertvoll

Optionen

Status quo: Speichern mit null-Koords (ab #22 unverändert).
Nicht speichern: Bei jedem GPS-Fehler kein Event anlegen, ErrorView reicht. Cleanstes Mental-Model.
Nur Zeitstempel + Typ: Speichern, aber eigenes Flag incomplete = true oder eigener Typ — visuell im Verlauf abheben (grau? durchgestrichene Koord-Zeile?).
User entscheiden lassen: Nach ErrorView fragen „Trotzdem ohne Standort speichern?". 1× extra Klick, aber bewusst.
Auto-retry: Bei Fehler nochmal 30 s warten, erst dann finalen Status setzen. Verkompliziert das State-Modell, könnte aber im Grenzfall (langsamer Fix) helfen.

Was ich vermute, was passt

Option 3 wäre am ehrlichsten: speichert (Zeit ist wichtig), markiert aber sichtbar als unvollständig. Ist auch die größte Code-Änderung. Option 1 (status quo) ist OK, wenn man im Verlauf akzeptiert, dass Kein Standort als Zeile reicht.

Vor Umsetzung hier eine Entscheidung treffen, dann ggf. Folge-Issue.

## Frage Wenn der GPS-Fix fehlschlägt (kein Signal oder zu schwach), wird das Ereignis aktuell **mit `null`-Koordinaten gespeichert** + ErrorView angezeigt. Ist das richtig oder sollten wir gar nicht speichern? Konzeptuelle Frage, kein Code-Issue — erstmal durchdenken. ## Aktuelles Verhalten | Fall | Speichern? | UI | |---|---|---| | Erfolg (≥ USABLE) | Ja, mit Koords | SuccessView | | Signal zu schwach | **Ja, ohne Koords** | ErrorView („GPS Signal zu schlecht") | | Kein Signal | **Ja, ohne Koords** | ErrorView („Standort konnte …") | ## Argumente *fürs* Speichern - **Zeitstempel ist gerettet**: Im Einsatz oft das Wichtigste — „um 14:32 ist xy passiert", auch wenn Standort fehlt - **User-Intent**: Knopf wurde gedrückt → ein Log-Eintrag ist gewollt - **Dokumentationspflicht**: Polizei-Vorgang nachher — fehlender Eintrag ist schlimmer als unvollständiger - **Keine doppelte Aktion**: User muss nicht erneut drücken nach Error-Wegklicken ## Argumente *dagegen* - **Müll im Verlauf**: Einträge ohne Koords sind nur halb nützlich, lenken beim Durchblättern ab - **Falsches Sicherheitsgefühl**: User glaubt evtl. „läuft", obwohl der Standort fehlt - **Clean-UX-Prinzip**: Error = nichts passiert, einfach wiederholen ohne mentale Last - **Edge case**: Wenn man vor laufender Funkstreife den Knopf drückt und GPS nicht greift, ist evtl. die *zeitliche* Genauigkeit wichtiger als die örtliche → Zeit-only ist trotzdem wertvoll ## Optionen 1. **Status quo**: Speichern mit `null`-Koords (ab #22 unverändert). 2. **Nicht speichern**: Bei jedem GPS-Fehler kein Event anlegen, ErrorView reicht. Cleanstes Mental-Model. 3. **Nur Zeitstempel + Typ**: Speichern, aber eigenes Flag `incomplete = true` oder eigener Typ — visuell im Verlauf abheben (grau? durchgestrichene Koord-Zeile?). 4. **User entscheiden lassen**: Nach ErrorView fragen „Trotzdem ohne Standort speichern?". 1× extra Klick, aber bewusst. 5. **Auto-retry**: Bei Fehler nochmal 30 s warten, erst dann finalen Status setzen. Verkompliziert das State-Modell, könnte aber im Grenzfall (langsamer Fix) helfen. ## Was ich vermute, was passt Option **3** wäre am ehrlichsten: speichert (Zeit ist wichtig), markiert aber sichtbar als unvollständig. Ist auch die größte Code-Änderung. Option 1 (status quo) ist OK, wenn man im Verlauf akzeptiert, dass `Kein Standort` als Zeile reicht. Vor Umsetzung hier eine Entscheidung treffen, dann ggf. Folge-Issue.

moritz added the

idea

label

2026-05-04 20:46:14 +02:00

moritz referenced this issue from a commit

2026-05-05 10:02:42 +02:00

Fix #24: Reassure user that timestamp is saved on GPS failure

moritz closed this issue

2026-05-05 10:02:43 +02:00