marcus/pdf-umbenenner
1
0
Fork 0
Code Issues 14 Releases 2 Activity

UX: Bedeutung und Darstellung von FAILED_RETRYABLE vs FAILED_PERMANENT klaeren #51

New Issue
Closed
opened 2026-04-28 08:12:15 +02:00 by marcus · 1 comment
marcus commented 2026-04-28 08:12:15 +02:00
Owner
Copy Link
Copy Source

Frage

Aus Benutzersicht ist der Unterschied zwischen FAILED_RETRYABLE und FAILED_PERMANENT unklar:

  • Der Benutzer kann per 'Erneut verarbeiten' und 'Status zuruecksetzen' den Zustand ohnehin manuell steuern
  • Ob eine Datei noch automatisch wiederholt wird oder endgueltig aufgegeben ist, ist fuer den Benutzer moeglicherweise irrelevant

Offene Fragen

  1. Soll der Benutzer den Unterschied zwischen FAILED_RETRYABLE und FAILED_PERMANENT sehen?
  2. Wenn ja: Wie wird das visuell unterschieden (Icon, Farbe, Tooltip)?
  3. Wenn nein: Werden beide Status in der GUI gleich dargestellt (z.B. beide rotes ❗)?
  4. Hat FAILED_RETRYABLE ueberhaupt eine Bedeutung wenn der Benutzer manuell eingreifen kann?

Hintergrund

Beim Requirement Engineering wurde diese Frage moeglicherweise zu oberflaechlich behandelt. Vor einer Implementierungsentscheidung sollte das geklaert werden.

## Frage Aus Benutzersicht ist der Unterschied zwischen FAILED_RETRYABLE und FAILED_PERMANENT unklar: - Der Benutzer kann per 'Erneut verarbeiten' und 'Status zuruecksetzen' den Zustand ohnehin manuell steuern - Ob eine Datei noch automatisch wiederholt wird oder endgueltig aufgegeben ist, ist fuer den Benutzer moeglicherweise irrelevant ## Offene Fragen 1. Soll der Benutzer den Unterschied zwischen FAILED_RETRYABLE und FAILED_PERMANENT sehen? 2. Wenn ja: Wie wird das visuell unterschieden (Icon, Farbe, Tooltip)? 3. Wenn nein: Werden beide Status in der GUI gleich dargestellt (z.B. beide rotes ❗)? 4. Hat FAILED_RETRYABLE ueberhaupt eine Bedeutung wenn der Benutzer manuell eingreifen kann? ## Hintergrund Beim Requirement Engineering wurde diese Frage moeglicherweise zu oberflaechlich behandelt. Vor einer Implementierungsentscheidung sollte das geklaert werden.
marcus commented 2026-04-30 14:46:14 +02:00
Author
Owner
Copy Link
Copy Source

Umgesetzt in V3.0: Einheitliche Status-Darstellung implementiert. Exakte Enum-Namen aus ProcessingStatus, Icons/Farben/Tooltips gemäß Spec, Farbe nie alleiniges Unterscheidungsmerkmal, Detailbereich bei FAILED_FINAL mit erweiterter Erklärung. Commit 563d9f5.

Umgesetzt in V3.0: Einheitliche Status-Darstellung implementiert. Exakte Enum-Namen aus ProcessingStatus, Icons/Farben/Tooltips gemäß Spec, Farbe nie alleiniges Unterscheidungsmerkmal, Detailbereich bei FAILED_FINAL mit erweiterter Erklärung. Commit 563d9f5.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Assignees
Clear assignees
marcus
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: marcus/pdf-umbenenner#51
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?